[Planetlab-users] Re: tuntap on 4.2

[Sapan Bhatia]

Cristian,

Unfortunately not. I can't think of any way of achieving this result,
short of trying to come up with a multiplexing key that is different
for the traffic streams into which you would like to split the main
tunnel.

Sapan

On Wed, Jul 9, 2008 at 4:55 PM, Cristian Lumezanu <lume at cs.umd.edu> wrote:
> Sapan,
>
> Thanks for the answer. Does this mean that there is no way of creating and
> using multiple tunnels on a PlanetLab node?
>
> Cristian
>
> Sapan Bhatia wrote:
>>
>> Hi Cristian and Shin-ae Woo,
>>
>> The way tun/tap works on PL is that there's one device (tap0) that is
>> virtualized on a per-slice basis. So you don't need to call the
>> standard interface-creation code you use on Linux to start things up.
>> The tap0 interface is instantiated and always there, and you can use
>> it by reading from and writing to the file /dev/net/tun and by using
>> the tap0 interface.
>>
>> Does this address your doubt?
>>
>> Sapan
>>
>> On Mon, Jul 7, 2008 at 6:32 PM, Cristian Lumezanu <lume at cs.umd.edu> wrote:
>>
>>>
>>> Sapan,
>>>
>>> I know you must be busy with other things besides the tun/tap on PL so
>>> please let me know if there is anything else I can do to make your work
>>> easier with the tun/tap.
>>>
>>> Cristian
>>>
>>> Sapan Bhatia wrote:
>>>
>>>>
>>>> Christian,
>>>>
>>>> Have you previously tried your code out on PlanetLab? Could you try
>>>> using this box: planet2.scs.nyu.edu? You'll have to ssh in via port
>>>> 806.
>>>>
>>>> The first thing I'd like to do is to make sure that the migration has
>>>> been clean and that we haven't lost any functionality because of the
>>>> changes to the VNET module. The second thing will be to figure out if
>>>> things work as they do on standalone Linux boxes.
>>>>
>>>> I'd appreciate it if you'd try this out. If it's the case that it's a
>>>> generic PL (not 4.2) problem, then we'll roll out an initial version
>>>> and debug your problem in that version.
>>>>
>>>> Sapan
>>>>
>>>>
>>>> On Thu, Jul 3, 2008 at 3:52 PM, Cristian Lumezanu <lume at cs.umd.edu>
>>>> wrote:
>>>>
>>>>
>>>>>
>>>>> Sapan
>>>>>
>>>>> I am using only the tun interface and I see some weird behavior:
>>>>>
>>>>> I open the tun device using open("/dev/net/tun",...) and then I use
>>>>> ioctl(TUNSETIFF,...) to set up some parameters. The tun interface that
>>>>> is
>>>>> associated with my tun device is "tap0" not "tun0" as it should be.
>>>>> When
>>>>> I
>>>>> repeat the same code (hoping that I would get a different tun
>>>>> interface),
>>>>> ioctl breaks with the error "Device or resource busy - /dev/net/tun
>>>>> (Errno::EBUSY)). The exact same code works without problems on each of
>>>>> my
>>>>> Linux machines I have set up in our lab. Is there anything different
>>>>> about
>>>>> PL that I am missing? Thanks.
>>>>>
>>>>> Cristian
>>>>>
>>>>> Sapan Bhatia wrote:
>>>>>
>>>>>
>>>>>>
>>>>>> Great! Thanks for responding quickly to our call for testing. Could
>>>>>> the others who had asked for tuntap (cc'd) also verify that it's
>>>>>> satisfactory, so that we can package it and roll it out? -- Sapan
>>>>>>
>>>>>> On 7/3/08, Andreas Haeberlen <ahae at mpi-sws.mpg.de> wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>>>
>>>>>>> Hello Sapan,
>>>>>>>
>>>>>>>  thank you for the quick response. I tested our software on the node
>>>>>>>  you set up for us, and it looks like everything is working fine.
>>>>>>>  The only unusual thing I saw was that all outgoing packets are
>>>>>>> counted
>>>>>>>  as dropped by the kernel:
>>>>>>>
>>>>>>>  tap0      Link encap:Ethernet  HWaddr 00:FF:0A:28:6C:01
>>>>>>>          inet addr:10.40.108.1  P-t-P:10.40.108.1
>>>>>>>  Bcast:10.255.255.255
>>>>>>> Mask:255.0.0.0
>>>>>>>          UP BROADCAST POINTOPOINT RUNNING NOARP  MTU:1468  Metric:1
>>>>>>>          RX packets:15108 errors:0 dropped:0 overruns:0 frame:0
>>>>>>>          TX packets:13935 errors:0 dropped:13935 overruns:0 carrier:0
>>>>>>>          collisions:0 txqueuelen:1000
>>>>>>>          RX bytes:20480346 (19.5 MiB)  TX bytes:14285330 (13.6 MiB)
>>>>>>>
>>>>>>>  However, since the packets seem to be delivered to the application
>>>>>>> anyway,
>>>>>>>  this is more of a cosmetic problem.
>>>>>>>
>>>>>>>  Thank you,
>>>>>>>
>>>>>>>      - Andreas
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>
>>>>>>>> Hello,
>>>>>>>>
>>>>>>>> I've installed a first attempt at resurecting tuntap on
>>>>>>>> planetlab-7.cs.princeton.edu. Please test the functionality on this
>>>>>>>> node at your convenience. If you run into problems (quite likely),
>>>>>>>> then it would help if you could join us on the PlanetLab IRC channel
>>>>>>>> at irc.freenode.net#planetlab so that we can iterate over it and get
>>>>>>>> it working as it should.
>>>>>>>>
>>>>>>>> Once we are satisfied that the feature is running fine on this alpha
>>>>>>>> node, we can deploy it throughout PlanetLab.
>>>>>>>>
>>>>>>>> Sapan
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>
>>>>>
>>>
>>>
>