bug in tun

[Samuel Rydh]

On Thu, May 29, 2003 at 04:14:07PM -0400, harry eaton wrote:
> Hello,
> 
> I don't see how this works for anybody, but my experience is this:
> 
> When starting up mol with
> 
> netdev: tun0 -tun
> 
> The function "tun_open" in src/drivers/net/iface.c is called with
> intf_name set to "tun0", but the line
> 
> ifr.ifr_flags = IFF_TAP | IFF_NO_PI;
> 
> suggests that the TAP interface is desired.

Yes... it is the tap service of the tun driver that MOL wants.
Not to be confused with the now obsolete ethertap driver.

> No matter, when the
> TUNSETIFF ioctl is made, there is a real problem:
> 
> first in the function "tun_set_iff", in src/netdriver/tun.c, at line 396
> name is set to "tap%d", which doesn't matter much because then
> it is immediately overwritten with ifr->ifr_name which is "tun0"
> because that name exists. It is this name that is passed to the kernel's
> dev_alloc_name routine
> however a quick glance at that code reveals
> that the name string must contain a single "%d" which "tun0" obviously
> does not; the result produces an error and the device is henceforth gone.

No, take a closer look. The dev_alloc_name() function 
accepts both "tun%d" and "tun0".

> My cheap work-around was to change the ifr.ifr_flags in iface.c to use
> IFF_TUN | IFF_NO_PI, and then comment out the code in tun.c where
> it takes the name from ifr->ifr_name. This at least brings up the interface
> for me.

That won't work. MOL really wants the tap interface of the
tun driver. Admittedly, it might have made more sense
to use 'tapN' as the interface name, but the 'tapN' name
is also used by ethertap driver...

Cheers,

/Samuel