Alberto,
Here is a patch against 1.4.0 that tries the 2.4 TUN/TAP interface then
falls back to 2.2 if it fails. I don't have access to a 2.2 machine so I
have not been able to test. Let me know if it works.
James
On Thu, 8 May 2003, Alberto Gonzalez Iniesta wrote:
> On Thu, May 08, 2003 at 08:30:34AM -0000, James Yonan wrote:
> > Alberto Gonzalez Iniesta <a...@agi.as> said:
> >
> > > When compiled with 2.4.* kernel headers (libc6-dev 2.2.5-14.3 headers)
> > > it detects this header file and defines HAVE_LINUX_IF_TUN_H. This allow
> > > openvpn to work correctly with 2.4.18 kernels BUT it stops it working
> > > with 2.2.X kernels at all (with or without the tun kernel module from
> > > sourceforge)
> >
> > OpenVPN's config script assumes that if 2.4 headers are present (i.e.
> > if_tun.h), then it should build for the 2.4 tun/tap driver.
> >
> > I don't completely understand why one would want to put 2.4 kernel headers
> > on
> > a 2.2 machine, since that would tend to confuse things, and break apps that
> > depend on the userspace <-> kernel interface as defined by the kernel header
> > files.
>
> The problem (again) is distributing binaries. I compile Debian's
> packages in my 2.4.x box, but those packages may be used in 2.2 boxes.
> I could find a 2.2 box (could I?) to compile them, but then the problem
> would be the other way around, wouldn't it?
>
> So, and as the bug reported says, we have two choices:
>
> a) I make two binaries in the package, and choose at installation time
> which one should be used. (will uname -r do? I guess so)
> b) openvpn detects at run time which tun interface to use.
>
> pros? cons?
>
> Regards,
>
> Alberto
>
>
> > But in any case, you can still build if you do the following.
> >
> > (1) run ./configure
> > (2) edit config.h
> > (3) comment out this line: #define HAVE_LINUX_IF_TUN_H 1
> > (4) run make
> >
> > This could be automatic if ./configure did a kernel version test, and only
> > defined HAVE_LINUX_IF_TUN_H if (a) if_tun.h exists and (b) kernel version is
> > 2.4.x.
> >
> > James
> >
> > > Options are:
> > >
> > > 1) Seperate compiles for 2.2.X and 2.4+ kernels, both binaries in the .deb
> > >
> > > 2) Patch tun.c to first check if /dev/net/tun exists and works before
> > > falling back to the open_tun_generic(..) function if it doesn't.
Here is a patch against 1.4.0 that does this (attached). I don't have
access to a 2.2 machine so I have not been able to test.
> > >
> > > I'm currently successfully using openvpn between a 2.2.19 and 2.4.18
> > > kernel using the tun0 tunnel and the driver from sourceforge on the 2.2.19
> > > machine. (No reboot required to install the tun0 driver) The 2.4.18
> > > openvpn is standard, the 2.2.19 has HAVE_LINUX_IF_TUN_H undefined.
> > >
> > > Both machines are woody with libc6/testing.
> > >
>
>
>
--- openvpn-1.4.0/tun.c Sat May 3 04:57:07 2003
+++ openvpn-new/tun.c Thu May 8 12:54:02 2003
@@ -375,10 +375,14 @@
}
else
{
- if (!dev_node)
- dev_node = "/dev/net/tun";
- if ((tt->fd = open (dev_node, O_RDWR)) < 0)
- msg (M_ERR, "Cannot open TUN/TAP dev %s", dev_node);
+ const char *node = dev_node;
+ if (!node)
+ node = "/dev/net/tun";
+ if ((tt->fd = open (node, O_RDWR)) < 0)
+ {
+ msg (M_WARN | M_ERRNO, "Note: Cannot open TUN/TAP dev %s", node);
+ goto linux_2_2_fallback;
+ }
CLEAR (ifr);
if (!tt->ipv6)
@@ -401,7 +405,10 @@
strncpynt (ifr.ifr_name, dev, IFNAMSIZ);
if (ioctl (tt->fd, TUNSETIFF, (void *) &ifr) < 0)
- msg (M_WARN, "Cannot ioctl TUNSETIFF %s", dev);
+ {
+ msg (M_WARN | M_ERRNO, "Note: Cannot ioctl TUNSETIFF %s", dev);
+ goto linux_2_2_fallback;
+ }
set_nonblock (tt->fd);
set_cloexec (tt->fd);
@@ -433,6 +440,12 @@
}
}
}
+ return;
+
+ linux_2_2_fallback:
+ msg (M_INFO, "Note: Attempting fallback to kernel 2.2 TUN/TAP interface");
+ close_tun_generic (tt);
+ open_tun_generic (dev, dev_node, dev_name, ipv6, false, true, tt);
}
#else
