A tun of trouble….
Sorry, VERY bad pun but I couldn’t resist. I mentioned that I was having tun difficulties that kept me from playing around with anything fancy networking-wise with qemu. For starters let me see if I can explain what tun is. Tun is a method of creating a point-to-point “imaginary” network connection between a program and an operating system. For instance, Qemu sets up a device called /dev/tun0 in the host operating system. This /dev/tun0 can communicate with the kernel and then the outside world. /dev/tun0 behaves just like any other network interface to the viewers on the outside (even getting it’s own ip address that is network reachable.)
Further, within the application (in this case Qemu) the other end of this point2point connection is setup. Within the guest operating system the network card connects to this “tunnel” so that the guest operating system talks to the outside world using the external /dev/tun0 Ok – you don’t need to understand the specifics. There is a Tun driver included in the 2.6 series of the Linux Kernel. Qemu uses Tun for host/guest operating system communication and if I recall so does bochs and plex86 and a few other emulators and virtual machines. The concept is also handy for VPN software such as openvpn. Usermodelinux also makes use of tun. Many of these can use a tap driver as well. The best way to seperate the two is to realize they act at different layers, tap passes ethernet frames, tun passes ip frames. (So tap works at a lower level and is more versatile with regards to different network protocols.)
Anyway, here’s what was going on. I was trying to test out the tun driver and did the following.
ifconfig tun0 up 10.0.2.1
and the error I saw was variations on this…
SIOCSIFADDR: No such device
tun0: unknown interface: No such device
SIOCSIFNETMASK: No such device
Now I saw several variations as I tinkered…. I had the tun device listed at /dev/tun and /dev/net/tun (one is a link to the other). The module was loaded, it just didn’t behave like it should. After MANY google searches I came across a single message in the openvpn users list that hinted at a possible solution.
According to this post, if the directories /usr/include/linux and /usr/src/linux/include/linux were different then you might have problems using the tun driver. (It might load but not behave properly.) Apparently this had been discussed heavily on the vtun list (another vpn approach) with the error message “bad state” showing up.
Now /usr/src/linux is usually symlinked to the source for your kernel version (in my case /usr/src/linux-2.6.8.1-12mdk/). The two directories mentioned though were different (I’ve gone through several kernels). So, I moved /usr/include/linux to /usr/include/linuxold and then symlinked /usr/src/linux/include/linux to /usr/include/linux like this….
ln -s /usr/src/linux/include/linux /usr/include/linux
After all this, today tun is working. I had a power interruption and don’t recall if that was after the change, so a reboot may be necessary to finalize the fix. But all in all this was an obscure fix to an obscure and strange problem. I’m posting mainly because I had such a time finding the answer, maybe this will help someone else out.