[Ns-developers] Tap/Tun NetDevice (Was: release update)

[Tom Henderson]

Gustavo Carneiro wrote:
> 
> 
> 2009/6/5 Tom Henderson <tomh at tomh.org <mailto:tomh at tomh.org>>
> 
>     Gustavo Carneiro wrote:
> 
>         2009/5/23 Mathieu Lacage <mathieu.lacage at sophia.inria.fr
>         <mailto:mathieu.lacage at sophia.inria.fr>>
> 
>             hi,
> 
>             It's been a while, and we are getting closer to our original
>             target
>             release date of june 15th.
> 
>             Tom, Craig, and I had a phone conversation on wednesday to
>             talk about
>             the status of the ipv4 rework. Tom plans to merge his
>             ns-3-ip-routing
>             tree in ns-3-dev on monday. This tree appears to contain the
>             crux of the
>             API changes we wanted with a couple of implementation issues
>             to sort
>             out. Given the tight schedule, we agreed to aim for a 2-week
>             stabilization and bug fixing period after the merge, and
>             then, to freeze
>             ns-3-dev around june 15th, hence, targeting june 21st or
>             early july for
>             a final release.
> 
>             Current items still on the table for merging:
>              - the tag rework: maybe it can make it after ip-routing is in
>              - the virtual net device: gustavo, do you have interest in
>             pushing
>             this forward with the name change (TapNetDevice) suggested
>             by tom ?
> 
> 
> 
>         The name is OK with me.  I took the old code, renamed a few
>         things, rebased
>         against ns-3-dev, and added a bit more documentation.  Should be
>         ready to
>         merge.  The only thing missing is an example, I guess.
> 
>            http://code.nsnam.org/gjc/ns-3-tap-netdevice/
> 
> 
>     Gustavo,
>     Although I suggested the name TapNetDevice, in reviewing this today,
>     I noticed that it is really behaving like a Tun device instead of a
>     Tap device (i.e. it is not adding an Ethernet header).
> 
>     So, would you be amenable to naming it TunNetDevice instead?
> 
> 
> I don't think you are seeing it right.  The analogy between Linux and 
> NS-3 does not fit perfectly simply because the NetDevice API of NS-3 is 
> slightly different from the netdevice API of Linux.  See [1].  Linux's 
> transmission API takes a single sk_buff of a packet with header already 
> applied, while NS-3 Send/SendTo takes a Packet, ethertype, source-addr, 
> dest-addr, and is the responsibility of the NetDevice to add the correct 
> header(s).  [but I think the NS-3 API is better than the Linux one]

I see your point about the net device API, but it seems like that is a 
detail that is not really important to users of the device.  I was 
looking at it from the perspective of the user-space user of the device, 
who if they read man 4 tap will expect the packet to have an Ethernet 
header.  I also saw that you were setting the default flags PointToPoint 
and NeedsArp like a TUN device.  IsPointToPoint is hard coded to true 
(although it is a virtual method).

> 
> If you keep that mismatch in mind, it is only natural that TapNetDevice 
> takes Packet and L2 information as separate parameters, but it only does 
> it to keep in line with NetDevice API.  It is still a L2 device, it is 
> still a TAP device.  It seems to me that an equivalent to a TUN device 
> would be a replacement for Ipv4Interface that would delegate 
> transmission to a user callback.
> 
> That being said, I believe that TapNetDevice can also be subverted to 
> fulfill a role similar to TUN.  To make IP tunnels, one needs to create 
> a TapNetDevice configured with IsPointToToint=true, NeedsArp=false, and 
> then transmit packets via a IP raw, UDP, or TCP socket, depending on the 
> type of tunnel you need.  
 >
On the receiving side, it needs to listen to a
> similar socket and inject the packet by calling Receive() or 
> PromiscReceive() with IP ethertype (0x0800) and empty src/dst addresses 
> (the IPv4 stack will not care about the addresses in any case).

> 
> With this in mind, I would agree with renaming to something else, but 
> not TunNetDevice.  My first choice was VirtualNetDevice because that 
> name is ambiguous enough that it can cover both tun and tap 
> functionality.  Another possible name I could suggest would be 
> UserNetDevice.

I still think that TapNetDevice is probably not a good name, because it 
is not working with Ethernet frames.

from the tun/tap faq:

1.6 What is the difference between TUN driver and TAP driver?
  TUN works with IP frames. TAP works with Ethernet frames.

I would still be OK with TunNetDevice but if that makes you 
uncomfortable I would be OK with your original proposal of 
VirtualNetDevice (which seems to be the generic name that tun/tap 
project uses) or UserNetDevice.

> 
> 
>     I also thought that the example was a bit unusual because the
>     TunNetDevice handler is creating a Udp socket to send the datagram
>     out, instead of just a raw socket.  What do you think about changing
>     it to a raw socket?
> 
> 
> I do not agree it is unusual.  See this example in the FAQ [2]:
> 
>     1.5 How does Virtual network device actually work ?
>      Virtual network device can be viewed as a simple Point-to-Point or
>      Ethernet device, which instead of receiving packets from a physical
>      media, receives them from user space program and instead of sending
>      packets via physical media sends them to the user space program.
> 
>      Let's say that you configured IPX on the tap0, then whenever
>      kernel sends any IPX packet to tap0, it is passed to the application
>      (VTun for example). Application encrypts, compresses and sends it to
>      the other side over TCP or UDP. Application on other side decompress
>      and decrypts them and write packet to the TAP device, kernel handles
>      the packet like it came from real physical device.

yes, but the example is not IPX tunneling; I don't see what the 
functionality of double UDP is giving here.

Regards,
Tom