Common Misconceptions

• An IP Address Is Required On The TAP Interface - This is absolutely false in TAP mode. If you add an IP address to the the interface on the host side, it is (literally) the same as adding another IP address to your system. Instead of being available to the general network, though, it’s accessible to the application on the other end of the tunnel. There are use cases – especially where routing and tunneling are concerned – but if you just want your application to be able to talk to the local host system, you’re better off with a host route. It’s less to manage.
• Hardware Address Ownership - I’ve seen some applications that use an ioctl call to get the hardware address of the TAP interface, and then attempt to use that address as the source of packets sent back over the tunnel. This is invalid! That hardware address belongs to the far end (the Linux host), not the near end. If you do this, you’ll have all manner of hard-to-debug problems. The correct method is to set or generate a unique MAC address for your application.

That’s all I can think of for now.

Conclusion

As you can see, using the TUN/TAP device is quite straightforward. There’s no mucking about with all the vagaries of writing kernel code. You simply open it, set it up, and exchange data with it.

As I mentioned, I spent most of last weekend (and a couple of evenings this week) sorting out the networking code in the NuttX simulator arch, and the tap device was the easy part. Most of the difficulty was in understanding the NuttX device model and making my features work with it. The actual network communication is a piece of cake.

References

• Linux Kernel - Documentation/networking/tuntap.txt
• Linux Kernel - drivers/net/tun.c
• Linux Kernel - include/uapi/linux/if_tun.h
• Let’s code a TCP/IP stack, 1: Ethernet & Arp