openvpn-devel — OpenVPN developers list

Re: [Openvpn-devel] Another pre-1.3.2 beta

[Matthias A. <ma+...@dt...>]

On Sun, 20 Oct 2002, James Yonan wrote:

> Changes since last beta:
> 
> * Added inetd/xinetd support (--inetd) including
>   documentation in the HOWTO.

Works for me. Thanks.

[Openvpn-devel] Another pre-1.3.2 beta

[James Y. <ji...@yo...>]

Another beta is available to test.  This one adds support and documentation for on-demand xinetd instantiation of the openvpn daemon.

Changes since last beta:

* Added FreeBSD 4.1.1+ TUN/TAP driver notes to
  INSTALL (Matthias Andree).
* Added inetd/xinetd support (--inetd) including
  documentation in the HOWTO.

Download from CVS or:

http://openvpn.sourceforge.net/beta/openvpn-1.3.1.10.tar.gz

Beta version of the website is here with some additions to the documentation and HOWTO:

http://openvpn.sourceforge.net/beta/www/

James

Re: [Openvpn-devel] New pre-1.3.2 beta available, please test

[James Y. <ji...@yo...>]

Matthias,

Thanks, I've merged with CVS.

James

Matthias Andree <ma+...@dt...> said:

> On Thu, 17 Oct 2002, James Yonan wrote:
> 
> > 
> > Here is the latest pre-1.3.2 beta that now supports IPv6 over tun on Linux.  Please test.  I plan to release 1.3.2 shortly if there are no problems reported.
> 
> No problems, just documentation about FreeBSD. Most of this has been
> filed as update against FreeBSD's 1.3.0 port.
> 
> FreeBSD currently installs tap0...tap3 and tun0...tun3 by default.
> 
> The FreeBSD GENERIC kernel has tun support compiled in, no further work
> necessary. However, for tap support, the admin must execute "kldload
> if_tap" once (or he can recompile and install the kernel after adding
> the line "pseudo-device tap").
> 
> (kldload is called insmod on Linux, rmmod -> kldunload, lsmod ->
> kldstat).
> 
> I suggest this patch (against CVS) -- it also includes two whitespace
> fixes, so don't copy & paste, but pipe it into patch:
> 
> Index: INSTALL
> ===================================================================
> RCS file: /cvsroot/openvpn/openvpn/INSTALL,v
> retrieving revision 1.22
> diff -u -r1.22 INSTALL
> --- INSTALL~	28 Jul 2002 07:54:57 -0000	1.22
> +++ INSTALL	18 Oct 2002 23:33:02 -0000
> @@ -152,20 +152,35 @@
>    openvpn.init script, these steps are taken care of for you.
>  
>  * Linux 2.2 or Solaris:
> - 
> +
>    You should obtain
>    version 1.1 of the TUN/TAP driver from
>    http://vtun.sourceforge.net/tun/
>    and follow the installation instructions.
>  
> +* FreeBSD 4.1.1+:
> +
> +  FreeBSD ships with the TUN/TAP driver, and the device nodes for tap0,
> +  tap1, tap2, tap3, tun0, tun1, tun2 and tun3 are made by default.
> +  However, only the TUN driver is linked into the GENERIC kernel.
> +
> +  To load the TAP driver, enter: 
> +
> +	kldload if_tap
> +
> +  See man rc(8) to find out how you can do this at boot time.
> +
> +  The easiest way is to install OpenVPN from the FreeBSD ports system,
> +  the port includes a sample script to automatically load the tap driver
> +  at boot-up time.
> +
>  * OpenBSD:
>  
>    OpenBSD ships with tun0 and tun1 installed by default.
>  
>  * Mac OS X:
>  
> -  Obtain Christoph Pfisterer's
> -  tun driver at
> +  Obtain Christoph Pfisterer's tun driver at
>    http://chrisp.de/en/projects/tunnel.html
>  
>   See the man page for more information, usage examples, and
> 
> -- 
> Matthias Andree
> 
> 
> -------------------------------------------------------
> This sf.net email is sponsored by:
> Access Your PC Securely with GoToMyPC. Try Free Now
> https://www.gotomypc.com/s/OSND/DD
> _______________________________________________
> Openvpn-devel mailing list
> Ope...@li...
> https://lists.sourceforge.net/lists/listinfo/openvpn-devel
> 



-- 

Re: [Openvpn-devel] New pre-1.3.2 beta available, please test

[Matthias A. <ma+...@dt...>]

On Thu, 17 Oct 2002, James Yonan wrote:

> 
> Here is the latest pre-1.3.2 beta that now supports IPv6 over tun on Linux.  Please test.  I plan to release 1.3.2 shortly if there are no problems reported.

No problems, just documentation about FreeBSD. Most of this has been
filed as update against FreeBSD's 1.3.0 port.

FreeBSD currently installs tap0...tap3 and tun0...tun3 by default.

The FreeBSD GENERIC kernel has tun support compiled in, no further work
necessary. However, for tap support, the admin must execute "kldload
if_tap" once (or he can recompile and install the kernel after adding
the line "pseudo-device tap").

(kldload is called insmod on Linux, rmmod -> kldunload, lsmod ->
kldstat).

I suggest this patch (against CVS) -- it also includes two whitespace
fixes, so don't copy & paste, but pipe it into patch:

Index: INSTALL
===================================================================
RCS file: /cvsroot/openvpn/openvpn/INSTALL,v
retrieving revision 1.22
diff -u -r1.22 INSTALL
--- INSTALL~	28 Jul 2002 07:54:57 -0000	1.22
+++ INSTALL	18 Oct 2002 23:33:02 -0000
@@ -152,20 +152,35 @@
   openvpn.init script, these steps are taken care of for you.
 
 * Linux 2.2 or Solaris:
- 
+
   You should obtain
   version 1.1 of the TUN/TAP driver from
   http://vtun.sourceforge.net/tun/
   and follow the installation instructions.
 
+* FreeBSD 4.1.1+:
+
+  FreeBSD ships with the TUN/TAP driver, and the device nodes for tap0,
+  tap1, tap2, tap3, tun0, tun1, tun2 and tun3 are made by default.
+  However, only the TUN driver is linked into the GENERIC kernel.
+
+  To load the TAP driver, enter: 
+
+	kldload if_tap
+
+  See man rc(8) to find out how you can do this at boot time.
+
+  The easiest way is to install OpenVPN from the FreeBSD ports system,
+  the port includes a sample script to automatically load the tap driver
+  at boot-up time.
+
 * OpenBSD:
 
   OpenBSD ships with tun0 and tun1 installed by default.
 
 * Mac OS X:
 
-  Obtain Christoph Pfisterer's
-  tun driver at
+  Obtain Christoph Pfisterer's tun driver at
   http://chrisp.de/en/projects/tunnel.html
 
  See the man page for more information, usage examples, and

-- 
Matthias Andree

[Openvpn-devel] New pre-1.3.2 beta available, please test

[James Y. <ji...@yo...>]

Here is the latest pre-1.3.2 beta that now supports IPv6 over tun on Linux.  Please test.  I plan to release 1.3.2 shortly if there are no problems reported.

Download from CVS or

http://openvpn.sourceforge.net/beta/openvpn-1.3.1.7.tar.gz

Change Log:

* Added SSL_CTX_set_client_CA_list call
  to follow the canonical form for TLS initialization
  recommended by the OpenSSL docs.  This change allows
  better support for intermediate CAs and has no impact
  on security.
* Added build-inter script to easy-rsa package, to
  facilitate the generation of intermediate CAs.
* Ported to NetBSD (Dimitri Goldin).
* Fixed minor bug in easy-rsa/sign-req.  It refers to
  openssl.cnf file, instead of $KEY_CONFIG, like all
  other scripts (Ernesto Baschny).
* Added --days 3650 to the root CA generation command
  in the HOWTO to override the woefully small 30 day
  default (Dominik 'Aeneas' Schnitzer).
* Fixed bug where --ping-restart would sometimes
  not re-resolve remote DNS hostname.
* Added --tun-ipv6 option and related infrastructure
  support for IPv6 over tun.
* Added IPv6 over tun support for Linux (Aaron Sethman).
* Added "Important Note on the use of commercial certificate
  authorities (CAs) with OpenVPN" to HOWTO based on
  issues raised on the openvpn-users list.

James

Re: [Openvpn-devel] tunnelling ipv6 on linux

[Aaron S. <and...@ra...>]

On Fri, 4 Oct 2002, James Yonan wrote:

> Hi Aaron,
>
> I've incorporated your IPv6 over tun patch for Linux into the latest OpenVPN beta, and added some basic infrastructure code and a --tun-ipv6 option which enables the IPv6 over tun support.  The option makes a placeholder for all OSes to support IPv6 over tun that is off by default and does not break any existing usage.
>
> Beta is available here and on CVS:
>
> http://openvpn.sourceforge.net/beta/openvpn-1.3.1.6.tar.gz
>
> My IPv6 testing capabilities are limited at this point, so please test.
I've tested between two Linux boxes and it seems to be working perfect at
this point.  I'll give it some more testing and see how it goes.  I'll
also look into testing on a Solaris box, but I'm guessing that will need
some extra help to get working.

Regards,

Aaron

Re: [Openvpn-devel] tunnelling ipv6 on linux

[James Y. <ji...@yo...>]

Hi Aaron,

I've incorporated your IPv6 over tun patch for Linux into the latest OpenVPN beta, and added some basic infrastructure code and a --tun-ipv6 option which enables the IPv6 over tun support.  The option makes a placeholder for all OSes to support IPv6 over tun that is off by default and does not break any existing usage.

Beta is available here and on CVS:

http://openvpn.sourceforge.net/beta/openvpn-1.3.1.6.tar.gz

My IPv6 testing capabilities are limited at this point, so please test.

Best Regards,
James

Aaron Sethman <and...@ra...> said:

> 
> 
> On Sat, 28 Sep 2002, James Yonan wrote:
> 
> > Aaron,
> >
> > Thanks for the patch, however I was not able to get it to work with IPv4 while talking between a 2.4.9 and 2.4.17 kernel, where both peers are running the patch.  The code compiles and runs, but pings don't go through.  Perhaps there is a minimum kernel version necessary for this to work?  Does the kernel need to be built with IPv6 support in order for this code to work with IPv4?
> Well, it shouldn't require any IPv6 support in the kernel to simply pass
> IPv4 packets.  I'll need to look at the tun driver in 2.4.9.  Both of my
> machines here are running 2.4.19.
> >
> > There is also the issue of breaking protocol compatibility by adding the ETH_P_IPV6/ETH_P_IP to the IP-over-tun packet encoding.  I would propose that:
> Well, it doesn't break the protocol at all, what ends up happening is, the
> kernel takes the tun_pi header and strips it off, so those headers never
> get sent on the wire.
> 
>  >
> > (1) We run-time conditionalize your patch on a --tun-ipv6 option.
> 
> >
> > (2) We compile-time (e.g. #ifdef bracket on HAVE_NETINET_IF_ETHER_H, ETH_P_IPV6, etc.) and/or run-time conditionalize so that usage of --tun-ipv6 produces a run-time error if ipv6 over tun is not supported.
> That sounds like a good idea.
> >
> > (3) We add --tun-ipv6 enabled/disabled state to the options_string function in options.h as a sanity check between peers.
> >
> > (4) We think about how to make --tun-ipv6 portable across the platforms which OpenVPN supports.  This may be better addressed at the tun driver level, to reduce the machine-specific ugliness in tun.c?
> Well, this one might be a bit more difficult if the tunnel driver doesn't
> support it, of course it might be worth the effort to submit patches to
> the respective OSes for this.
> 
> >
> > (5) We look into making an ipv6 option for the tunnel UDP channel and endpoints as well.
> This part shouldn't be much of a problem.
> 
> Regards,
> 
> Aaron
> 



-- 

Re: [Openvpn-devel] tunnelling ipv6 on linux

[Aaron S. <and...@ra...>]

On Sat, 28 Sep 2002, James Yonan wrote:

> Aaron,
>
> Thanks for the patch, however I was not able to get it to work with IPv4 while talking between a 2.4.9 and 2.4.17 kernel, where both peers are running the patch.  The code compiles and runs, but pings don't go through.  Perhaps there is a minimum kernel version necessary for this to work?  Does the kernel need to be built with IPv6 support in order for this code to work with IPv4?
Well, it shouldn't require any IPv6 support in the kernel to simply pass
IPv4 packets.  I'll need to look at the tun driver in 2.4.9.  Both of my
machines here are running 2.4.19.
>
> There is also the issue of breaking protocol compatibility by adding the ETH_P_IPV6/ETH_P_IP to the IP-over-tun packet encoding.  I would propose that:
Well, it doesn't break the protocol at all, what ends up happening is, the
kernel takes the tun_pi header and strips it off, so those headers never
get sent on the wire.

 >
> (1) We run-time conditionalize your patch on a --tun-ipv6 option.

>
> (2) We compile-time (e.g. #ifdef bracket on HAVE_NETINET_IF_ETHER_H, ETH_P_IPV6, etc.) and/or run-time conditionalize so that usage of --tun-ipv6 produces a run-time error if ipv6 over tun is not supported.
That sounds like a good idea.
>
> (3) We add --tun-ipv6 enabled/disabled state to the options_string function in options.h as a sanity check between peers.
>
> (4) We think about how to make --tun-ipv6 portable across the platforms which OpenVPN supports.  This may be better addressed at the tun driver level, to reduce the machine-specific ugliness in tun.c?
Well, this one might be a bit more difficult if the tunnel driver doesn't
support it, of course it might be worth the effort to submit patches to
the respective OSes for this.

>
> (5) We look into making an ipv6 option for the tunnel UDP channel and endpoints as well.
This part shouldn't be much of a problem.

Regards,

Aaron

Re: [Openvpn-devel] tunnelling ipv6 on linux

[James Y. <ji...@yo...>]

Aaron,

Thanks for the patch, however I was not able to get it to work with IPv4 while talking between a 2.4.9 and 2.4.17 kernel, where both peers are running the patch.  The code compiles and runs, but pings don't go through.  Perhaps there is a minimum kernel version necessary for this to work?  Does the kernel need to be built with IPv6 support in order for this code to work with IPv4?

There is also the issue of breaking protocol compatibility by adding the ETH_P_IPV6/ETH_P_IP to the IP-over-tun packet encoding.  I would propose that:

(1) We run-time conditionalize your patch on a --tun-ipv6 option.

(2) We compile-time (e.g. #ifdef bracket on HAVE_NETINET_IF_ETHER_H, ETH_P_IPV6, etc.) and/or run-time conditionalize so that usage of --tun-ipv6 produces a run-time error if ipv6 over tun is not supported.

(3) We add --tun-ipv6 enabled/disabled state to the options_string function in options.h as a sanity check between peers.

(4) We think about how to make --tun-ipv6 portable across the platforms which OpenVPN supports.  This may be better addressed at the tun driver level, to reduce the machine-specific ugliness in tun.c?

(5) We look into making an ipv6 option for the tunnel UDP channel and endpoints as well.

Thanks again for your contribution, and if we can deal with these issues, especially as they affect protocol compatibility, I will have no problem merging your patch.

James

Aaron Sethman <and...@ra...> said:

> 
> I've done some work on getting openvpn to tunnel ipv6 without having to
> use TAP tunnels.  I think to get ipv6 tunneling to work on other platforms
> it may require changes in the tunnel driver.  But I figure I'll post this
> here as it might be of use to somebody.
> 
> Regards,
> 
> Aaron
> 
> 
> 
> Index: Makefile.in
> ===================================================================
> RCS file: /cvsroot/openvpn/openvpn/Makefile.in,v
> retrieving revision 1.6
> diff -u -r1.6 Makefile.in
> --- Makefile.in	25 Jun 2002 06:56:16 -0000	1.6
> +++ Makefile.in	27 Sep 2002 22:41:09 -0000
> @@ -1,4 +1,4 @@
> -# Makefile.in generated by automake 1.6.1 from Makefile.am.
> +# Makefile.in generated by automake 1.6.3 from Makefile.am.
>  # @configure_input@
> 
>  # Copyright 1994, 1995, 1996, 1997, 1998, 1999, 2000, 2001, 2002
> @@ -74,6 +74,7 @@
>  INSTALL_DATA = @INSTALL_DATA@
>  install_sh_DATA = $(install_sh) -c -m 644
>  install_sh_PROGRAM = $(install_sh) -c
> +install_sh_SCRIPT = $(install_sh) -c
>  INSTALL_SCRIPT = @INSTALL_SCRIPT@
>  INSTALL_HEADER = $(INSTALL_DATA)
>  transform = @program_transform_name@
> @@ -170,6 +171,9 @@
> 
>  .SUFFIXES:
>  .SUFFIXES: .c .o .obj
> +
> +am__CONFIG_DISTCLEAN_FILES = config.status config.cache config.log \
> + configure.lineno
>  $(srcdir)/Makefile.in:  Makefile.am  $(top_srcdir)/configure.ac $(ACLOCAL_M4)
>  	cd $(top_srcdir) && \
>  	  $(AUTOMAKE) --gnu  Makefile
> @@ -199,7 +203,7 @@
>  	touch $(srcdir)/config.h.in
> 
>  distclean-hdr:
> -	-rm -f config.h
> +	-rm -f config.h stamp-h1
>  sbinPROGRAMS_INSTALL = $(INSTALL_PROGRAM)
>  install-sbinPROGRAMS: $(sbin_PROGRAMS)
>  	@$(NORMAL_INSTALL)
> @@ -208,8 +212,7 @@
>  	  p1=`echo $$p|sed 's/$(EXEEXT)$$//'`; \
>  	  if test -f $$p \
>  	  ; then \
> -	    p1=`echo "$$p1" | sed -e 's,^.*/,,'`; \
> -	    f=`echo $$p1|sed '$(transform);s/$$/$(EXEEXT)/'`; \
> +	    f=`echo "$$p1" | sed 's,^.*/,,;$(transform);s/$$/$(EXEEXT)/'`; \
>  	   echo " $(INSTALL_PROGRAM_ENV) $(sbinPROGRAMS_INSTALL) $$p $(DESTDIR)$(sbindir)/$$f"; \
>  	   $(INSTALL_PROGRAM_ENV) $(sbinPROGRAMS_INSTALL) $$p $(DESTDIR)$(sbindir)/$$f; \
>  	  else :; fi; \
> @@ -218,8 +221,7 @@
>  uninstall-sbinPROGRAMS:
>  	@$(NORMAL_UNINSTALL)
>  	@list='$(sbin_PROGRAMS)'; for p in $$list; do \
> -	  f=`echo $$p|sed 's/$(EXEEXT)$$//;$(transform);s/$$/$(EXEEXT)/'`; \
> -	  f=`echo "$$f" | sed -e 's,^.*/,,'`; \
> +	  f=`echo "$$p" | sed 's,^.*/,,;s/$(EXEEXT)$$//;$(transform);s/$$/$(EXEEXT)/'`; \
>  	  echo " rm -f $(DESTDIR)$(sbindir)/$$f"; \
>  	  rm -f $(DESTDIR)$(sbindir)/$$f; \
>  	done
> @@ -286,6 +288,10 @@
>  	  if test -f $(srcdir)/$$i; then file=$(srcdir)/$$i; \
>  	  else file=$$i; fi; \
>  	  ext=`echo $$i | sed -e 's/^.*\\.//'`; \
> +	  case "$$ext" in \
> +	    8*) ;; \
> +	    *) ext='8' ;; \
> +	  esac; \
>  	  inst=`echo $$i | sed -e 's/\\.[0-9a-z]*$$//'`; \
>  	  inst=`echo $$inst | sed -e 's/^.*\///'`; \
>  	  inst=`echo $$inst | sed '$(transform)'`.$$ext; \
> @@ -361,7 +367,7 @@
>  distdir: $(DISTFILES)
>  	$(am__remove_distdir)
>  	mkdir $(distdir)
> -	@for file in $(DISTFILES); do \
> +	@list='$(DISTFILES)'; for file in $$list; do \
>  	  if test -f $$file || test -d $$file; then d=.; else d=$(srcdir); fi; \
>  	  dir=`echo "$$file" | sed -e 's,/[^/]*$$,,'`; \
>  	  if test "$$dir" != "$$file" && test "$$dir" != "."; then \
> @@ -459,7 +465,7 @@
>  clean-generic:
> 
>  distclean-generic:
> -	-rm -f Makefile $(CONFIG_CLEAN_FILES) stamp-h stamp-h[0-9]*
> +	-rm -f Makefile $(CONFIG_CLEAN_FILES)
> 
>  maintainer-clean-generic:
>  	@echo "This command is intended for maintainers to use"
> @@ -469,7 +475,7 @@
>  clean-am: clean-generic clean-sbinPROGRAMS mostlyclean-am
> 
>  distclean: distclean-am
> -	-rm -f config.status config.cache config.log
> +	-rm -f $(am__CONFIG_DISTCLEAN_FILES)
>  distclean-am: clean-am distclean-compile distclean-depend \
>  	distclean-generic distclean-hdr distclean-tags
> 
> @@ -492,7 +498,8 @@
>  installcheck-am:
> 
>  maintainer-clean: maintainer-clean-am
> -
> +	-rm -f $(am__CONFIG_DISTCLEAN_FILES)
> +	-rm -rf autom4te.cache
>  maintainer-clean-am: distclean-am maintainer-clean-generic
> 
>  mostlyclean: mostlyclean-am
> Index: aclocal.m4
> ===================================================================
> RCS file: /cvsroot/openvpn/openvpn/aclocal.m4,v
> retrieving revision 1.31
> diff -u -r1.31 aclocal.m4
> --- aclocal.m4	14 Sep 2002 21:54:10 -0000	1.31
> +++ aclocal.m4	27 Sep 2002 22:41:11 -0000
> @@ -1,4 +1,4 @@
> -# aclocal.m4 generated automatically by aclocal 1.6.1 -*- Autoconf -*-
> +# aclocal.m4 generated automatically by aclocal 1.6.3 -*- Autoconf -*-
> 
>  # Copyright 1996, 1997, 1998, 1999, 2000, 2001, 2002
>  # Free Software Foundation, Inc.
> @@ -96,7 +96,7 @@
>  dnl macros posted by AFC to the autoconf macro repository.  We are also
>  dnl grateful for the helpful feedback of numerous users.
>  dnl
> -dnl @version $Id: aclocal.m4,v 1.31 2002/09/14 21:54:10 jimyonan Exp $
> +dnl @version $Id: acinclude.m4,v 1.1 2002/05/30 00:04:45 jimyonan Exp $
>  dnl @author Steven G. Johnson <st...@al...> and Alejandro Forero Cuervo <ba...@ba...>
> 
>  AC_DEFUN([ACX_PTHREAD], [
> @@ -490,7 +490,7 @@
>  # Call AM_AUTOMAKE_VERSION so it can be traced.
>  # This function is AC_REQUIREd by AC_INIT_AUTOMAKE.
>  AC_DEFUN([AM_SET_CURRENT_AUTOMAKE_VERSION],
> -	 [AM_AUTOMAKE_VERSION([1.6.1])])
> +	 [AM_AUTOMAKE_VERSION([1.6.3])])
> 
>  # Helper functions for option handling.                    -*- Autoconf -*-
> 
> @@ -822,7 +822,7 @@
> 
>  ifelse([$1], CC,   [depcc="$CC"   am_compiler_list=],
>         [$1], CXX,  [depcc="$CXX"  am_compiler_list=],
> -       [$1], OBJC, [depcc="$OBJC" am_compiler_list='gcc3 gcc']
> +       [$1], OBJC, [depcc="$OBJC" am_compiler_list='gcc3 gcc'],
>         [$1], GCJ,  [depcc="$GCJ"  am_compiler_list='gcc3 gcc'],
>                     [depcc="$$1"   am_compiler_list=])
> 
> @@ -947,7 +947,13 @@
>  [for mf in $CONFIG_FILES; do
>    # Strip MF so we end up with the name of the file.
>    mf=`echo "$mf" | sed -e 's/:.*$//'`
> -  if (sed 1q $mf | fgrep 'generated by automake') > /dev/null 2>&1; then
> +  # Check whether this is an Automake generated Makefile or not.
> +  # We used to match only the files named `Makefile.in', but
> +  # some people rename them; so instead we look at the file content.
> +  # Grep'ing the first line is not enough: some people post-process
> +  # each Makefile.in and add a new line on top of each file to say so.
> +  # So let's grep whole file.
> +  if grep '^#.*generated by automake' $mf > /dev/null 2>&1; then
>      dirpart=`AS_DIRNAME("$mf")`
>    else
>      continue
> Index: config.h.in
> ===================================================================
> RCS file: /cvsroot/openvpn/openvpn/config.h.in,v
> retrieving revision 1.6
> diff -u -r1.6 config.h.in
> --- config.h.in	28 Jul 2002 07:54:57 -0000	1.6
> +++ config.h.in	27 Sep 2002 22:41:12 -0000
> @@ -78,6 +78,9 @@
>  /* Define to 1 if you have the <netdb.h> header file. */
>  #undef HAVE_NETDB_H
> 
> +/* Define to 1 if you have the <netinet/if_ether.h> header file. */
> +#undef HAVE_NETINET_IF_ETHER_H
> +
>  /* Define to 1 if you have the <netinet/in.h> header file. */
>  #undef HAVE_NETINET_IN_H
> 
> Index: configure
> ===================================================================
> RCS file: /cvsroot/openvpn/openvpn/configure,v
> retrieving revision 1.37
> diff -u -r1.37 configure
> --- configure	14 Sep 2002 21:54:10 -0000	1.37
> +++ configure	27 Sep 2002 22:41:39 -0000
> @@ -6759,6 +6759,120 @@
>  done
> 
> 
> +for ac_header in netinet/if_ether.h
> +do
> +as_ac_Header=`echo "ac_cv_header_$ac_header" | $as_tr_sh`
> +if eval "test \"\${$as_ac_Header+set}\" = set"; then
> +  echo "$as_me:$LINENO: checking for $ac_header" >&5
> +echo $ECHO_N "checking for $ac_header... $ECHO_C" >&6
> +if eval "test \"\${$as_ac_Header+set}\" = set"; then
> +  echo $ECHO_N "(cached) $ECHO_C" >&6
> +fi
> +echo "$as_me:$LINENO: result: `eval echo '${'$as_ac_Header'}'`" >&5
> +echo "${ECHO_T}`eval echo '${'$as_ac_Header'}'`" >&6
> +else
> +  # Is the header compilable?
> +echo "$as_me:$LINENO: checking $ac_header usability" >&5
> +echo $ECHO_N "checking $ac_header usability... $ECHO_C" >&6
> +cat >conftest.$ac_ext <<_ACEOF
> +#line $LINENO "configure"
> +#include "confdefs.h"
> +$ac_includes_default
> +#include <$ac_header>
> +_ACEOF
> +rm -f conftest.$ac_objext
> +if { (eval echo "$as_me:$LINENO: \"$ac_compile\"") >&5
> +  (eval $ac_compile) 2>&5
> +  ac_status=$?
> +  echo "$as_me:$LINENO: \$? = $ac_status" >&5
> +  (exit $ac_status); } &&
> +         { ac_try='test -s conftest.$ac_objext'
> +  { (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5
> +  (eval $ac_try) 2>&5
> +  ac_status=$?
> +  echo "$as_me:$LINENO: \$? = $ac_status" >&5
> +  (exit $ac_status); }; }; then
> +  ac_header_compiler=yes
> +else
> +  echo "$as_me: failed program was:" >&5
> +cat conftest.$ac_ext >&5
> +ac_header_compiler=no
> +fi
> +rm -f conftest.$ac_objext conftest.$ac_ext
> +echo "$as_me:$LINENO: result: $ac_header_compiler" >&5
> +echo "${ECHO_T}$ac_header_compiler" >&6
> +
> +# Is the header present?
> +echo "$as_me:$LINENO: checking $ac_header presence" >&5
> +echo $ECHO_N "checking $ac_header presence... $ECHO_C" >&6
> +cat >conftest.$ac_ext <<_ACEOF
> +#line $LINENO "configure"
> +#include "confdefs.h"
> +#include <$ac_header>
> +_ACEOF
> +if { (eval echo "$as_me:$LINENO: \"$ac_cpp conftest.$ac_ext\"") >&5
> +  (eval $ac_cpp conftest.$ac_ext) 2>conftest.er1
> +  ac_status=$?
> +  egrep -v '^ *\+' conftest.er1 >conftest.err
> +  rm -f conftest.er1
> +  cat conftest.err >&5
> +  echo "$as_me:$LINENO: \$? = $ac_status" >&5
> +  (exit $ac_status); } >/dev/null; then
> +  if test -s conftest.err; then
> +    ac_cpp_err=$ac_c_preproc_warn_flag
> +  else
> +    ac_cpp_err=
> +  fi
> +else
> +  ac_cpp_err=yes
> +fi
> +if test -z "$ac_cpp_err"; then
> +  ac_header_preproc=yes
> +else
> +  echo "$as_me: failed program was:" >&5
> +  cat conftest.$ac_ext >&5
> +  ac_header_preproc=no
> +fi
> +rm -f conftest.err conftest.$ac_ext
> +echo "$as_me:$LINENO: result: $ac_header_preproc" >&5
> +echo "${ECHO_T}$ac_header_preproc" >&6
> +
> +# So?  What about this header?
> +case $ac_header_compiler:$ac_header_preproc in
> +  yes:no )
> +    { echo "$as_me:$LINENO: WARNING: $ac_header: accepted by the compiler, rejected by the preprocessor!" >&5
> +echo "$as_me: WARNING: $ac_header: accepted by the compiler, rejected by the preprocessor!" >&2;}
> +    { echo "$as_me:$LINENO: WARNING: $ac_header: proceeding with the preprocessor's result" >&5
> +echo "$as_me: WARNING: $ac_header: proceeding with the preprocessor's result" >&2;};;
> +  no:yes )
> +    { echo "$as_me:$LINENO: WARNING: $ac_header: present but cannot be compiled" >&5
> +echo "$as_me: WARNING: $ac_header: present but cannot be compiled" >&2;}
> +    { echo "$as_me:$LINENO: WARNING: $ac_header: check for missing prerequisite headers?" >&5
> +echo "$as_me: WARNING: $ac_header: check for missing prerequisite headers?" >&2;}
> +    { echo "$as_me:$LINENO: WARNING: $ac_header: proceeding with the preprocessor's result" >&5
> +echo "$as_me: WARNING: $ac_header: proceeding with the preprocessor's result" >&2;};;
> +esac
> +echo "$as_me:$LINENO: checking for $ac_header" >&5
> +echo $ECHO_N "checking for $ac_header... $ECHO_C" >&6
> +if eval "test \"\${$as_ac_Header+set}\" = set"; then
> +  echo $ECHO_N "(cached) $ECHO_C" >&6
> +else
> +  eval "$as_ac_Header=$ac_header_preproc"
> +fi
> +echo "$as_me:$LINENO: result: `eval echo '${'$as_ac_Header'}'`" >&5
> +echo "${ECHO_T}`eval echo '${'$as_ac_Header'}'`" >&6
> +
> +fi
> +if test `eval echo '${'$as_ac_Header'}'` = yes; then
> +  cat >>confdefs.h <<_ACEOF
> +#define `echo "HAVE_$ac_header" | $as_tr_cpp` 1
> +_ACEOF
> +
> +fi
> +
> +done
> +
> +
>  for ac_header in netinet/tcp.h
>  do
>  as_ac_Header=`echo "ac_cv_header_$ac_header" | $as_tr_sh`
> @@ -12646,7 +12760,13 @@
>      depfiles ) test x"$AMDEP_TRUE" != x"" || for mf in $CONFIG_FILES; do
>    # Strip MF so we end up with the name of the file.
>    mf=`echo "$mf" | sed -e 's/:.*$//'`
> -  if (sed 1q $mf | fgrep 'generated by automake') > /dev/null 2>&1; then
> +  # Check whether this is an Automake generated Makefile or not.
> +  # We used to match only the files named `Makefile.in', but
> +  # some people rename them; so instead we look at the file content.
> +  # Grep'ing the first line is not enough: some people post-process
> +  # each Makefile.in and add a new line on top of each file to say so.
> +  # So let's grep whole file.
> +  if grep '^#.*generated by automake' $mf > /dev/null 2>&1; then
>      dirpart=`(dirname "$mf") 2>/dev/null ||
>  $as_expr X"$mf" : 'X\(.*[^/]\)//*[^/][^/]*/*$' \| \
>           X"$mf" : 'X\(//\)[^/]' \| \
> Index: configure.ac
> ===================================================================
> RCS file: /cvsroot/openvpn/openvpn/configure.ac,v
> retrieving revision 1.37
> diff -u -r1.37 configure.ac
> --- configure.ac	14 Sep 2002 21:54:10 -0000	1.37
> +++ configure.ac	27 Sep 2002 22:41:39 -0000
> @@ -169,6 +169,7 @@
>  AC_CHECK_HEADERS(netinet/in.h)
>  AC_CHECK_HEADERS(netinet/in_systm.h)
>  AC_CHECK_HEADERS(netinet/ip.h)
> +AC_CHECK_HEADERS(netinet/if_ether.h)
>  AC_CHECK_HEADERS(netinet/tcp.h)
>  AC_CHECK_HEADERS(resolv.h)
>  AC_CHECK_HEADERS(arpa/inet.h)
> Index: syshead.h
> ===================================================================
> RCS file: /cvsroot/openvpn/openvpn/syshead.h,v
> retrieving revision 1.10
> diff -u -r1.10 syshead.h
> --- syshead.h	28 Jul 2002 07:54:57 -0000	1.10
> +++ syshead.h	27 Sep 2002 22:41:40 -0000
> @@ -141,8 +141,16 @@
> 
>  #ifdef TARGET_LINUX
> 
> +#ifdef HAVE_NETINET_IF_ETHER_H
> +#include <netinet/if_ether.h>
> +#endif
> +
>  #ifdef HAVE_LINUX_IF_TUN_H
>  #include <linux/if_tun.h>
> +#endif
> +
> +#ifdef HAVE_NETINET_IP_H
> +#include <netinet/ip.h>
>  #endif
> 
>  #endif /* TARGET_LINUX */
> Index: tun.c
> ===================================================================
> RCS file: /cvsroot/openvpn/openvpn/tun.c,v
> retrieving revision 1.17
> diff -u -r1.17 tun.c
> --- tun.c	28 Jul 2002 07:54:57 -0000	1.17
> +++ tun.c	27 Sep 2002 22:41:41 -0000
> @@ -277,7 +277,6 @@
>  	msg (M_ERR, "Cannot open tun/tap dev %s", dev_node);
> 
>        CLEAR (ifr);
> -      ifr.ifr_flags = IFF_NO_PI;
> 
>        if (is_dev_type (dev, dev_type, "tun"))
>  	{
> @@ -339,13 +338,43 @@
>  int
>  write_tun (struct tuntap* tt, uint8_t *buf, int len)
>  {
> -  return write (tt->fd, buf, len);
> +  struct tun_pi pi;
> +  struct iphdr *iph;
> +  struct iovec vect[2];
> +  int ret;
> +
> +  iph = (struct iphdr *)buf;
> +
> +  pi.flags = 0;
> +
> +  if(iph->version == 6)
> +    pi.proto = htons(ETH_P_IPV6);
> +  else
> +    pi.proto = htons(ETH_P_IP);
> +
> +  vect[0].iov_len = sizeof(pi);
> +  vect[0].iov_base = &pi;
> +  vect[1].iov_len = len;
> +  vect[1].iov_base = buf;
> +
> +  ret = writev(tt->fd, vect, 2);
> +  return(ret - sizeof(pi));
>  }
> 
>  int
>  read_tun (struct tuntap* tt, uint8_t *buf, int len)
>  {
> -  return read (tt->fd, buf, len);
> +  struct iovec vect[2];
> +  struct tun_pi pi;
> +  int ret;
> +
> +  vect[0].iov_len = sizeof(pi);
> +  vect[0].iov_base = &pi;
> +  vect[1].iov_len = len;
> +  vect[1].iov_base = buf;
> +
> +  ret = readv(tt->fd, vect, 2);
> +  return(ret - sizeof(pi));
>  }
> 
>  #elif defined(TARGET_SOLARIS)
> 
> 
> 
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Openvpn-devel mailing list
> Ope...@li...
> https://lists.sourceforge.net/lists/listinfo/openvpn-devel
> 



-- 

[Openvpn-devel] tunnelling ipv6 on linux

[Aaron S. <and...@ra...>]

I've done some work on getting openvpn to tunnel ipv6 without having to
use TAP tunnels.  I think to get ipv6 tunneling to work on other platforms
it may require changes in the tunnel driver.  But I figure I'll post this
here as it might be of use to somebody.

Regards,

Aaron



Index: Makefile.in
===================================================================
RCS file: /cvsroot/openvpn/openvpn/Makefile.in,v
retrieving revision 1.6
diff -u -r1.6 Makefile.in
--- Makefile.in	25 Jun 2002 06:56:16 -0000	1.6
+++ Makefile.in	27 Sep 2002 22:41:09 -0000
@@ -1,4 +1,4 @@
-# Makefile.in generated by automake 1.6.1 from Makefile.am.
+# Makefile.in generated by automake 1.6.3 from Makefile.am.
 # @configure_input@

 # Copyright 1994, 1995, 1996, 1997, 1998, 1999, 2000, 2001, 2002
@@ -74,6 +74,7 @@
 INSTALL_DATA = @INSTALL_DATA@
 install_sh_DATA = $(install_sh) -c -m 644
 install_sh_PROGRAM = $(install_sh) -c
+install_sh_SCRIPT = $(install_sh) -c
 INSTALL_SCRIPT = @INSTALL_SCRIPT@
 INSTALL_HEADER = $(INSTALL_DATA)
 transform = @program_transform_name@
@@ -170,6 +171,9 @@

 .SUFFIXES:
 .SUFFIXES: .c .o .obj
+
+am__CONFIG_DISTCLEAN_FILES = config.status config.cache config.log \
+ configure.lineno
 $(srcdir)/Makefile.in:  Makefile.am  $(top_srcdir)/configure.ac $(ACLOCAL_M4)
 	cd $(top_srcdir) && \
 	  $(AUTOMAKE) --gnu  Makefile
@@ -199,7 +203,7 @@
 	touch $(srcdir)/config.h.in

 distclean-hdr:
-	-rm -f config.h
+	-rm -f config.h stamp-h1
 sbinPROGRAMS_INSTALL = $(INSTALL_PROGRAM)
 install-sbinPROGRAMS: $(sbin_PROGRAMS)
 	@$(NORMAL_INSTALL)
@@ -208,8 +212,7 @@
 	  p1=`echo $$p|sed 's/$(EXEEXT)$$//'`; \
 	  if test -f $$p \
 	  ; then \
-	    p1=`echo "$$p1" | sed -e 's,^.*/,,'`; \
-	    f=`echo $$p1|sed '$(transform);s/$$/$(EXEEXT)/'`; \
+	    f=`echo "$$p1" | sed 's,^.*/,,;$(transform);s/$$/$(EXEEXT)/'`; \
 	   echo " $(INSTALL_PROGRAM_ENV) $(sbinPROGRAMS_INSTALL) $$p $(DESTDIR)$(sbindir)/$$f"; \
 	   $(INSTALL_PROGRAM_ENV) $(sbinPROGRAMS_INSTALL) $$p $(DESTDIR)$(sbindir)/$$f; \
 	  else :; fi; \
@@ -218,8 +221,7 @@
 uninstall-sbinPROGRAMS:
 	@$(NORMAL_UNINSTALL)
 	@list='$(sbin_PROGRAMS)'; for p in $$list; do \
-	  f=`echo $$p|sed 's/$(EXEEXT)$$//;$(transform);s/$$/$(EXEEXT)/'`; \
-	  f=`echo "$$f" | sed -e 's,^.*/,,'`; \
+	  f=`echo "$$p" | sed 's,^.*/,,;s/$(EXEEXT)$$//;$(transform);s/$$/$(EXEEXT)/'`; \
 	  echo " rm -f $(DESTDIR)$(sbindir)/$$f"; \
 	  rm -f $(DESTDIR)$(sbindir)/$$f; \
 	done
@@ -286,6 +288,10 @@
 	  if test -f $(srcdir)/$$i; then file=$(srcdir)/$$i; \
 	  else file=$$i; fi; \
 	  ext=`echo $$i | sed -e 's/^.*\\.//'`; \
+	  case "$$ext" in \
+	    8*) ;; \
+	    *) ext='8' ;; \
+	  esac; \
 	  inst=`echo $$i | sed -e 's/\\.[0-9a-z]*$$//'`; \
 	  inst=`echo $$inst | sed -e 's/^.*\///'`; \
 	  inst=`echo $$inst | sed '$(transform)'`.$$ext; \
@@ -361,7 +367,7 @@
 distdir: $(DISTFILES)
 	$(am__remove_distdir)
 	mkdir $(distdir)
-	@for file in $(DISTFILES); do \
+	@list='$(DISTFILES)'; for file in $$list; do \
 	  if test -f $$file || test -d $$file; then d=.; else d=$(srcdir); fi; \
 	  dir=`echo "$$file" | sed -e 's,/[^/]*$$,,'`; \
 	  if test "$$dir" != "$$file" && test "$$dir" != "."; then \
@@ -459,7 +465,7 @@
 clean-generic:

 distclean-generic:
-	-rm -f Makefile $(CONFIG_CLEAN_FILES) stamp-h stamp-h[0-9]*
+	-rm -f Makefile $(CONFIG_CLEAN_FILES)

 maintainer-clean-generic:
 	@echo "This command is intended for maintainers to use"
@@ -469,7 +475,7 @@
 clean-am: clean-generic clean-sbinPROGRAMS mostlyclean-am

 distclean: distclean-am
-	-rm -f config.status config.cache config.log
+	-rm -f $(am__CONFIG_DISTCLEAN_FILES)
 distclean-am: clean-am distclean-compile distclean-depend \
 	distclean-generic distclean-hdr distclean-tags

@@ -492,7 +498,8 @@
 installcheck-am:

 maintainer-clean: maintainer-clean-am
-
+	-rm -f $(am__CONFIG_DISTCLEAN_FILES)
+	-rm -rf autom4te.cache
 maintainer-clean-am: distclean-am maintainer-clean-generic

 mostlyclean: mostlyclean-am
Index: aclocal.m4
===================================================================
RCS file: /cvsroot/openvpn/openvpn/aclocal.m4,v
retrieving revision 1.31
diff -u -r1.31 aclocal.m4
--- aclocal.m4	14 Sep 2002 21:54:10 -0000	1.31
+++ aclocal.m4	27 Sep 2002 22:41:11 -0000
@@ -1,4 +1,4 @@
-# aclocal.m4 generated automatically by aclocal 1.6.1 -*- Autoconf -*-
+# aclocal.m4 generated automatically by aclocal 1.6.3 -*- Autoconf -*-

 # Copyright 1996, 1997, 1998, 1999, 2000, 2001, 2002
 # Free Software Foundation, Inc.
@@ -96,7 +96,7 @@
 dnl macros posted by AFC to the autoconf macro repository.  We are also
 dnl grateful for the helpful feedback of numerous users.
 dnl
-dnl @version $Id: aclocal.m4,v 1.31 2002/09/14 21:54:10 jimyonan Exp $
+dnl @version $Id: acinclude.m4,v 1.1 2002/05/30 00:04:45 jimyonan Exp $
 dnl @author Steven G. Johnson <st...@al...> and Alejandro Forero Cuervo <ba...@ba...>

 AC_DEFUN([ACX_PTHREAD], [
@@ -490,7 +490,7 @@
 # Call AM_AUTOMAKE_VERSION so it can be traced.
 # This function is AC_REQUIREd by AC_INIT_AUTOMAKE.
 AC_DEFUN([AM_SET_CURRENT_AUTOMAKE_VERSION],
-	 [AM_AUTOMAKE_VERSION([1.6.1])])
+	 [AM_AUTOMAKE_VERSION([1.6.3])])

 # Helper functions for option handling.                    -*- Autoconf -*-

@@ -822,7 +822,7 @@

 ifelse([$1], CC,   [depcc="$CC"   am_compiler_list=],
        [$1], CXX,  [depcc="$CXX"  am_compiler_list=],
-       [$1], OBJC, [depcc="$OBJC" am_compiler_list='gcc3 gcc']
+       [$1], OBJC, [depcc="$OBJC" am_compiler_list='gcc3 gcc'],
        [$1], GCJ,  [depcc="$GCJ"  am_compiler_list='gcc3 gcc'],
                    [depcc="$$1"   am_compiler_list=])

@@ -947,7 +947,13 @@
 [for mf in $CONFIG_FILES; do
   # Strip MF so we end up with the name of the file.
   mf=`echo "$mf" | sed -e 's/:.*$//'`
-  if (sed 1q $mf | fgrep 'generated by automake') > /dev/null 2>&1; then
+  # Check whether this is an Automake generated Makefile or not.
+  # We used to match only the files named `Makefile.in', but
+  # some people rename them; so instead we look at the file content.
+  # Grep'ing the first line is not enough: some people post-process
+  # each Makefile.in and add a new line on top of each file to say so.
+  # So let's grep whole file.
+  if grep '^#.*generated by automake' $mf > /dev/null 2>&1; then
     dirpart=`AS_DIRNAME("$mf")`
   else
     continue
Index: config.h.in
===================================================================
RCS file: /cvsroot/openvpn/openvpn/config.h.in,v
retrieving revision 1.6
diff -u -r1.6 config.h.in
--- config.h.in	28 Jul 2002 07:54:57 -0000	1.6
+++ config.h.in	27 Sep 2002 22:41:12 -0000
@@ -78,6 +78,9 @@
 /* Define to 1 if you have the <netdb.h> header file. */
 #undef HAVE_NETDB_H

+/* Define to 1 if you have the <netinet/if_ether.h> header file. */
+#undef HAVE_NETINET_IF_ETHER_H
+
 /* Define to 1 if you have the <netinet/in.h> header file. */
 #undef HAVE_NETINET_IN_H

Index: configure
===================================================================
RCS file: /cvsroot/openvpn/openvpn/configure,v
retrieving revision 1.37
diff -u -r1.37 configure
--- configure	14 Sep 2002 21:54:10 -0000	1.37
+++ configure	27 Sep 2002 22:41:39 -0000
@@ -6759,6 +6759,120 @@
 done


+for ac_header in netinet/if_ether.h
+do
+as_ac_Header=`echo "ac_cv_header_$ac_header" | $as_tr_sh`
+if eval "test \"\${$as_ac_Header+set}\" = set"; then
+  echo "$as_me:$LINENO: checking for $ac_header" >&5
+echo $ECHO_N "checking for $ac_header... $ECHO_C" >&6
+if eval "test \"\${$as_ac_Header+set}\" = set"; then
+  echo $ECHO_N "(cached) $ECHO_C" >&6
+fi
+echo "$as_me:$LINENO: result: `eval echo '${'$as_ac_Header'}'`" >&5
+echo "${ECHO_T}`eval echo '${'$as_ac_Header'}'`" >&6
+else
+  # Is the header compilable?
+echo "$as_me:$LINENO: checking $ac_header usability" >&5
+echo $ECHO_N "checking $ac_header usability... $ECHO_C" >&6
+cat >conftest.$ac_ext <<_ACEOF
+#line $LINENO "configure"
+#include "confdefs.h"
+$ac_includes_default
+#include <$ac_header>
+_ACEOF
+rm -f conftest.$ac_objext
+if { (eval echo "$as_me:$LINENO: \"$ac_compile\"") >&5
+  (eval $ac_compile) 2>&5
+  ac_status=$?
+  echo "$as_me:$LINENO: \$? = $ac_status" >&5
+  (exit $ac_status); } &&
+         { ac_try='test -s conftest.$ac_objext'
+  { (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5
+  (eval $ac_try) 2>&5
+  ac_status=$?
+  echo "$as_me:$LINENO: \$? = $ac_status" >&5
+  (exit $ac_status); }; }; then
+  ac_header_compiler=yes
+else
+  echo "$as_me: failed program was:" >&5
+cat conftest.$ac_ext >&5
+ac_header_compiler=no
+fi
+rm -f conftest.$ac_objext conftest.$ac_ext
+echo "$as_me:$LINENO: result: $ac_header_compiler" >&5
+echo "${ECHO_T}$ac_header_compiler" >&6
+
+# Is the header present?
+echo "$as_me:$LINENO: checking $ac_header presence" >&5
+echo $ECHO_N "checking $ac_header presence... $ECHO_C" >&6
+cat >conftest.$ac_ext <<_ACEOF
+#line $LINENO "configure"
+#include "confdefs.h"
+#include <$ac_header>
+_ACEOF
+if { (eval echo "$as_me:$LINENO: \"$ac_cpp conftest.$ac_ext\"") >&5
+  (eval $ac_cpp conftest.$ac_ext) 2>conftest.er1
+  ac_status=$?
+  egrep -v '^ *\+' conftest.er1 >conftest.err
+  rm -f conftest.er1
+  cat conftest.err >&5
+  echo "$as_me:$LINENO: \$? = $ac_status" >&5
+  (exit $ac_status); } >/dev/null; then
+  if test -s conftest.err; then
+    ac_cpp_err=$ac_c_preproc_warn_flag
+  else
+    ac_cpp_err=
+  fi
+else
+  ac_cpp_err=yes
+fi
+if test -z "$ac_cpp_err"; then
+  ac_header_preproc=yes
+else
+  echo "$as_me: failed program was:" >&5
+  cat conftest.$ac_ext >&5
+  ac_header_preproc=no
+fi
+rm -f conftest.err conftest.$ac_ext
+echo "$as_me:$LINENO: result: $ac_header_preproc" >&5
+echo "${ECHO_T}$ac_header_preproc" >&6
+
+# So?  What about this header?
+case $ac_header_compiler:$ac_header_preproc in
+  yes:no )
+    { echo "$as_me:$LINENO: WARNING: $ac_header: accepted by the compiler, rejected by the preprocessor!" >&5
+echo "$as_me: WARNING: $ac_header: accepted by the compiler, rejected by the preprocessor!" >&2;}
+    { echo "$as_me:$LINENO: WARNING: $ac_header: proceeding with the preprocessor's result" >&5
+echo "$as_me: WARNING: $ac_header: proceeding with the preprocessor's result" >&2;};;
+  no:yes )
+    { echo "$as_me:$LINENO: WARNING: $ac_header: present but cannot be compiled" >&5
+echo "$as_me: WARNING: $ac_header: present but cannot be compiled" >&2;}
+    { echo "$as_me:$LINENO: WARNING: $ac_header: check for missing prerequisite headers?" >&5
+echo "$as_me: WARNING: $ac_header: check for missing prerequisite headers?" >&2;}
+    { echo "$as_me:$LINENO: WARNING: $ac_header: proceeding with the preprocessor's result" >&5
+echo "$as_me: WARNING: $ac_header: proceeding with the preprocessor's result" >&2;};;
+esac
+echo "$as_me:$LINENO: checking for $ac_header" >&5
+echo $ECHO_N "checking for $ac_header... $ECHO_C" >&6
+if eval "test \"\${$as_ac_Header+set}\" = set"; then
+  echo $ECHO_N "(cached) $ECHO_C" >&6
+else
+  eval "$as_ac_Header=$ac_header_preproc"
+fi
+echo "$as_me:$LINENO: result: `eval echo '${'$as_ac_Header'}'`" >&5
+echo "${ECHO_T}`eval echo '${'$as_ac_Header'}'`" >&6
+
+fi
+if test `eval echo '${'$as_ac_Header'}'` = yes; then
+  cat >>confdefs.h <<_ACEOF
+#define `echo "HAVE_$ac_header" | $as_tr_cpp` 1
+_ACEOF
+
+fi
+
+done
+
+
 for ac_header in netinet/tcp.h
 do
 as_ac_Header=`echo "ac_cv_header_$ac_header" | $as_tr_sh`
@@ -12646,7 +12760,13 @@
     depfiles ) test x"$AMDEP_TRUE" != x"" || for mf in $CONFIG_FILES; do
   # Strip MF so we end up with the name of the file.
   mf=`echo "$mf" | sed -e 's/:.*$//'`
-  if (sed 1q $mf | fgrep 'generated by automake') > /dev/null 2>&1; then
+  # Check whether this is an Automake generated Makefile or not.
+  # We used to match only the files named `Makefile.in', but
+  # some people rename them; so instead we look at the file content.
+  # Grep'ing the first line is not enough: some people post-process
+  # each Makefile.in and add a new line on top of each file to say so.
+  # So let's grep whole file.
+  if grep '^#.*generated by automake' $mf > /dev/null 2>&1; then
     dirpart=`(dirname "$mf") 2>/dev/null ||
 $as_expr X"$mf" : 'X\(.*[^/]\)//*[^/][^/]*/*$' \| \
          X"$mf" : 'X\(//\)[^/]' \| \
Index: configure.ac
===================================================================
RCS file: /cvsroot/openvpn/openvpn/configure.ac,v
retrieving revision 1.37
diff -u -r1.37 configure.ac
--- configure.ac	14 Sep 2002 21:54:10 -0000	1.37
+++ configure.ac	27 Sep 2002 22:41:39 -0000
@@ -169,6 +169,7 @@
 AC_CHECK_HEADERS(netinet/in.h)
 AC_CHECK_HEADERS(netinet/in_systm.h)
 AC_CHECK_HEADERS(netinet/ip.h)
+AC_CHECK_HEADERS(netinet/if_ether.h)
 AC_CHECK_HEADERS(netinet/tcp.h)
 AC_CHECK_HEADERS(resolv.h)
 AC_CHECK_HEADERS(arpa/inet.h)
Index: syshead.h
===================================================================
RCS file: /cvsroot/openvpn/openvpn/syshead.h,v
retrieving revision 1.10
diff -u -r1.10 syshead.h
--- syshead.h	28 Jul 2002 07:54:57 -0000	1.10
+++ syshead.h	27 Sep 2002 22:41:40 -0000
@@ -141,8 +141,16 @@

 #ifdef TARGET_LINUX

+#ifdef HAVE_NETINET_IF_ETHER_H
+#include <netinet/if_ether.h>
+#endif
+
 #ifdef HAVE_LINUX_IF_TUN_H
 #include <linux/if_tun.h>
+#endif
+
+#ifdef HAVE_NETINET_IP_H
+#include <netinet/ip.h>
 #endif

 #endif /* TARGET_LINUX */
Index: tun.c
===================================================================
RCS file: /cvsroot/openvpn/openvpn/tun.c,v
retrieving revision 1.17
diff -u -r1.17 tun.c
--- tun.c	28 Jul 2002 07:54:57 -0000	1.17
+++ tun.c	27 Sep 2002 22:41:41 -0000
@@ -277,7 +277,6 @@
 	msg (M_ERR, "Cannot open tun/tap dev %s", dev_node);

       CLEAR (ifr);
-      ifr.ifr_flags = IFF_NO_PI;

       if (is_dev_type (dev, dev_type, "tun"))
 	{
@@ -339,13 +338,43 @@
 int
 write_tun (struct tuntap* tt, uint8_t *buf, int len)
 {
-  return write (tt->fd, buf, len);
+  struct tun_pi pi;
+  struct iphdr *iph;
+  struct iovec vect[2];
+  int ret;
+
+  iph = (struct iphdr *)buf;
+
+  pi.flags = 0;
+
+  if(iph->version == 6)
+    pi.proto = htons(ETH_P_IPV6);
+  else
+    pi.proto = htons(ETH_P_IP);
+
+  vect[0].iov_len = sizeof(pi);
+  vect[0].iov_base = &pi;
+  vect[1].iov_len = len;
+  vect[1].iov_base = buf;
+
+  ret = writev(tt->fd, vect, 2);
+  return(ret - sizeof(pi));
 }

 int
 read_tun (struct tuntap* tt, uint8_t *buf, int len)
 {
-  return read (tt->fd, buf, len);
+  struct iovec vect[2];
+  struct tun_pi pi;
+  int ret;
+
+  vect[0].iov_len = sizeof(pi);
+  vect[0].iov_base = &pi;
+  vect[1].iov_len = len;
+  vect[1].iov_base = buf;
+
+  ret = readv(tt->fd, vect, 2);
+  return(ret - sizeof(pi));
 }

 #elif defined(TARGET_SOLARIS)

Re: [Openvpn-devel] OpenVPN Project Update

[Matthias A. <ma+...@dt...>]

On Sun, 15 Sep 2002, James Yonan wrote:

> Well actually "Forking server support" is really a misnomer.  It would
> be better titled "Server support for arbitrary number of connecting
> clients without requiring a separate config file and a
> pre-instantiated daemon for every client, or just "scalability
> support".  xinetd is an interesting idea.  Anyone using xinetd with
> OpenVPN?

I tried and failed, and the problem is that openvpn is not prepared to
be run from xinetd -- it would have to take the socket it is passed in,
rather than trying to opening a new one.

Here's how far I got, it would take openvpn to add an --inetd option,
I'll see if I get that done. Note that server_args is a single line.

service openvpn
{
	type		= UNLISTED
	port		= 5002
	socket_type	= dgram
	protocol	= udp
	wait		= yes
	user		= root
	server		= /usr/local/sbin/openvpn-log
	server_args	= --user vpn --verb 5 --float --dev tun0 --ifconfig 192.168.0.1 192.168.0.129 --up /service/openvpn/script-up --comp-lzo --mlock --secret /service/openvpn/openvpn.key --ping 60
}

-- 
Matthias Andree

[Openvpn-devel] hub and spoke topology checklist.txt

[R P H. <he...@ow...>]

I was working through the openvpn material, and had been 
testing with the following design checklist (see bottom)

The thought is to provide a hub and spoke design for isolated
non-routable subnets at the end of the spokes, behind
otherwise properly routed outbound-only NATting (which allow 
return packets ...), where there is available a central
routable IP hub available (to allow static custom routing 
between those subnets).

I can ping, and indeed set up an SSH session, out to the hub,
which indicates that encapsulation of TCP within the OpenVPN
client is occurring -- I leave encryption off, as I am in
process diagnosing where things are falling apart --

-- after a couple minutes, it locks up tight, and I have 
to go kill the remote Hub routing, out of band.

As such, I have not gotten the second subnet set up yet.

The tracing shows packets for a while, but then the consoles 
lock (in which the tracing is occurring), and I cannot 
ctrl-C to regain control.  Network connectivity remains active 
-- I can work out of band on the Hub, the enar spoke terminus 
is local ...

Any thoughts on a theoretical reason this should not work?

-- Russ Herrold

=============================================================

Hub and Spoke Topology:

HUB x.y.z.a is a static IP, in routable space -- all other
devices are masqueraded, and not reachible from the outside,

The VPN gateway will encapsulate VPN network destination traffic into the
TUN interface, and pass the rest along to the next hop exterior NAT device

Subnets:

                         |
           10.1.1.1      |
client --- gateway ---- NAT ------ internet ----- HUB
10.1.1.2      |       10.1.1.254    0.0.0.0     x.y.z.a
              \          |
               \--- 192.168.1.2 ----------- 192.168.1.1
                         |         P-t-P
     10.1.1.x segment    |
                        /
-----------------------/



                         |
          10.10.10.1     |
client --- gateway ---- NAT ------ internet ----- HUB
10.10.10.2    |      10.10.10.254   0.0.0.0     x.y.z.a
              \          |
               \--- 192.168.10.2 ----------- 192.168.10.1
                         |          P-t-P
     10.10.10.x segment  |
                        /
-----------------------/


Routing:

on VPN gateway-10.1.1.1

( next hop: route add default gateway 10.1.1.254 )
route add -host 192.168.1.1 gateway 192.168.1.2
route add -net 10.0.0.0 gateway 192.168.1.1


on VPN gateway-10.10.10.1

( next hop: route add default gateway 10.10.10.254 )
route add -host 192.168.10.1 gateway 192.168.10.2
route add -net 10.0.0.0 gateway 192.168.10.1


on HUB -- simple reciprocal routing for each VPN'd subnet

route add -host 192.168.1.2 gateway 192.168.1.1
route add -net 10.1.1.0 gateway 192.168.1.2
route add -host 192.168.10.2 gateway 192.168.10.1
route add -net 10.10.10.0 gateway 192.168.10.2


Local gateway behind NAT

	modprobe tun
	echo 1 > /proc/sys/net/ipv4/ip_forward   
	openvpn --remote x.y.z.a --dev tun --port 5001 \
		--ifconfig 192.168.1.2 192.168.1.1 --verb 8

Local gateway behind NAT

	modprobe tun
	echo 1 > /proc/sys/net/ipv4/ip_forward   
	openvpn --remote x.y.z.a --dev tun --port 5010 \
		--ifconfig 192.168.10.2 192.168.10.1 --verb 8

Central HUB (== x.y.z.a )

	modprobe tun
	echo 1 > /proc/sys/net/ipv4/ip_forward
	openvpn --dev tun --port 5001 \
		--ifconfig 192.168.1.1 192.168.1.2 --verb 8
	openvpn --dev tun --port 5010 \
		--ifconfig 192.168.10.1 192.168.10.2 --verb 8

===================================

Re: [Openvpn-devel] OpenVPN Project Update

[James Y. <ji...@yo...>]

Matthias Andree <ma+...@dt...> said:

> On Sat, 14 Sep 2002, James Yonan wrote:
> 
> > (1) Forking server support
> > (2) Automatic Secure MTU discovery
> > (3) IPv6 endpoints or IPv6 over tun device
> > (4) Windows port
> > 
> > While none of these (with perhaps the exception of the last :) is
> > rocket science, all require some work, and given that OpenVPN has
> > reached a nice stability plateau, I'd like to hear your opinions on
> > future directions in the development effort.
> 
> ad 1) what's this good for? Sharing one port? Won't really work with
>       UDP. Convenience? Go get daemontools, or let's figure if openvpn
>       can be run from xinetd. Not something that should be done unless
>       you're really bored or have some compelling reason (a malicious
>       person holding a gun against your head might be one). Don't waste
>       your time.

Well actually "Forking server support" is really a misnomer.  It would be better titled "Server support for arbitrary number of connecting clients without requiring a separate config file and a pre-instantiated daemon for every client, or just "scalability support".  xinetd is an interesting idea.  Anyone using xinetd with OpenVPN?

> ad 2) I'd like to see that somewhen in the future, but I'd give IPv6 the
>       preference.
> 
> ad 3) IPv6 is certainly something that will have to be added.
> 
> ad 4) If they want secure networking, they shouldn't be running an
>       operating system of which the current version forces you to
>       register with the vendor, sending data you don't control.
>
>       It may be a moot point, but IMHO Windows which is made and sold by
>       a company that's always looking at its own profit, acting to its
>       own advantage, no matter how ruthless, and that aims to harm
>       OpenSource just to fortify its monopoly, to make more money, and
>       to control ever more markets to further maximize its huge
>       revenues, should not be supported by OpenSource developers.

While I agree that Windows is marketed by an aggressive monopoly, I don't agree that just because a company is anti-open-source, we shouldn't port open source software to its platform or make *nix implementations of its protocols.  On the contrary, I would argue that the more ruthlessly Microsoft behaves, the more that Open Source can benefit by porting to Windows, because once we have a large body of cross-platform software, then suddenly the OS won't matter as much and people will be free to choose based on quality.  And the ultimate weapon against a ruthless monopoly is this: Give customers a choice.

Having said that, and having glimpsed the cries of agony on the cipe-win32 list from those who have faced the windows network driver model, I expect that a win port will not be a panacea.

James

>       If your opinion differs from mine, that's called freedom. :-)

> Matthias Andree

Re: [Openvpn-devel] OpenVPN Project Update

[Matthias A. <ma+...@dt...>]

On Sat, 14 Sep 2002, James Yonan wrote:

> (1) Forking server support
> (2) Automatic Secure MTU discovery
> (3) IPv6 endpoints or IPv6 over tun device
> (4) Windows port
> 
> While none of these (with perhaps the exception of the last :) is
> rocket science, all require some work, and given that OpenVPN has
> reached a nice stability plateau, I'd like to hear your opinions on
> future directions in the development effort.

ad 1) what's this good for? Sharing one port? Won't really work with
      UDP. Convenience? Go get daemontools, or let's figure if openvpn
      can be run from xinetd. Not something that should be done unless
      you're really bored or have some compelling reason (a malicious
      person holding a gun against your head might be one). Don't waste
      your time.

ad 2) I'd like to see that somewhen in the future, but I'd give IPv6 the
      preference.

ad 3) IPv6 is certainly something that will have to be added.

ad 4) If they want secure networking, they shouldn't be running an
      operating system of which the current version forces you to
      register with the vendor, sending data you don't control.

      It may be a moot point, but IMHO Windows which is made and sold by
      a company that's always looking at its own profit, acting to its
      own advantage, no matter how ruthless, and that aims to harm
      OpenSource just to fortify its monopoly, to make more money, and
      to control ever more markets to further maximize its huge
      revenues, should not be supported by OpenSource developers.

      If your opinion differs from mine, that's called freedom. :-)

-- 
Matthias Andree

[Openvpn-devel] OpenVPN Project Update

[James Y. <ji...@yo...>]

CURRENT STATUS
--------------

Here's an update on OpenVPN progress for the last two months...

1.3.1 appears to be very stable and there haven't been a lot of new patches recently, though having said that there are certainly a few, most notably a minor patch to enable NetBSD support, and better support for intermediate CAs.

WISH LIST
---------

The current wish list stands as follows:

(1) Forking server support
(2) Automatic Secure MTU discovery
(3) IPv6 endpoints or IPv6 over tun device
(4) Windows port

While none of these (with perhaps the exception of the last :) is rocket science, all require some work, and given that OpenVPN has reached a nice stability plateau, I'd like to hear your opinions on future directions in the development effort.

DONATIONS
---------

I'd also like to bring to your attention the fact that the OpenVPN project is now accepting donations.  Please consider a small donation (such as $20) if you are actively using OpenVPN and possibly more if you are deriving significant utility from the software.  Right now I am "between jobs" and therefore don't have as much time as I'd like to spend on open source, but with enough support from the user community I hope to forge ahead on more of the wish list.  Having said that, I'd like to emphasize that OpenVPN has been a team effort with many individuals now cited in the change log or offering support on the lists.  Still, there's a lot of less glamorous work required to keep an open source project alive, such as merging contributions, testing on multiple platforms, documentation, releases, web site and mailing list admin, tech support, answering questions, keeping up to date with libraries, staying on top of security issues, trying to figure out whether problem reports ar!
e bugs or operator error, etc. etc.  Those all add up to a significant time commitment, and bear in mind that even a small donation can go a long way towards funding this kind of work.

If you would like to donate, you can do so via pay-pal:

https://www.paypal.com/xclick/business=paypal%40yonan.net

I you have deeper pockets and want to make a more dramatic gesture, you might even consider hiring me :)  My resume is here:

http://openvpn.sourceforge.net/resume2002/

PRE-1.3.2 BETA AVAILABLE
------------------------

While there hasn't been a great deal of development activity over the past two months, there are a small number of low-impact patches waiting in the queue that I'd like to release.

Here's the change log:

* Added SSL_CTX_set_client_CA_list call
  to follow the canonical form for TLS initialization
  recommended by the OpenSSL docs.  This change allows
  better support for intermediate CAs and has no impact
  on security.
* Added build-inter script to easy-rsa package, to
  facilitate the generation of intermediate CAs.
* Ported to NetBSD (Dimitri Goldin).
* Fixed minor bug in easy-rsa/sign-req.  It refers to
  openssl.cnf file, instead of $KEY_CONFIG, like all
  other scripts (Ernesto Baschny).
* Added --days 3650 to the root CA generation command
  in the howto to override the woefully small 30 day
  default (Dominik 'Aeneas' Schnitzer).
* Added paypal links to website for project donations.
* Configured sourceforge mailing lists to require
  admin approval for non-member posts to reduce spam.

If you have time, are using TLS, and especially if you are using an intermediate CA, I would encourage you to test this beta and verify that the first point in the change log does not cause problems.

Download beta:

http://openvpn.sourceforge.net/beta/openvpn-1.3.1.4.tar.gz

SPAM
----

In other news, openvpn-users got its first spam the other day.  While spam certainly has not been a big problem here, I want to be as proactive as possible in keeping these lists from becoming spam vectors, so I've reconfigured the lists to require admin approval for non-member posts.  I'm willing to be the admin on this as long as it doesn't become a big time sink, and you can make life easier for me by subscribing before you post.

Thanks,
James Yonan
OpenVPN Project Leader

Re: Fwd: [Openvpn-devel] Fwd: Bug#158404: openvpn: Improper error handling

[James Y. <ji...@yo...>]

Richard A Nelson <co...@vn...> said:

> On Tue, 27 Aug 2002, James Yonan wrote:
> 
> > Hello Richard,
> 
> Hi, thanks for the quick feedback
> 
> > Normally we shouldn't get EAGAIN in the UDP read loop because we block on select and don't call recvfrom until there is a datagram waiting for us.  So the fact that you are getting a lot of EAGAIN messages is interesting and probably indicative of some kind of problem.  Is there any correlation between the EAGAIN floods and some sort of real world factor such as a bad or congested network condition?
> 
> Its hard to reproduce, but congestion is definitely a possiblity
> 
> > If EAGAIN is received from recvfrom (or any other error for that matter), it is syslogged and the select event loop continues.  So your potential solutions 1 and 2 below are already being done.  Solution 3 doesn't work because OpenVPN is too asynchronous to be able to block on a single i/o call.  That's why we use select instead.
> 
> I thought that #3 might be out of the question, and I'm glad to know
> that the IO is indeed retried
> 
> > Also, floods of non-fatal error returns from recvfrom are generally logged for informational purposes, but can be controlled by the --mute option so as not to clog up the log files.
> 
> I'll keep that in mind, but for now I think I'll keep the verbosity to
> help in tracking
> 
> > You also mention that sometimes the session drops.  What do you mean?  Does OpenVPN crash or exit?  Does it try to renegotiate?  Does the tunnel die for a while and then come back?  What kind of encryption mode are you running in (Static Key, TLS, or cleartext)?
> 
> The tunnel seems to survive, but any open telnet/ssh/etc. session over
> it timeout and die.

Unfortunately, OpenVPN doesn't have control over the timeouts of application protocols that run over the tunnel.

So if there's a network outage, though OpenVPN will almost certainly recover when the network comes up, applications with connections on the tunnel may time out.

> 
> For now, I'm using a static key, but would like to move to certificates.
> 
> > Since I don't know how to reproduce this, I'll need more details.
> 
> It happens here every other day or so, I'll be glad to provide any
> information I can.
> 
> -- 
> Rick Nelson
> I can saw a woman in two, but you won't want to look in the box when I do
> 'For My Next Trick I'll Need a Volunteer' -- Warren Zevon
> 

James

Fwd: [Openvpn-devel] Fwd: Bug#158404: openvpn: Improper error handling

[James Y. <ji...@yo...>]

Hello Richard,

Normally we shouldn't get EAGAIN in the UDP read loop because we block on select and don't call recvfrom until there is a datagram waiting for us.  So the fact that you are getting a lot of EAGAIN messages is interesting and probably indicative of some kind of problem.  Is there any correlation between the EAGAIN floods and some sort of real world factor such as a bad or congested network condition?

If EAGAIN is received from recvfrom (or any other error for that matter), it is syslogged and the select event loop continues.  So your potential solutions 1 and 2 below are already being done.  Solution 3 doesn't work because OpenVPN is too asynchronous to be able to block on a single i/o call.  That's why we use select instead.

Also, floods of non-fatal error returns from recvfrom are generally logged for informational purposes, but can be controlled by the --mute option so as not to clog up the log files.

You also mention that sometimes the session drops.  What do you mean?  Does OpenVPN crash or exit?  Does it try to renegotiate?  Does the tunnel die for a while and then come back?  What kind of encryption mode are you running in (Static Key, TLS, or cleartext)?

Since I don't know how to reproduce this, I'll need more details.

James

> ----- Forwarded message from Richard A Nelson <co...@vn...> -----
> 
> From: Richard A Nelson <co...@vn...>
> Reply-To: Richard A Nelson <co...@vn...>,
> 	15...@bu...
> To: su...@bu...
> Subject: Bug#158404: openvpn: Improper error handling
> Date: Mon, 26 Aug 2002 17:28:37 -0400
> X-Spam-Status: No, hits=-4.5 required=5.0 tests=SENT_BY_BTS,FORGED_RCVD_FOUND version=2.20
> 
> Package: openvpn
> Version: 1.3.0-1
> Severity: important
> 
> I often get a flood of these messages:
> openvpn[1239]: read from UDP: Resource temporarily unavailable (errno=11)
> 
> The condition persists for a bit, and then clears up...  While the errors
> are occuring, occasionally the session will drop ;(
> 
> It seems to be improper handling of EAGAIN !
> The potential solutions would most likely be:
> 	1) re-try the systemcall
> 	2) redrive the read loop
> 	3) set blocking IO
> 
> -- System Information
> Debian Release: testing/unstable
> Kernel Version: Linux badlands.lexington.ibm.com 2.4.20-pre4-ac1 #13 Sat Aug 24 19:11:43 EDT 2002 i686 unknown unknown GNU/Linux
> 
> Versions of the packages openvpn depends on:
> ii  libc6          2.2.5-14       GNU C Library: Shared libraries and Timezone
> ii  liblzo1        1.07-1         A real-time data compression library.
> ii  libssl0.9.6    0.9.6g-2       SSL shared libraries
> 
> ----- End forwarded message -----
> 
> -- 
> Alberto Gonzalez Iniesta       | They that give up essential liberty
> ag...@ag...                     | to obtain a little temporary safety
> Encrypted mail preferred       | deserve neither liberty nor safety.
> 
> Key fingerprint = 9782 04E7 2B75 405C F5E9  0C81 C514 AF8E 4BA4 01C3
> 
> 
> -------------------------------------------------------
> This sf.net email is sponsored by: OSDN - Tired of that same old
> cell phone?  Get a new here for FREE!
> https://www.inphonic.com/r.asp?r=sourceforge1&refcode1=vs3390
> _______________________________________________
> Openvpn-devel mailing list
> Ope...@li...
> https://lists.sourceforge.net/lists/listinfo/openvpn-devel
> 



-- 

[Openvpn-devel] Fwd: Bug#158404: openvpn: Improper error handling

[Alberto G. I. <ag...@ag...>]

Hi James et al,

I just came back from holidays and got this bug report in Debian. (Seems
like IBM is using OpenVPN). I didn't have time to look at it yet, but
I'm sure you'll handle it better anyway :)

Best regards,

Alberto



----- Forwarded message from Richard A Nelson <co...@vn...> -----

From: Richard A Nelson <co...@vn...>
Reply-To: Richard A Nelson <co...@vn...>,
	15...@bu...
To: su...@bu...
Subject: Bug#158404: openvpn: Improper error handling
Date: Mon, 26 Aug 2002 17:28:37 -0400
X-Spam-Status: No, hits=-4.5 required=5.0 tests=SENT_BY_BTS,FORGED_RCVD_FOUND version=2.20

Package: openvpn
Version: 1.3.0-1
Severity: important

I often get a flood of these messages:
openvpn[1239]: read from UDP: Resource temporarily unavailable (errno=11)

The condition persists for a bit, and then clears up...  While the errors
are occuring, occasionally the session will drop ;(

It seems to be improper handling of EAGAIN !
The potential solutions would most likely be:
	1) re-try the systemcall
	2) redrive the read loop
	3) set blocking IO

-- System Information
Debian Release: testing/unstable
Kernel Version: Linux badlands.lexington.ibm.com 2.4.20-pre4-ac1 #13 Sat Aug 24 19:11:43 EDT 2002 i686 unknown unknown GNU/Linux

Versions of the packages openvpn depends on:
ii  libc6          2.2.5-14       GNU C Library: Shared libraries and Timezone
ii  liblzo1        1.07-1         A real-time data compression library.
ii  libssl0.9.6    0.9.6g-2       SSL shared libraries

----- End forwarded message -----

-- 
Alberto Gonzalez Iniesta       | They that give up essential liberty
ag...@ag...                     | to obtain a little temporary safety
Encrypted mail preferred       | deserve neither liberty nor safety.

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

[Openvpn-devel] Ramifications on OpenVPN of OpenSSL security announcement

[James Y. <ji...@nt...>]

As many of you have probably noticed, the OpenSSL project released a
security update today which fixes potential remote buffer overflows.

What you may not have known is that the ASN1 parser bug was independently
discovered in the process of stress testing OpenVPN, earning yours truly the
dubious distinction of being acknowledged in the security advisory.

So here's the scoop for OpenVPN users:

(1) If you are using preshared static key mode, you are not vulnerable.

(2) If you are using TLS mode with --tls-auth, you are not vulnerable.

(3) If you are using TLS mode without --tls-auth, you may be vulnerable if
you are also using --float.

If you think you are vulnerable, the quickest fix is to start
using --tls-auth, which was explicitly designed to protect against buffer
overflows in OpenSSL by creating a two-tier authentication hierarchy that
forces ALL incoming packets to authenticate via HMAC before they are passed
on to the TLS code in OpenSSL.  Think of it as a kind of MAC firewall.

In general you should also consider downgrading privileges with --user
and/or --group, to limit the damage that would be caused by a remote buffer
overflow attack.  If for whatever reason you must run as root, then consider
using the --chroot option to lock the OpenVPN daemon into a restricted
filesystem, so that a remote attack would not be able to modify sensitive
files.

Of course most systems have a lot of other apps and daemons that depend on
OpenSSL so upgrading ASAP is probably the best course.

James

Re: [Openvpn-devel] NetBSD patch for OpenVPN

[Dimitri G. <dm...@su...>]

Hi,

>One question I have, were you able to connect OpenVPN running on NetBSD to
>OpenVPN running on a different platform such as Linux?

Yes, my peer is a Linux box.

Re: [Openvpn-devel] NetBSD patch for OpenVPN

[James Y. <ji...@nt...>]

Dimitri,

Thanks for the patch, I will apply it to the CVS shortly.

One question I have, were you able to connect OpenVPN running on NetBSD to
OpenVPN running on a different platform such as Linux?

I ask because some tun/tap devices will prepend unnecessary stuff onto the
datagram that must be disabled with an explicit ioctl call if cross-platform
compatibility is to be preserved.  You can see some examples of this in
tun.c.

If this is the case, you might find that NetBSD <-> NetBSD tunnels work
fine, but NetBSD <-> Linux tunnels are broken.  Just something to check for
if possible...

James

----- Original Message -----
From: "Dimitri Goldin" <dm...@su...>
To: <ope...@li...>
Sent: Friday, July 26, 2002 3:58 PM
Subject: [Openvpn-devel] NetBSD patch for OpenVPN


> Hello list,
>
> The patch for the NetBSD "support" ist ready.
> I only added some entries for NetBSD and used the same ifconfig code
> as OpenBSD in tun.c.
> The patch is attached.
> I hope I did everything right.
>
> Cheers,
>         Dimitri
> --
> pub  1024D/3A264EA8 2002-07-07 Dimitri Goldin <dm...@su...>
> Fingerprint: 3AA9 1264 51AA 0BB5 EB29  A6E3 9648 F42A 3A26 4EA8
>                                                 "Don't Panic."
>
>

[Openvpn-devel] NetBSD patch for OpenVPN

[Dimitri G. <dm...@su...>]

Hello list,                                                                     
                                                                                
The patch for the NetBSD "support" ist ready.                                   
I only added some entries for NetBSD and used the same ifconfig code            
as OpenBSD in tun.c.                                                            
The patch is attached.                                            
I hope I did everything right.              
                                                                                
Cheers,                                                                         
        Dimitri               
--                                                                              
pub  1024D/3A264EA8 2002-07-07 Dimitri Goldin <dm...@su...>              
Fingerprint: 3AA9 1264 51AA 0BB5 EB29  A6E3 9648 F42A 3A26 4EA8                 
                                                "Don't Panic."                  
                                                                                                                    

Re: [Openvpn-devel] OpenVPN on NetBSD

[James Y. <ji...@nt...>]

Hi Dimitri,

Yes, it would be great if you would like to do a NetBSD port.  I imagine it
would be pretty straightforward, given the existence of FreeBSD, OpenBSD,
and Mac OS X ports.

The "PORTS" file has a nice rundown on making a clean port, with some points
on testing to make sure all the major features work correctly.

Best Regards,
James

> Hello developers,
>
> Tried to setup a vpn with a friend today.
> The box ist running NetBSD 1.5.2.
> But when I tried to start the openvpn with "ifconfig 10.0.0.2 10.0.0.1" in
> my config file I've got the error
> "Sorry, but I don't know how to do 'ifconfig'
> commands on this operating system. You should ifconfig your tun/tap device
> manually or use an --up script."
>
> The --up thing didn't woked. I tried "--up ifconfig 10.0.0.2
> 10.0.0.2". I don't know why but it always did:
> 4: tun/tap device /dev/tun1 opened
> 5: ifconfig tun1 10.0.0.2 10.0.0.1 tun1 1300 1344
>
> After some testings I've decided to try the OpenBSD ifconfig code in tun.c
> since the syntax is similar for such simple operations.
> I replaced the message about unknown ifconfig with this code and it
> worked without any problems.
> It's quick and dirty, but if there is interest in a NetBSD port then
I will add it properly.

>
> Greets,
>         Dimitri
> --
> "A towel is about the most massively useful
>  thing an interstellar hitch hiker can have." -- Hitchicker's Guide
> pub  1024D/3A264EA8 2002-07-07 Dimitri Goldin <dm...@su...>
> Fingerprint: 3AA9 1264 51AA 0BB5 EB29  A6E3 9648 F42A 3A26 4EA8
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by: Jabber - The world's fastest growing
> real-time communications platform! Don't just IM. Build it in!
> http://www.jabber.com/osdn/xim
> _______________________________________________
> Openvpn-devel mailing list
> Ope...@li...
> https://lists.sourceforge.net/lists/listinfo/openvpn-devel
>

[Openvpn-devel] OpenVPN on NetBSD

[<dm...@th...>]

Hello developers,                                                               
                                                                                
Tried to setup a vpn with a friend today.                                       
The box ist running NetBSD 1.5.2.                                               
But when I tried to start the openvpn with "ifconfig 10.0.0.2 10.0.0.1" in      
my config file I've got the error                                               
"Sorry, but I don't know how to do 'ifconfig'                                   
commands on this operating system. You should ifconfig your tun/tap device      
manually or use an --up script."                                                
                                                                                
The --up thing didn't woked. I tried "--up ifconfig 10.0.0.2                    
10.0.0.2". I don't know why but it always did:                                  
4: tun/tap device /dev/tun1 opened                                              
5: ifconfig tun1 10.0.0.2 10.0.0.1 tun1 1300 1344                               
                                                                                
After some testings I've decided to try the OpenBSD ifconfig code in tun.c      
since the syntax is similar for such simple operations.                         
I replaced the message about unknown ifconfig with this code and it             
worked without any problems.                                                    
It's quick and dirty, but if there is interest in a NetBSD port then            I will add it properly.                                                         
                                                                                
Greets,                                                                         
        Dimitri                                                                 
--                                                                              
"A towel is about the most massively useful                                     
 thing an interstellar hitch hiker can have." -- Hitchicker's Guide             
pub  1024D/3A264EA8 2002-07-07 Dimitri Goldin <dm...@su...>              
Fingerprint: 3AA9 1264 51AA 0BB5 EB29  A6E3 9648 F42A 3A26 4EA8                 

Re: [Openvpn-devel] Multiple VPN connections on the same port

[Sampo N. <aud...@au...>]

> > > Hi Sampo,
> > >
> > > > I have been busy writing a forking server
> > > > addon to openvpn.
>
> Will forking server only work for TLS mode?

No, It works also with shared secret or without
security.

For prefork security I could use either the key used
for tls-auth or preshared secret.

Any examples of how to implement tls-auth like
authentication in simples form?

> > --remote as server addres in the client.
> >
> > I just got it running. Still with out dynamic ip address assigment
> > and proper signal handling in parent process. And there ain't
> > anykind of DoS protection yet.
>
> One way to do DoS protection would be to augment --tls-auth with persistent
> anti-replay protection by saving the Session ID (struct session_id) and
> reject any Session ID that was seen before.

Let's see when I get it working. :-)

> > port before calling openvpn(). Mayby I could add the exchange of
> > address info here, since I don't think it needs to be
> > transferred over a secure channel.
>
> Actually the temporary keys + options_string() get passed over the secure
> TLS channel, so you could add further handshaking options and they would be
> secure.



> >
> > > > This way I have been able to keep
> > > > those well tested procedures and protocol
> > > > of openvpn untouched.
> > > >
> > > > I still have some questions unsolved like
> > > > DoS protection, dropping root priviledges
> > > > and how to handel SIGUSR1 and SIGHUP.
>
> It would be cool if we could get the forking server to work with dropping
> root privs.
>
> One of the goals of dropping privs is that no datagram is ever read from the
> network with root privs.
>
> It would be great if we could preserve this behavior.
>
> Otherwise the split privileges model of the new openssh would be a
> possibility, but it's more complex.


For a forking server accepting connections from any ip, I
consider it even more critical than for a peer2peer version.

I did it simply by calling set_user() in the
server's main process and everything seems to work at least
for me.

Don't know if this works in all cases since the server drops
priviledges before opening tun dev.


Sampo