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
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" <[email protected]>
To: <[email protected]>
Cc: <[email protected]>
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 [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
>
>
>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)
> >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
[email protected]
http://bluez.sf.net
http://vtun.sf.net
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)
> > 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
[email protected]
http://bluez.sf.net
http://vtun.sf.net