Forget it,
It works now. I just found out
that setting the name of the device
couses the ioctl to fail.
Don't know if this is a
platform dependent issue or
a feature of the tun driver in 2.4.14
I suppose the latter since tun driver
is after all a quite high level one.
I also added a new optional command line
parameter to change the /dev/net/tun to
point somewhere else to avoid reflashing :-)
I included a patch agains openvpn-1.2.0
if someone else has similar problem.
Syntax is as fallows:
--tundev /tmp/tun
Thanks to you all for this beautiful software.
As an user space program it was mutch more
easy to port than freeswan, since kernel hackin'
would have required a million reflashings and
a great deal of serial debugging, since our
device has no display.
Sampo Nurmentaus
>
> Thanks James,
>
> It really helped. Simple recrosscompiling first kernel
> and then openvpn fixed it.
>
> And now I have faced a new one :-(
>
> ioctl on line 216 in tun.c (TUNSETIFF) seems to fail
> complainin' about Invalid argument with errno 22.
> I use tun driver shipped with 2.4.14 kernel and
> if_tun.h which is identical to one in the kernel
> source tree.
>
> Any ideas?
>
>
> Sampo Nurmentaus
>
>
>
> > From: "Sampo Nurmentaus" <audiopoppi...@audioriders.fi>
> > To: <openvpn-devel@lists.sourceforge.net>
> > Sent: Wednesday, June 12, 2002 8:31 AM
> > Subject: [Openvpn-devel] Porting to an embedded linux
> >
> >
> > > Hello folks,
> > >
> > >
> > > I have been recently busy porting openssl, openssh
> > > and openvpn to our embended linux environment
> > > build on etrax 100lx processor from axis communications.
> > >
> > > Openvpn's code was, thanks to you guys, quite easy to
> > > port but then I ran into problems when open vpn tries
> > > to ioctl tun device:
> > >
> > > ....
> > > 65: Static Decrypt: Cipher 'BF-CBC' initialized with 128 bit key
> > > 66: Static Decrypt: Using 160 bit message digest 'SHA1' for HMAC
> > > authentication
> > > 67: Data Channel MTU parms: mtu=1456 extra_frame=44 extra_buffer=44
> > > extra_tun=0
> > > 68: Cannot ioctl TUNSETIFF tun0: File descriptor in bad state (errno=77)
> > > 69: Exiting
> > >
> > >
> > > I have changed device to locate
> > > in /tmp/tun, but that shuld not couse this kind of problems.
> > > /dev is on flash image so it is easier to use /tmp for testing.
> > > I created the device as should with:
> > > mknod /tmp/tun c 10 200
> > >
> > > If I try to cat tun device read returns with the very same
> > > error text.
> > >
> > > I compiled support to kernel (not as a module)
> > > so it should always be there.
> > >
> > >
> > > Any ideas?
> >
> > Sampo,
> >
> > See message below from a previous thread on openvpn-users, and with
> > references to vtun list.
> >
> > James
> >
> > >
> > > Thanx in advange,
> > >
> > > Sampo Nurmentaus
> >
> > James Yonan wrote:
> > >>Hi James,
> > >>
> > >>Thank you for your prompt and detailed reply. What was happening
> > >>earlier was that I built openvpn first, then realized I needed to build
> > >>the tun/tap kernel module, so built that and then rebuilt openvpn - but
> > >>configure (god bless it) used the cached result of NOT finding if_tun.h.
> > >> I cleared configure's cache and rebuilt it again - this time it found
> > >>"tun/tap v1.4". Now I'm onto a new set of problems though. Now I get:
> > >>
> > >>34: Cannot ioctl TUNSETIFF tun: File descriptor in bad state (errno=77)
> > >
> > >
> > > Though I've never seen this error personally, it has been talked about
> > > extensively on the vtun list (another tunneling daemon that uses the
> > TUN/TAP
> > > driver).
> > >
> > > Go to http://sourceforge.net/mailarchive/forum.php?forum_id=1826
> > >
> > > and search for "bad state".
> > >
> > > It appears to be caused by a mismatch between the tun/tap kernel module
> > and
> > > the kernel itself.
> > >
> > > What kernel version are you using?
> > >
> > > Because in versions 2.4.6 and higher, the TUN/TAP module is integral to
> > the
> > > kernel -- if you try to build an external version of the module, rather
> > than
> > > using the one already bundled, it will likely fail.
> >
> > Also I've read a few posts that suggest that /usr/src/linux needs to point
> > to headers that match the running kernel. Depending on what Sean has, it
> > may be worthwhile to ensure all the various versions
> > (kernel/headers/tunTap) all match.
> >
> >
> >
> > _______________________________________________________________
> >
> > Sponsored by:
> > ThinkGeek at http://www.ThinkGeek.com/
> > _______________________________________________
> > Openvpn-devel mailing list
> > Openvpn-devel@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/openvpn-devel
> >
>
>
> _______________________________________________________________
>
> Don't miss the 2002 Sprint PCS Application Developer's Conference
> August 25-28 in Las Vegas -
> http://devcon.sprintpcs.com/adp/index.cfm?source=osdntextlink
>
> _______________________________________________
> Openvpn-devel mailing list
> Openvpn-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/openvpn-devel
>
47a48,49
> #include <assert.h>
>
553c555
< open_tun (options->dev, options->dev_type, &tuntap);
---
> open_tun (options->tundev,options->dev, options->dev_type, &tuntap);
1372c1374
< tuncfg (options.dev, options.dev_type, options.persist_mode);
---
> tuncfg (options.tundev,options.dev, options.dev_type,
> options.persist_mode);
1388,1389c1390,1399
< notnull (options.dev, "tun/tap device (--dev)");
<
---
> {
> notnull (options.dev, "tun/tap device (--dev)");
> if (options.tundev == NULL)
> {
> assert(options.tundev =
> (char *) malloc(strlen("/dev/net/tun")+1));
> sprintf(options.tundev,"/dev/net/tun");
> }
> }
>
587a588,592
> else if (streq (p1, "tundev") && p2)
> {
> ++i;
> options->tundev = p2;
> }
diff -r openvpn-1.2.0/options.h axis/devboard_lx/apps/openvpn/options.h
53a54
> char *tundev;
diff -r openvpn-1.2.0/syshead.h axis/devboard_lx/apps/openvpn/syshead.h
133c133
<
---
> /*
136a137,139
> */
>
> #include </home/sabe/axis/devboard_lx/os/linux/include/linux/if_tun.h>
diff -r openvpn-1.2.0/tun.c axis/devboard_lx/apps/openvpn/tun.c
181c181
< open_tun (const char *dev, const char* dev_type, struct tuntap *tt)
---
> open_tun (const char *device,const char *dev, const char* dev_type, struct
> tuntap *tt)
184c184
< static const char device[] = "/dev/net/tun";
---
> // static const char device[] = "/tmp/hd/tun";
218c218
<
---
>
228c228
< tuncfg (const char *dev, const char *dev_type, int persist_mode)
---
> tuncfg (const char *tundev,const char *dev, const char *dev_type, int
> persist_mode)
232c232
< open_tun (dev, dev_type, &tt);
---
> open_tun (tundev,dev, dev_type, &tt);
diff -r openvpn-1.2.0/tun.h axis/devboard_lx/apps/openvpn/tun.h
41c41
< void open_tun (const char *dev, const char* dev_type, struct tuntap *tt);
---
> void open_tun (const char *tundev,const char *dev, const char* dev_type,
> struct tuntap *tt);
47c47
< void tuncfg (const char *dev, const char *dev_type, int persist_mode);
---
> void tuncfg (const char *tundev, const char *dev, const char *dev_type, int
> persist_mode);
