usermode uses some makefile hackery to enable TUNTAP support (it appends a -DTUNTAP to the end of CFLAGS). The ebuild isn't building with tuntap support and i guess it's because gentoo sets specific CFLAGS. This applies to the masked ebuild as well..
Actually the other thing with uml - some of uml uses /dev/net/tun, but the symlink to /dev/misc/net/tun was wrong on my system (and another system): % ls -l /dev/net/tun lr-xr-xr-x 1 root root 12 Aug 6 20:50 /dev/net/tun -> misc/net/tun ie. it links to /dev/net/misc/net/tun..
to comment #1: look at bug 1585. there is a fix but this fix needs more testing.
Created attachment 2912 [details] from scratch to uml networking the attachment shows a simple solution. assuming everyone runs a 2.4 kernel nowadays, constantly adding -DTUNTAP to the ebuild solves the problem.
Hello maintainer?!?!?! Manson?!?! Or who is ist? Is this fixed?
Date: Wed, 26 Feb 2003 23:26:31 +0100 From: Cristiano Paris <paris@disp.uniroma2.it> To: tantive@gentoo.org Subject: Gentoo Usermode Utilities I was running an UML vm using the tuntap transport when uml_net reported "Unknown transport 'tuntap'. Looking at UML-utils Makefile and uml_net in particular I see the following conditional: TUNTAP = $(shell [ -e /usr/include/linux/if_tun.h ] && echo -DTUNTAP) which correctly evaluates to "-DTUNTAP". Anyway this compilation define doesn't shows up during uml_net compilation. I think it conflicts with ebuild's CFLAGS env variable. I had to add -DTUNTAP by hand to the ebuild. I think this can easily fixed. Thanks for your work, Cristiano ---- JabberID : paris@jabber.at ICQ # : 168127096 Yahoo : cristiano_paris MSN : cristiano_paris@hotmail.com GnuPG Public Key Fingerprint (keyserver.linux.it) pub 1024D/9F064556 2002-01-18 Cristiano Paris Key fingerprint = 9D20 667A 9B12 1DA2 2A41 F32E C93E 490C 9F06 4556 ----
As I already corrected this in #16834 some time ago and mholzer reassigned this bug to me i'm going to close it now. sys-apps/usermode-utilities-20030205-r1 have -DTUNTAP in the emake line.
Closing.
