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