[BUG?] vtund broken by tun driver changes in 2.4.6

[BUG?] vtund broken by tun driver changes in 2.4.6

[Ryan Mack]

I recently upgraded a server running vtund 2.4 (4/18/01) to stock 2.4.6
kernel.  It seems the changes to the tun driver have broken vtund.  Now my
syslog gets filled with the following messages when a client attempts to
connect:

Jul  5 10:15:53 mackman vtund[4011]: Session
mackman-vpn[64.169.117.25:2359] opened
Jul  5 10:15:53 mackman vtund[4011]: Can't allocate tun device. File
descriptor in bad state(77)
Jul  5 10:15:53 mackman vtund[4011]: Session mackman-vpn closed
Jul  5 10:16:04 mackman vtund[4014]: Session
mackman-vpn[64.169.117.25:2360] opened
Jul  5 10:16:04 mackman vtund[4014]: Can't allocate tun device. File
descriptor in bad state(77)
Jul  5 10:16:04 mackman vtund[4014]: Session mackman-vpn closed

Eventually the client gives up.  Do you have any suggestions or know of
any fixes?

Thanks, Ryan Mack

Re: [BUG?] vtund broken by tun driver changes in 2.4.6

[Kevin P. Fleming]

Recompile your VTUND daemon with the new kernel headers (and also updated to
2.5 vtund, it has some small patches) and you will be fine.

----- Original Message -----
From: "Ryan Mack" <rmack@mackman.net>
To: <max_mk@yahoo.com>
Cc: <linux-kernel@vger.kernel.org>
Sent: Saturday, July 07, 2001 1:02 AM
Subject: [BUG?] vtund broken by tun driver changes in 2.4.6


> I recently upgraded a server running vtund 2.4 (4/18/01) to stock 2.4.6
> kernel.  It seems the changes to the tun driver have broken vtund.  Now my
> syslog gets filled with the following messages when a client attempts to
> connect:
>
> Jul  5 10:15:53 mackman vtund[4011]: Session
> mackman-vpn[64.169.117.25:2359] opened
> Jul  5 10:15:53 mackman vtund[4011]: Can't allocate tun device. File
> descriptor in bad state(77)
> Jul  5 10:15:53 mackman vtund[4011]: Session mackman-vpn closed
> Jul  5 10:16:04 mackman vtund[4014]: Session
> mackman-vpn[64.169.117.25:2360] opened
> Jul  5 10:16:04 mackman vtund[4014]: Can't allocate tun device. File
> descriptor in bad state(77)
> Jul  5 10:16:04 mackman vtund[4014]: Session mackman-vpn closed
>
> Eventually the client gives up.  Do you have any suggestions or know of
> any fixes?
>
> Thanks, Ryan Mack
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
>
>
>

Re: [BUG?] vtund broken by tun driver changes in 2.4.6

[Joerg Reuter]

>Recompile your VTUND daemon with the new kernel headers (and also updated to
>2.5 vtund, it has some small patches) and you will be fine.

Probably not:

        #define TUNSETNOCSUM  _IOW('T', 200, int)
        #define TUNSETDEBUG   _IOW('T', 201, int)
        #define TUNSETIFF     _IOW('T', 202, int)
        #define TUNSETPERSIST _IOW('T', 203, int)
        #define TUNSETOWNER   _IOW('T', 204, int)

Which is (apart from some extensions) the same as it ever was. However 
adding a

	printk(KERN_INFO "tun_chr_ioctl() called with cmd=%4.4X
		(TUNSETIFF=%4.4X, tun is%s set)\n",
		cmd, TUNSETIFF, tun? "":" not");

in tun_chr_ioctl() reveals:

	tun_chr_ioctl() called with cmd=54CA (TUNSETIFF=400454CA, tun is not set)

Now, where does the 0x400454CA come from? What happened to the _IOW()
macros? (Tested with 2.4.6 vanilla kernel sources and gcc-2.95.3)

And BTW, you shouldn't include kernel headers from user space programs,
should you.

Regards,
-- 
Joerg Reuter                                    http://yaina.de/jreuter
And I make my way to where the warm scent of soil fills the evening air. 
Everything is waiting quietly out there....                 (Anne Clark)

Re: [BUG?] vtund broken by tun driver changes in 2.4.6

[Maksim Krasnyanskiy]

> >Recompile your VTUND daemon with the new kernel headers (and also updated
> > to 2.5 vtund, it has some small patches) and you will be fine.
>
> Probably not:
>
>         #define TUNSETNOCSUM  _IOW('T', 200, int)
>         #define TUNSETDEBUG   _IOW('T', 201, int)
>         #define TUNSETIFF     _IOW('T', 202, int)
>         #define TUNSETPERSIST _IOW('T', 203, int)
>         #define TUNSETOWNER   _IOW('T', 204, int)
>
> Which is (apart from some extensions) the same as it ever was. However adding a
Ioctls were defined _without_ IOW macros. And that was ugly. That's why I redifened them.
So, if you recompile everything will be fine.

> And BTW, you shouldn't include kernel headers from user space programs, should you.
That rule doesn't apply here. 

Max 

-- 

Maksim Krasnyanskiy      
Senior Kernel Engineer
Qualcomm Incorporated

maxk@qualcomm.com
http://bluez.sf.net
http://vtun.sf.net

Re: [BUG?] vtund broken by tun driver changes in 2.4.6

[Joerg Reuter]

[-- Attachment #1: Type: text/plain, Size: 1151 bytes --]

On Fri, Jul 13, 2001 at 08:58:52AM -0700, Maksim Krasnyanskiy wrote:

> Ioctls were defined _without_ IOW macros. And that was ugly. That's why I redifened them.
> So, if you recompile everything will be fine.

So you break binary compatibilty within a _stable_ kernel release just
for the sake of beauty? Besides, this does not only affect VTUND but
also other applications like Hercules. Just recompiling Hercules doesn't
help here anyway, because it (rightfully) refuses to include kernel
headers but (due to the lack of net/if_tun.h within glibc) constructs
the IOCTL command on its own.

> > And BTW, you shouldn't include kernel headers from user space programs, should you.
> That rule doesn't apply here. 

Can you tell me why it does not apply here? Just because you happen to
be the author of both the driver (which is, without doubt, very
valuable) and _one_ of several applications using it?

-- 
Joerg Reuter                                    http://yaina.de/jreuter
And I make my way to where the warm scent of soil fills the evening air. 
Everything is waiting quietly out there....                 (Anne Clark)

[-- Attachment #2: Type: application/pgp-signature, Size: 240 bytes --]

Re: [BUG?] vtund broken by tun driver changes in 2.4.6

[Maksim Krasnyanskiy]

> > Ioctls were defined _without_ IOW macros. And that was ugly. That's why I
> > redifened them. So, if you recompile everything will be fine.
>
> So you break binary compatibilty within a _stable_ kernel release just
> for the sake of beauty ? 
I rewrote a lot of driver code to support persistent device and device ownership. So, I thought it was a right time
to clean up interface as well. API was supposed to be cleaned up before 2.4.0 final.

> Besides, this does not only affect VTUND but  also other applications like Hercules.
Yeah :(. Dave warned me about that.  I agree that it's a bad thing. Sorry about that.
I promice that there will be no API changes in 2.4.x. 
 
> Just recompiling Hercules  doesn't  help here anyway, because it (rightfully) refuses to include kernel
> headers but (due to the lack of net/if_tun.h within glibc) constructs the IOCTL command on its own.
Which imho is not a good idea.

> > > And BTW, you shouldn't include kernel headers from user space programs, should you.
> > That rule doesn't apply here.
>
> Can you tell me why it does not apply here? Just because you happen to
> be the author of both the driver (which is, without doubt, very
> valuable) and _one_ of several applications using it?
No. Just because glibc lacks a lot of if_*.h headers and if_tun.h is one of them.
Also it seems that there is no standard where if_*.h should go (include/netinet or in include/net).
On my RH 7.1 box if_ether.h is in netinet (which is imho wrong) and if_ppp.h is in net. 

Max
-- 

Maksim Krasnyanskiy      
Senior Kernel Engineer
Qualcomm Incorporated

maxk@qualcomm.com
http://bluez.sf.net
http://vtun.sf.net