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

[Alberto Gonzalez Iniesta]

Hi all, 

Sorry for the delay forwarding this email, but I don't find time to 
breath lately (and thus Oxygen does not make it to my brain :)

Hope it's an easy one.


- Forwarded message from Robert de Bath  -

From: Robert de Bath 
Reply-To: Robert de Bath , 182...@bugs.debian.org
To: sub...@bugs.debian.org
Subject: Bug#182020: openvpn needs dynamic choice on HAVE_LINUX_IF_TUN_H
List-Post: openvpn-devel@lists.sourceforge.net
Date: Sat, 22 Feb 2003 11:03:19 + (GMT)
X-URL: 
X-Dev86-Version: 0.16.10
Reply-By: 01 jan 2001 00:00:00
X-Message-Flag: Linux: The choice of a GNU generation.
Return-Receipt-To: recei...@mayday.cix.co.uk
X-Spam-Level: 
X-SpamProbe: GOOD 0.000 f10cd08f2b096e6bf59bcfea5e2f80a4
X-Spam-Status: No, hits=-4.5 required=5.0 tests=SENT_BY_BTS,FORGED_RCVD_FOUND 
version=2.20
X-Spam-Level: 

Package: openvpn
Version: 1.3.0-2

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)

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.

-- 
Rob.  (Robert de Bath )
   
Google Homepage:   http://www.google.com/search?btnI&q=Robert+de+Bath


- End forwarded message -

-- 
Alberto Gonzalez Iniesta   | BOFH excuse #2:
agi@(agi.as|debian.org)| solar flares
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
> 



-- 

[Openvpn-devel] 1.4.0 Released

[James Yonan]

Download:

http://sourceforge.net/projects/openvpn/

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.

Change Log:

* Added --replay-persist feature to allow replay
  protection across sessions.
* Fixed bug where --ifconfig could not be used
  with --tun-mtu.
* Added --tun-mtu-extra parameter to deal with
  the situation where a read on a TUN/TAP device
  returns more data than the device's MTU size.
* Fixed bug where some IPv6 support code for
  Linux was not being properly ifdefed out for
  Linux 2.2, causing compile errors.
* Added OPENVPN_EXIT_STATUS_x codes to
  openvpn.h to control which status value
  openvpn returns to its caller (such as
  a shell or inetd/xinetd) for various conditions.
* Added OPENVPN_DEBUG_COMMAND_LINE flag to
  openvpn.h to allow debugging in situations
  where stdout, stderr, and syslog cannot be used
  for message output, such as when OpenVPN is
  instantiated by inetd/xinetd.
* Removed owner-execute permission from file
  created by static key generator (Herbert Xu
  and Alberto Gonzalez Iniesta).
* Added --passtos option to allow IPv4 TOS bits
  to be passed from TUN/TAP input packets to
  the outgoing UDP socket (Craig Knox).
* Added code to prevent open socket file descriptors
  from being accessible to called scripts.
* Added --dev-name option (Christian Lademann).
* Added --mtu-disc option for manual control
  over MTU options.
* Show OS MTU value on UDP socket write failures
  (linux only).
* Numerous build system and portability
  fixes (Matthias Andree).
* Added better sensing of compiler support for
  variable argument macros, including (a) gcc
  style, (b) ISO C 1999 style, and (c) no support.
* Removed generated files from CVS.  Note INSTALL
  file for new CVS build commands.
* Changed all internal _* symbols to x_*
  for C standards compliance.
* Added TUN/TAP open code to cycle dynamically
  through unit numbers until it finds a free
  unit (based on code from Thomas Gielfeldt
  and VTun).
* Added dynamic MTU and fragmenting infrastructure
  (Experimental).  Rebuild with FRAGMENT_ENABLE
  defined to enable.
* Minor changes to SSL/TLS negotiation, use
  exponential backoff on retransmits, and use
  a smaller MTU size (note that no protocol
  changes have been made which would break
  compatibility with 1.3.x).
* Added --enable-strict-options flag
  to ./configure.  This option will cause
  a more strict check for options compatibility
  between peers when SSL/TLS negotiation is used,
  but should only be used when both OpenVPN peers
  are of the same version.
* Reorganization of debugging levels.
* Added a workaround in configure.ac for
  default SSL header location on Linux
  to fix RH9 build problem.
* Fixed potential deadlock when pthread support
  is used on OSes that allocate a small socketpair()
  message buffer.
* Fixed openvpn.init to be sh compliant
  (Bishop Clark).
* Changed --daemon to wait until all
  initialization is finished before becoming a
  daemon, for the benefit of initialization
  scripts that want a useful return status from
  the openvpn command.
* Made openvpn.init script more robust, including
  positive indication of initialization errors
  in the openvpn daemon and better sanity checks.
* Changed --chroot to wait until initialization
  is finished before calling chroot(), and allow
  the use of --user and --group with --chroot.
* When syslog logging is enabled (--daemon or
  --inetd), set stdin/stdout/stderr to point
  to /dev/null.
* For inetd instantiations, dup socket descriptor
  to a >2 value.
* Fixed bug in verify-cn script, where test would
  incorrectly fail if CN=x was the last component
  of the X509 composite string (Anonymous).
* Added Markus F.X.J. Oberhumer's special
  license exception to COPYING.

James

[Openvpn-devel] an idea for openvpn..

[Aaron Sethman]

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