[Ns-developers] Tap/Tun NetDevice (Was: release update)
tomh at tomh.org
Sat Jun 6 08:19:13 PDT 2009
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>>
> It's been a while, and we are getting closer to our original
> 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
> 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
> 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.
> 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 . 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
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 :
> 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.
More information about the Ns-developers