Re: [Openvpn-devel] Fwd: Bug#182020: openvpn needs dynamic choice on HAVE_LINUX_IF_TUN_H

[Matthias Andree]

On Thu, 08 May 2003, James Yonan wrote:

> 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.

This may not be true for build hosts of a distributor, who needs the
most conservative code if he's still shipping 2.2 kernels (as Debian).

> 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.

Think "binary package": built on a 2.4 machine, installed onto a
different 2.2 machine.

Re: [Openvpn-devel] 1.4.0 Released

[Matthias Andree]

On Thu, 08 May 2003, James Yonan wrote:

> Release Notes:
> 
> This release adds options for persistence of replay protection information
> across sessions, pass through of IPv4 TOS bits from the TUN/TAP device to the
> UDP link, some advanced MTU control options, moderate revamping of the build
> system to improve portability, and misc bug fixes and web site additions.
> 
> Also new is a major restructuring of MTU and fragmentation handling. Much of
> this code is experimental and must be explicitly enabled by defining
> FRAGMENT_ENABLE and rebuilding.

I have sent in an update for the FreeBSD port, but it does not include
the FRAGMENT_ENABLE code, just the default options.

Re: [Openvpn-devel] Fwd: Bug#182020: openvpn needs dynamic choice on HAVE_LINUX_IF_TUN_H

[Alberto Gonzalez Iniesta]

On Thu, May 08, 2003 at 08:30:34AM -, James Yonan wrote:
> Alberto Gonzalez Iniesta  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.
> > 
> > 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.
> > 


-- 
Alberto Gonzalez Iniesta   | BOFH excuse #99:
agi@(agi.as|debian.org)| SIMM crosstalk.
Encrypted mail preferred   | 

Key fingerprint = 9782 04E7 2B75 405C F5E9  0C81 C514 AF8E 4BA4 01C3

Re: [Openvpn-devel] an idea for openvpn..

[James Yonan]

Aaron,

I've found that the linux scheduler on 2.4 does a fairly good job at giving
openvpn the CPU that it needs, even on a more heavily loaded system.  When
openvpn is forwarding tunnel packets, it is essentially i/o bound, and as such
gets a priority boost.  When TLS keys are being negotiated, however, openvpn
becomes a CPU hog for as much as several seconds, so you wouldn't want to lock
up the machine during this period, especially given the fact that TLS
renegotiations are not in the critical path of tunnel packet forwarding
operations.  Overall, it's not clear to me that we need more scheduling
flexibility than --nice or --nice-work can give us.  And nice scheduling has
the safety factor as well of never completely locking up the machine, even if
something of high priority does a CPU grab.

James

Aaron Sethman  said:

> 
> One of the things that I just thought about is, that we can probably have
> openvpn call sched_setscheduler() using something like SCHED_RR.  This
> might be of more use than just renicing the process.  Considering we are
> in a fairly performance critical path for a userspace process this would
> seem to make sense.  Not sure how to deal with SCHED_RR wrt to threads
> though.  On my systems I haven't noticed much of a difference, when doing
> this, but my systems aren't heavily loaded either.
> 
> Thoughts, comments?
> 
> -Aaron
> 
> 
> ---
> Enterprise Linux Forum Conference & Expo, June 4-6, 2003, Santa Clara
> The only event dedicated to issues related to Linux enterprise solutions
> www.enterpriselinuxforum.com
> 
> ___
> Openvpn-devel mailing list
> Openvpn-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/openvpn-devel
> 



--