openvpn-devel — OpenVPN developers list

Re: [Openvpn-devel] Openvpn for RH62 - eek!

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

How do most other initialization scripts handle the differences between bash 1
and 2?  Do they just restrict themselves to the least common denominator (a)?

Or do they try to explicitly instantiate bash2 (b)?

-#!/bin/sh
+#!/bin/bash2

(b) could be risky if there are distros where where /bin/bash2 is not present.

I would lean towards (a) if trivial changes in the script can make it both
bash1 and bash2 compliant.  If that is not the case, and we think that we have
a reliable, distro-independent method to instantiate bash2, then I would favor
(b).

What does the patch look like for (a)?

James

bishop <bi...@pl...> said:

> James, Folks,
> 
> I noticed a minor problem as my RH62 box started up:
> 
> > $Starting openvpn: /etc/rc.d/init.d/openvpn: [: ==: binary operator expected
> 
> That's two distinct, common errors:
>   - $localization stuff that doesn't work on bash1
>   - an == in a [] in the script.
> 
> These are both directly related to the fact that the standard bash on 
> RH62 is bash1.  We can fix compatibility in a few ways:
>   - ignore the odd $localization $artefact and make the one change to 
> the init script (as if we did perl -pi -e 's:==:=:' to is) in one place.
> 
> OR
>   - this patch:
> 
> > --- /etc/rc.d/init.d/openvpn~	Sun Apr 27 03:51:51 2003
> > +++ /etc/rc.d/init.d/openvpn	Thu May  1 12:07:50 2003
> > @@ -1,4 +1,4 @@
> > -#!/bin/sh
> > +#!/bin/bash2
> >  #
> >  # openvpn       This shell script takes care of starting and stopping
> >  #               openvpn.
> 
> Super-trivial, but I'm wondering about any possible complications with 
> either approach.  As it is now, we do have a valid bug in that, on RH62, 
> openVPN will not start.
> 
> (I also noticed I can start it multiple times.  This may be another 
> problem - service openvpn start ; service openvpn start ; service 
> openvpn start ; service openvpn start - because it should normally 
> generate a minor gripe message)
> 
> Anyway, whatever the consensus, I can submit a patch.
> 
>   - bish
> 
> -- 
> 	"Every well-bred petty crook knows -- the small concealable
> 	weapons always go to the far left of the place setting."
> 		-- Inara (Morena Baccarin), "Firefly"
> 		   (unaired - into production AFTER fox crushed it)
> 
> 
> 
> -------------------------------------------------------
> 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] Openvpn for RH62 - eek!

[bishop <bi...@pl...>]

James, Folks,

I noticed a minor problem as my RH62 box started up:

> $Starting openvpn: /etc/rc.d/init.d/openvpn: [: ==: binary operator expected

That's two distinct, common errors:
  - $localization stuff that doesn't work on bash1
  - an == in a [] in the script.

These are both directly related to the fact that the standard bash on 
RH62 is bash1.  We can fix compatibility in a few ways:
  - ignore the odd $localization $artefact and make the one change to 
the init script (as if we did perl -pi -e 's:==:=:' to is) in one place.

OR
  - this patch:

> --- /etc/rc.d/init.d/openvpn~	Sun Apr 27 03:51:51 2003
> +++ /etc/rc.d/init.d/openvpn	Thu May  1 12:07:50 2003
> @@ -1,4 +1,4 @@
> -#!/bin/sh
> +#!/bin/bash2
>  #
>  # openvpn       This shell script takes care of starting and stopping
>  #               openvpn.

Super-trivial, but I'm wondering about any possible complications with 
either approach.  As it is now, we do have a valid bug in that, on RH62, 
openVPN will not start.

(I also noticed I can start it multiple times.  This may be another 
problem - service openvpn start ; service openvpn start ; service 
openvpn start ; service openvpn start - because it should normally 
generate a minor gripe message)

Anyway, whatever the consensus, I can submit a patch.

  - bish

-- 
	"Every well-bred petty crook knows -- the small concealable
	weapons always go to the far left of the place setting."
		-- Inara (Morena Baccarin), "Firefly"
		   (unaired - into production AFTER fox crushed it)

Re: [Openvpn-devel] 2nd release candidate for 1.4.0

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

Alberto Gonzalez Iniesta <ag...@ag...> said:

> Builds and works like a charm in Debian.
> 
> Building OpenVPN with FRAGMENT_ENABLE shouldn't affect tunnels against
> older versions without this option, right?

Correct.

> In that case, I think I'll enable this option in Debian's packages so
> we can get some testing/feedback on it. Good idea?

FRAGMENT_ENABLE is still pretty experimental, so I would hesitate to enable it
by default.  Since I have not enabled it for the most of the pre-1.4.0 testing
I have done, I think it would make more sense to leave it off in default
distributions, lest it produce any surprises.

On the other hand, there's a bunch of new infrastructure to handle dynamic
MTUs (In mtu.[ch]).  This is enabled by default and has been part of the test
cycle.

James

Re: [Openvpn-devel] 2nd release candidate for 1.4.0

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

Builds and works like a charm in Debian.

Building OpenVPN with FRAGMENT_ENABLE shouldn't affect tunnels against
older versions without this option, right?

In that case, I think I'll enable this option in Debian's packages so
we can get some testing/feedback on it. Good idea?

Regards,

Alberto

On Wed, Apr 30, 2003 at 05:39:48AM -0000, James Yonan wrote:
> 
> This release candidate fixes some build problems that surfaced on the outliers
> of the RedHat distribution (6.2 and 9.0).  Other minor fixes as well (see the
> change log).
> 
> Tarball is here:
> 
> http://openvpn.sourceforge.net/beta/openvpn-1.3.2.30.tar.gz
> 
> James
> 
> 
> 
> 
> -------------------------------------------------------
> 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

-- 
Alberto Gonzalez Iniesta       | They that give up essential liberty
agi@(agi.as|debian.org)        | 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] 2nd release candidate for 1.4.0

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

This release candidate fixes some build problems that surfaced on the outliers
of the RedHat distribution (6.2 and 9.0).  Other minor fixes as well (see the
change log).

Tarball is here:

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

James

Re: [Openvpn-devel] Fwd: Re: comp-lzo and licensing issues

[bishop <bi...@pl...>]

>> Of course another option here is to consider getting OpenVPN to play nice
>> with gnutls, though I am not familiary with the maturity of that piece of
>> software.

Does anyone else here consider this to be entirely the wrong way to go?

First off, the problem appears to be one that's present in all cases 
where GPL-licensed software is linked with non-GPL-licensed software 
(I'm lazy, and assuming OpenSSL is `BSD).  The OpenSSL people are only 
stating a commonly-overlooked problem that will eventually bite every 
single one of us.

So, what do we do?  We write an exeption in a GPL-licensed project's 
software license?  That only seems shady on the surface, like one's 
trying to exempt oneself from someone else's licensing - -I'd like to do 
that with MS.  In fact, the only problem is that, soon, maintainers of 
GPL-licensed projects will need to maintain an entire list of 
exemptions, and it may eventually be larger than the GPL boilerplate - 
no mean feat, but as time_t->oo ...

I think that this is another example of how the GPL1 license is really 
not intended for a world that is not either entirely GPL or entirely 
non-GPL.  It's perhaps meant to eventually edge-out the non-GPL 
licenses, something we'd normally consider a bit more difficult if it 
weren't the much-loved GNU doing it.  The motives are similar to any 
other empire-builder (Oh yes, and please let us remora the name of your 
operating system).

I would suggest, for our sanity and not for the sake of any freedom we 
require to link with whatever projects we choose, that we do NOT 
consider adding any more GPL-covered projects to this one.  In case we 
run into any more snags, the remaining GPL bits can be pulled more easily.

Is this an issue that should be Asked of Slashdot?

  - bish

DISCLAIMERS:

This message is only half-formed, having been the product of a mere hour 
of thought and discussion on the issue with co-workers, none of whom 
were lawyers.  It is neither logically complete nor sound.

I am biased.  Normally I'm an annoying, opinionated, proselytizing 
grouchy recluse, emerging from my cave only to yell "Dooooom" in a James 
Earl Jones voice.

I work for a company that works with linux and tries to make a profit; 
that's two distinct halves of a company that do not often mix due to 
legal reasons.  Ironically, many free vendors trying to make money on 
'free' software employ full-time legal teams whose sole job is to 
prevent the company running afoul of the GPL and other licenses;  I'm 
not a member of that part of my company, thankfully (IANAL).



Aaron Sethman wrote:
> On Mon, 28 Apr 2003, Alberto Gonzalez Iniesta wrote:
> 
> 
>>Hi all,
>>
>>Sorry for the huge forward, but everything needed to understand this
>>problem should be there :)
>>
>>GPL software does not mix well with OpenSSL, and that's giving me some
>>headaches lately. As you me see in my mail to Markus (liblzo author) and
>>James (we all know who he is :) linking liblzo with OpenSSL may be a GPL
>>violation [1].
>>
>>So this is a call for comments on this issue.
>>Can anybody reach Markus and comment him about this?
>>Should we switch to another compression library? In that case, which one
>>would be suitable? zlib?
>>Should we ignore this and let RMS jump on us? [2]
> 
> 
> Well zlib could be suitable, considering that OpenVPN does implement some
> reliable UDP stuff for SSL/TLS type streams to work correctly.  Of course
> it might be a performance hit.  On the other hand, if you are linking it
> yourself and not redistributing the binaries you are probably okay.  This
> means though that prebuilt binaries linked to liblzo could be a no-no.
> 
> Of course the slope gets slippery if OpenSSL is shipped with the OS by
> default and is considered a 'system library'.  In such case it might not
> necessarly be a violation, otherwise linking GPL software on a system like
> Solaris and distribution the resulting binaries would be forbidden as
> well.
> 
> Of course another option here is to consider getting OpenVPN to play nice
> with gnutls, though I am not familiary with the maturity of that piece of
> software.
> 
> Regards,
> 
> Aaron
> 
> 
> -------------------------------------------------------
> 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

-- 
	"Every well-bred petty crook knows -- the small concealable
	weapons always go to the far left of the place setting."
		-- Inara (Morena Baccarin), "Firefly"
		   (unaired - into production AFTER fox crushed it)

Re: [Openvpn-devel] Fwd: Re: comp-lzo and licensing issues

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

On Mon, 28 Apr 2003, Alberto Gonzalez Iniesta wrote:

> Hi all,
>
> Sorry for the huge forward, but everything needed to understand this
> problem should be there :)
>
> GPL software does not mix well with OpenSSL, and that's giving me some
> headaches lately. As you me see in my mail to Markus (liblzo author) and
> James (we all know who he is :) linking liblzo with OpenSSL may be a GPL
> violation [1].
>
> So this is a call for comments on this issue.
> Can anybody reach Markus and comment him about this?
> Should we switch to another compression library? In that case, which one
> would be suitable? zlib?
> Should we ignore this and let RMS jump on us? [2]

Well zlib could be suitable, considering that OpenVPN does implement some
reliable UDP stuff for SSL/TLS type streams to work correctly.  Of course
it might be a performance hit.  On the other hand, if you are linking it
yourself and not redistributing the binaries you are probably okay.  This
means though that prebuilt binaries linked to liblzo could be a no-no.

Of course the slope gets slippery if OpenSSL is shipped with the OS by
default and is considered a 'system library'.  In such case it might not
necessarly be a violation, otherwise linking GPL software on a system like
Solaris and distribution the resulting binaries would be forbidden as
well.

Of course another option here is to consider getting OpenVPN to play nice
with gnutls, though I am not familiary with the maturity of that piece of
software.

Regards,

Aaron

[Openvpn-devel] Fwd: Re: comp-lzo and licensing issues

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

Hi all,

Sorry for the huge forward, but everything needed to understand this
problem should be there :)

GPL software does not mix well with OpenSSL, and that's giving me some
headaches lately. As you me see in my mail to Markus (liblzo author) and
James (we all know who he is :) linking liblzo with OpenSSL may be a GPL
violation [1].

So this is a call for comments on this issue. 
Can anybody reach Markus and comment him about this?
Should we switch to another compression library? In that case, which one
would be suitable? zlib?
Should we ignore this and let RMS jump on us? [2]

Hoping to get lots of feedback,

Alberto

[1] http://www.openssl.org/support/faq.html#LEGAL2
[2] Yes, it's a joke

----- Forwarded message from James Yonan <ji...@yo...> -----

From: James Yonan <ji...@yo...>
To: Alberto Gonzalez Iniesta <ag...@ag...>
Subject: Re: comp-lzo and licensing issues
Date: Sat, 26 Apr 2003 16:57:26 -0000
X-SpamProbe: GOOD 0.0000000 6c2c0cd892c1100831080d47b6f1d8e2

Hi Alberto,

How are you doing?  I haven't heard from you for a while!

Interesting problem.  Well I hope that Markus will agree to the linkage.

It seems that this must be a common problem, if GPL cannot co-exist with
licenses which are still open source but non-GPL.  It also seems that the
whole notion of "linkage" is a thorny issue and would need to be rigorously
defined.  For example, does

gpl-program | non-gpl-program > conundrum.log

constitute linkage?

What if the linkage is between components in user space and kernel space that
have different licenses, but otherwise comingle in the same address space?

Is linkage via shared libraries or static linkage different from interprocess
communication linkages or network communication linkages?

As you mention, zlib is certainly another option, though I don't know how it
scores in the realtime category.  It would also need to be able to
compress/decompress small blocks (i.e. MTU sized) without reference to other
blocks or cross-block state-info.

I would agree that you should post something to openvpn-devel about this.

Best Regards,
James

Alberto Gonzalez Iniesta <ag...@ag...> said:

> 
> --/WwmFnJnmDyWGHa4
> Content-Type: text/plain; charset=us-ascii
> Content-Disposition: inline
> Content-Transfer-Encoding: quoted-printable
> 
> Hi James,
> 
> First of all, sorry for the delay in contacting you about this.  :(
> I'm mailing you off the list because this is can be picky subject. You
> may take this subject to the list whenever you feel like.
> 
> As you can see in http://bugs.debian.org/177497 , I had to disable
> liblzo support in Debian's packages due to a (possible) GPL violation.
> 
> Remember the exception you did to OpenVPN's license so it could be built
> against OpenSSL? Well, the same thing should be done with liblzo. I
> mailed liblzo's author on Jan 26, but I got no answer from him. (See
> attachment)
> 
> So, what happens now? From my point of view, we have two choices:
> a) Try (again) to convince LZO's author to make the exception in his
> source. Until that happens I won't be able to package OpenVPN with LZO
> support (and lots of people require it. See bugs.d.o/182549 and 187117)
> 
> b) My No 1 wishlist request for OpenVPN: a new compression library.
> For example: zlib, which uses a BSD like license and it's used in
> OpenSSH.
> 
> Please, let me know what you think of all this. And, of course, feel
> free to take this discussion to the -devel list.
> 
> Thanks,
> 
> Alberto
> 
> --=20
> Alberto Gonzalez Iniesta       | They that give up essential liberty
> agi@(agi.as|debian.org)        | to obtain a little temporary safety
> Encrypted mail preferred       | deserve neither liberty nor safety.
> 
> Key fingerprint =3D 9782 04E7 2B75 405C F5E9  0C81 C514 AF8E 4BA4 01C3
> 
> --/WwmFnJnmDyWGHa4
> Content-Type: message/rfc822
> Content-Disposition: inline
> 
> Date: Sun, 26 Jan 2003 10:51:01 +0100
> From: Alberto Gonzalez Iniesta <ag...@ag...>
> To: Markus Franz Xaver Johannes Oberhumer <mar...@jk...>
> Subject: Compiling and/or linking liblzo with OpenSSL
> Message-ID: <200...@va...>
> Mime-Version: 1.0
> Content-Type: text/plain; charset=us-ascii
> Content-Disposition: inline
> User-Agent: Mutt/1.5.3i
> 
> Hi Markus,
> 
> I'm the Debian Maintainer of OpenVPN (http://openvpn.sourceforge.net).
> OpenVPN is, as you may guess, a VPN software with liblzo support for
> improved performance. It's GPL'ed just like liblzo, but uses OpenSSL.
> 
> It seems that GPL and OpenSSL don't mix well:
> http://www.openssl.org/support/faq.html#LEGAL2
> 
> Since we're *very* picky with licenses in Debian, I had to disable libzo
> support in Debian's OpenVPN packages (http://bugs.debian.org/177497).
> That's far from being the best solution to the 'problem', which is
> adding a little exception to liblzo's license. OF COURSE IF, AND ONLY IF
> you completely agree with your source compiling, linking, and/or using
> OpenSSL in any case.
> 
> The exception would be something like this (from OpenVPN's one):
> 
> 
>     In addition, as a special exception, **your name here ** gives
>     permission to link the code of this program with the OpenSSL
>     library (or with modified versions of OpenSSL that use the same
>     license as OpenSSL), and distribute linked combinations including
>     the two.  You must obey the GNU General Public License in all
>     respects for all of the code used other than OpenSSL.  If you modify
>     this file, you may extend this exception to your version of the
>     file, but you are not obligated to do so.  If you do not wish to
>     do so, delete this exception statement from your version.
> 
> 
> Thanks for your time. I'm looking forward to hearing from you soon and 
> hope to be able to use liblzo in OpenVPN from now on :)
> 
> Alberto
> 



-- 



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

-- 
Alberto Gonzalez Iniesta       | They that give up essential liberty
agi@(agi.as|debian.org)        | 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

Re: [Openvpn-devel] TCP-over-TCP (was: Multi-channel VPN)

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

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

> 
> On Thu, 24 Apr 2003, James Yonan wrote:
> > Actually, I was thinking more about the situation where people are forced to
> > tunnel IP over TCP, for whatever reason, when UDP is not an option.  Since IP
> > is designed to transit over an unreliable physical layer, when you tunnel it
> > over TCP (a la vpnd or IP over ssh) you end up with this problem:
> >
> > http://sites.inka.de/sites/bigred/devel/tcp-tcp.html (see Stacking TCPs)
> I've read the paper many times, heh ;)
> 
> >
> > The key issue here is that when you tunnel IP over TCP, that will usually mean
> > TCP over TCP.  And this tends to break TCP's retransmission algorithm.  As the
> > article above states: "The upper layer will queue up more retransmissions
> > faster than the lower layer can process them".
> >
> > So my idea is why not filter out the upper layer TCP retransmissions, and
> > synthesize the return ACKs so that the upper TCP layer doesn't begin the
> > exponential backing off of the retransmit timer that eventually will stall the
> > connection?  This process would essentially strip the upper layer TCP of its
> > reliability function, since now the lower TCP layer will provide that
> > function.  This is not difficult to implement, since to OpenVPN, the upper
> > layer protocols are all simply byte streams flowing over the TUN pipe.  They
> > can be filtered without resorting to raw sockets or any other such potentially
> > unportable constructs.
> What if you end up filtering out necessary retransmissions that occur
> elsewhere on the path.  Consider the situation of one end being a router
> and passing packets out to the rest of the world, and openvpn is being
> used to brige an insecure link like say an 802.11b network.  Personally I
> think mucking with this could be dangerous.

That's a good point.  Once you synthesize an ACK to avoid retransmission over
the TCP-tunnel segment of the path, you are guaranteeing to the sender that
the packet has been received at the destination.  This means you would need to
do some accounting of TCP sequence numbers at both ends of the tunnel, so that
you could differentiate retransmits caused by local congestion on the
TCP-tunnel from retransmits occurring due to lossage elsewhere on the path. 
The more you look at it, the uglier it gets.

What you need is a kind of TCP mode that strips out the reliability function.
 Of course we have it, it's called UDP ;)

James

Re: [Openvpn-devel] TCP-over-TCP (was: Multi-channel VPN)

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

On Thu, 24 Apr 2003, James Yonan wrote:

> Actually, I was thinking more about the situation where people are forced to
> tunnel IP over TCP, for whatever reason, when UDP is not an option.  Since IP
> is designed to transit over an unreliable physical layer, when you tunnel it
> over TCP (a la vpnd or IP over ssh) you end up with this problem:
> 
> http://sites.inka.de/sites/bigred/devel/tcp-tcp.html (see Stacking TCPs)
> 
> The key issue here is that when you tunnel IP over TCP, that will usually mean
> TCP over TCP.  And this tends to break TCP's retransmission algorithm.  As the
> article above states: "The upper layer will queue up more retransmissions
> faster than the lower layer can process them".
> 
> So my idea is why not filter out the upper layer TCP retransmissions, and
> synthesize the return ACKs so that the upper TCP layer doesn't begin the
> exponential backing off of the retransmit timer that eventually will stall the
> connection?  This process would essentially strip the upper layer TCP of its

I think data volume (in flight or lost) is the issue, not stalls. Once
an ACK of the outer layer is returned, the inner layer will implicitly
also see an ACK (payload) which will then kick the data flow alive
again.

> reliability function, since now the lower TCP layer will provide that
> function.  This is not difficult to implement, since to OpenVPN, the upper
> layer protocols are all simply byte streams flowing over the TUN pipe.  They
> can be filtered without resorting to raw sockets or any other such potentially
> unportable constructs.

Only that OpenVPN would have to parse the TCP protocol for IPv4 and
IPv6.

-- 
Matthias Andree

Re: [Openvpn-devel] TCP-over-TCP (was: Multi-channel VPN)

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

On Thu, 24 Apr 2003, James Yonan wrote:
> Actually, I was thinking more about the situation where people are forced to
> tunnel IP over TCP, for whatever reason, when UDP is not an option.  Since IP
> is designed to transit over an unreliable physical layer, when you tunnel it
> over TCP (a la vpnd or IP over ssh) you end up with this problem:
>
> http://sites.inka.de/sites/bigred/devel/tcp-tcp.html (see Stacking TCPs)
I've read the paper many times, heh ;)

>
> The key issue here is that when you tunnel IP over TCP, that will usually mean
> TCP over TCP.  And this tends to break TCP's retransmission algorithm.  As the
> article above states: "The upper layer will queue up more retransmissions
> faster than the lower layer can process them".
>
> So my idea is why not filter out the upper layer TCP retransmissions, and
> synthesize the return ACKs so that the upper TCP layer doesn't begin the
> exponential backing off of the retransmit timer that eventually will stall the
> connection?  This process would essentially strip the upper layer TCP of its
> reliability function, since now the lower TCP layer will provide that
> function.  This is not difficult to implement, since to OpenVPN, the upper
> layer protocols are all simply byte streams flowing over the TUN pipe.  They
> can be filtered without resorting to raw sockets or any other such potentially
> unportable constructs.
What if you end up filtering out necessary retransmissions that occur
elsewhere on the path.  Consider the situation of one end being a router
and passing packets out to the rest of the world, and openvpn is being
used to brige an insecure link like say an 802.11b network.  Personally I
think mucking with this could be dangerous.

> Using raw sockets would be another potential method -- instead of removing the
> reliability function from the upper layer TCP layer, remove it from the lower
> layer.  This would require a sort of fake-TCP implementation in user-space
> with the reliability function stripped out.  On first glance, this seems to be
> a more complicated approach because you would need to implement a lot of the
> TCP protocol in user space, and you would need to depend on the OS supporting
> raw sockets.  The approach outlined in the previous paragraph doesn't need raw
> sockets, and it doesn't need to reimplement TCP.  It only needs to examine the
> byte stream of IP packets flowing over the TUN device, filter out TCP
> retransmits, and synthesize return TCP ACKs.
This is what I was thinking, however this is a really big pain in the rear
too.

> Each method tries to stabilize TCP-over-TCP by eliminating a redundant
> reliability layer.  Both of these methods, while somewhat ugly, would
> eliminate a big part of the robustness issue of IP over TCP, for those who
> lack IP over UDP as an option.

Or you could just tell users that you are to expect degraded performance
in this case and use UDP if possible.  But *if* you are stuck, and have no
other options, this will work, but it'll suck too.

I'm wondering if there are some socket options one could set to twiddle
the TCP stack into playing slightly nicer.  I doubt it, because you've
still got the issue of other systems not playing nice with it.


-Aaron

Re: [Openvpn-devel] TCP-over-TCP (was: Multi-channel VPN)

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

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

> 
> 
> On Wed, 23 Apr 2003, Matthias Andree wrote:
> 
> > On Wed, 23 Apr 2003, James Yonan wrote:
> >
> > > I wonder if one could build a better tcp-over-tcp by doing some intelligent
> > > packet filtering on the higher level tcp connection, such as filtering out
> > > retransmits and fudging return ACKs -- essentially removing those
elements of
> > > the TCP protocol which are designed to make TCP work over an unreliable
link.
> >
> > I wonder if that's necessary. Tunnelling through TCP is inherently
> > reliable no matter what you send, so TCP-nested-in-TCP is just overkill.
> > Cheating the OS doesn't help. Maybe some LD_PRELOAD library that turns
> > stream sockets into dgram sockets for connections that use the tunnel is
> > sufficient. However, this doesn't actually apply to openvpn because
> > openvpn does TCP-over-UDP.
> 
> I think you've got it backwards.  I think James is talking about the layer
> that openvpn is tunnelling over.  Basically fiddling with it to keep that
> layer from doing a lot of the reliabilitiy stuff.  To be honest I'm not
> sure its possible without using raw sockets and constructing your own TCP
> packets.  Even then though, I don't think that would work for some
> people's needs like being able to shove it through an SSL proxy or
> something like that.

Actually, I was thinking more about the situation where people are forced to
tunnel IP over TCP, for whatever reason, when UDP is not an option.  Since IP
is designed to transit over an unreliable physical layer, when you tunnel it
over TCP (a la vpnd or IP over ssh) you end up with this problem:

http://sites.inka.de/sites/bigred/devel/tcp-tcp.html (see Stacking TCPs)

The key issue here is that when you tunnel IP over TCP, that will usually mean
TCP over TCP.  And this tends to break TCP's retransmission algorithm.  As the
article above states: "The upper layer will queue up more retransmissions
faster than the lower layer can process them".

So my idea is why not filter out the upper layer TCP retransmissions, and
synthesize the return ACKs so that the upper TCP layer doesn't begin the
exponential backing off of the retransmit timer that eventually will stall the
connection?  This process would essentially strip the upper layer TCP of its
reliability function, since now the lower TCP layer will provide that
function.  This is not difficult to implement, since to OpenVPN, the upper
layer protocols are all simply byte streams flowing over the TUN pipe.  They
can be filtered without resorting to raw sockets or any other such potentially
unportable constructs.

Using raw sockets would be another potential method -- instead of removing the
reliability function from the upper layer TCP layer, remove it from the lower
layer.  This would require a sort of fake-TCP implementation in user-space
with the reliability function stripped out.  On first glance, this seems to be
a more complicated approach because you would need to implement a lot of the
TCP protocol in user space, and you would need to depend on the OS supporting
raw sockets.  The approach outlined in the previous paragraph doesn't need raw
sockets, and it doesn't need to reimplement TCP.  It only needs to examine the
byte stream of IP packets flowing over the TUN device, filter out TCP
retransmits, and synthesize return TCP ACKs.

Each method tries to stabilize TCP-over-TCP by eliminating a redundant
reliability layer.  Both of these methods, while somewhat ugly, would
eliminate a big part of the robustness issue of IP over TCP, for those who
lack IP over UDP as an option.

James

Re: [Openvpn-devel] TCP-over-TCP (was: Multi-channel VPN)

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

On Wed, 23 Apr 2003, Matthias Andree wrote:

> On Wed, 23 Apr 2003, James Yonan wrote:
>
> > I wonder if one could build a better tcp-over-tcp by doing some intelligent
> > packet filtering on the higher level tcp connection, such as filtering out
> > retransmits and fudging return ACKs -- essentially removing those elements of
> > the TCP protocol which are designed to make TCP work over an unreliable link.
>
> I wonder if that's necessary. Tunnelling through TCP is inherently
> reliable no matter what you send, so TCP-nested-in-TCP is just overkill.
> Cheating the OS doesn't help. Maybe some LD_PRELOAD library that turns
> stream sockets into dgram sockets for connections that use the tunnel is
> sufficient. However, this doesn't actually apply to openvpn because
> openvpn does TCP-over-UDP.

I think you've got it backwards.  I think James is talking about the layer
that openvpn is tunnelling over.  Basically fiddling with it to keep that
layer from doing a lot of the reliabilitiy stuff.  To be honest I'm not
sure its possible without using raw sockets and constructing your own TCP
packets.  Even then though, I don't think that would work for some
people's needs like being able to shove it through an SSL proxy or
something like that.

Aaron

Re: [Openvpn-devel] TCP-over-TCP (was: Multi-channel VPN)

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

On Wed, 23 Apr 2003, James Yonan wrote:

> I wonder if one could build a better tcp-over-tcp by doing some intelligent
> packet filtering on the higher level tcp connection, such as filtering out
> retransmits and fudging return ACKs -- essentially removing those elements of
> the TCP protocol which are designed to make TCP work over an unreliable link.

I wonder if that's necessary. Tunnelling through TCP is inherently
reliable no matter what you send, so TCP-nested-in-TCP is just overkill.
Cheating the OS doesn't help. Maybe some LD_PRELOAD library that turns
stream sockets into dgram sockets for connections that use the tunnel is
sufficient. However, this doesn't actually apply to openvpn because
openvpn does TCP-over-UDP.

-- 
Matthias Andree

[Openvpn-devel] Release candidate for 1.4.0

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

We're on the final stretch for 1.4.0, so if possible, please give this release
a spin.

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

I plan to release 1.4.0 shortly if there are no problems.

James

Re: [Openvpn-devel] TCP-over-TCP (was: Multi-channel VPN)

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

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

> On Sat, 19 Apr 2003, Aaron Sethman wrote:
> 
> > I'm not necessarly sure it belongs in OpenVPN, but then again, I can see
> > the advantages to automatically failover to other links.  Perhaps
> > abstracting things out in the code a bit that it would be possible to have
> > multiple methods of sending data out to the world, perhaps even non-ip
> > methods.  Or even implementing something as tunnelling over TCP(I do know
> > the reasons why you don't want to do this, but in some cases you don't
> > have a choice, and are willing to eat the performance loss).
> 
> TCP-over-TCP tunnelling isn't necessarily a performance loss, but it
> also exhibits excessive retransmit behaviour -- which isn't too bad if
> you have congested links and need to take a bigger share than the others
> ;-) I've always found vpnd (tcp-over-tcp) to be more stable than vtund
> (over udp in my configurations) across congested links, but I haven't
> compared vpnd to openvpn. (And I've found vtund to be fragile, a single
> ping -f into a tunnel usually let the tunnel collapse on Linux. OpenVPN
> is solid in these circumstances.)

I wonder if one could build a better tcp-over-tcp by doing some intelligent
packet filtering on the higher level tcp connection, such as filtering out
retransmits and fudging return ACKs -- essentially removing those elements of
the TCP protocol which are designed to make TCP work over an unreliable link.

James

[Openvpn-devel] TCP-over-TCP (was: Multi-channel VPN)

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

On Sat, 19 Apr 2003, Aaron Sethman wrote:

> I'm not necessarly sure it belongs in OpenVPN, but then again, I can see
> the advantages to automatically failover to other links.  Perhaps
> abstracting things out in the code a bit that it would be possible to have
> multiple methods of sending data out to the world, perhaps even non-ip
> methods.  Or even implementing something as tunnelling over TCP(I do know
> the reasons why you don't want to do this, but in some cases you don't
> have a choice, and are willing to eat the performance loss).

TCP-over-TCP tunnelling isn't necessarily a performance loss, but it
also exhibits excessive retransmit behaviour -- which isn't too bad if
you have congested links and need to take a bigger share than the others
;-) I've always found vpnd (tcp-over-tcp) to be more stable than vtund
(over udp in my configurations) across congested links, but I haven't
compared vpnd to openvpn. (And I've found vtund to be fragile, a single
ping -f into a tunnel usually let the tunnel collapse on Linux. OpenVPN
is solid in these circumstances.)

-- 
Matthias Andree

Re: [Openvpn-devel] Fwd: RE: Multi-channel VPN

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

On Fri, Apr 18, 2003 at 05:53:07AM -0000, James Yonan wrote:
> I'm forwarding this discussion of an interesting feature request.  Namely,
> could (and should) OpenVPN have a channel bonding capability, where more than
> one UDP connection over different paths is used to connect two peers, and
> OpenVPN does channel bonding, load balancing, and failover among the
> connections?  Or does this function not belong in OpenVPN since it is
> functionally distinct from the role of network security and tunneling and
> could be implemented as a module or driver apart from OpenVPN?
> 


Hi all,

IMHO this feature would be out of OpenVPN's scope, just as QoS or
firewalling are. It'd add (talking from my ignorant-and-no-developer
point of view) lots of complexity, and we know complexity and bugs
travel in the same ship :)
This can be achieved in both Linux and FreeBSD, it's not easy but it's
possible.
Let each tool do its job, and only that.



-- 
Alberto Gonzalez Iniesta       | They that give up essential liberty
agi@(agi.as|debian.org)        | 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

Re: [Openvpn-devel] Fwd: RE: Multi-channel VPN

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

On Fri, 18 Apr 2003, James Yonan wrote:

> I'm forwarding this discussion of an interesting feature request.  Namely,
> could (and should) OpenVPN have a channel bonding capability, where more than
> one UDP connection over different paths is used to connect two peers, and
> OpenVPN does channel bonding, load balancing, and failover among the
> connections?  Or does this function not belong in OpenVPN since it is
> functionally distinct from the role of network security and tunneling and
> could be implemented as a module or driver apart from OpenVPN?

I'm not necessarly sure it belongs in OpenVPN, but then again, I can see
the advantages to automatically failover to other links.  Perhaps
abstracting things out in the code a bit that it would be possible to have
multiple methods of sending data out to the world, perhaps even non-ip
methods.  Or even implementing something as tunnelling over TCP(I do know
the reasons why you don't want to do this, but in some cases you don't
have a choice, and are willing to eat the performance loss).

Regards,

Aaron

Re: [Openvpn-devel] Fwd: RE: Multi-channel VPN

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

On Fri, 18 Apr 2003, James Yonan wrote:

> I'm forwarding this discussion of an interesting feature request.  Namely,
> could (and should) OpenVPN have a channel bonding capability, where more than
> one UDP connection over different paths is used to connect two peers, and
> OpenVPN does channel bonding, load balancing, and failover among the
> connections?  Or does this function not belong in OpenVPN since it is
> functionally distinct from the role of network security and tunneling and
> could be implemented as a module or driver apart from OpenVPN?

I wouldn't add multilink capabilities into OpenVPN itself unless it will
see a major improvement in security compared to bonding several OpenVPN
connections, and I'd rather see it separately. I could imagine OpenVPN
using a virtual device that has this multilink capability with failure
resilience, or I could imagine such multilink software operating several
OpenVPN tunnels. Either would likely be adequate. It gets simple if this
(de)multiplexer looked like a regular network interface to other
applications.

Re: [Openvpn-devel] Re: New beta available + progress update

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

On Thu, 17 Apr 2003, James Yonan wrote:

> The nice part about a radio link is that it is probably under your control,
> meaning that you can ensure that ICMPs get properly passed.  This allows path
> MTU discovery to work and therefore solves a lot of the harder problems.

Well,  at least for the bits that crossed a Linux 2.2 masquerade
router...

> In this case, the FRAGMENT_ENABLE code would take the Path MTU hint from the
> OS rather than trying to figure it out empirically by trial-and-error.  The
> current FRAGMENT_ENABLE code knows how to get the PMTU from Linux, but still
> needs code for other OSes.

For FreeBSD, apparently the routing table has to be queried for the MTU
-- unless someone comes up with better information. NetBSD has an
IP_RETURNMTU ioctl, I'm unsure about other systems. Seems to be
non-standard :-/

[Openvpn-devel] Fwd: RE: Multi-channel VPN

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

I'm forwarding this discussion of an interesting feature request.  Namely,
could (and should) OpenVPN have a channel bonding capability, where more than
one UDP connection over different paths is used to connect two peers, and
OpenVPN does channel bonding, load balancing, and failover among the
connections?  Or does this function not belong in OpenVPN since it is
functionally distinct from the role of network security and tunneling and
could be implemented as a module or driver apart from OpenVPN?

James

Forwarded From: "R. Latimer" <la...@or...>

> Hi,
> 
> Certainly, I don't mind if you wish to post to the list.
> 
> My reason for suggesting this be done in OpenVPN is primarily due to the
> ability to support multiple platforms (my e-mail should say
> platform-independant, not hardware-independant) without relying on
> additional software being installed at both ends, or OS-specific solutions.
> 
> Thanks,
> 
> - R. Latimer
> 
> -----Original Message-----
> From: James Yonan [mailto:ji...@yo...]
> Sent: Thursday, 17 April 2003 22:40
> To: R. Latimer
> Subject: Re: Multi-channel VPN
> 
> 
> Mr. Latimer,
> 
> It's an interesting idea, though I'm not sure that OpenVPN is the right
> place
> to put the channel bonding code.
> 
> Since OpenVPN leaves all routing control to the OS, it would seem to make
> more
> sense to implement the channel bonding at the router level, since channel
> bonding is functionally distinct from the role of a VPN.
> 
> Having said that, it would certainly be possible to implement this in
> OpenVPN
> though it would add the complexity of load balancing, failover, to OpenVPN.
> It would also introduce issues of flow control on the UDP channel(s) that
> OpenVPN hasn't had to deal with before.
> 
> If you don't mind, I would like to post this thread to the list so that
> others
> can comment.
> 
> James
> 
> "R. Latimer" <la...@or...> said:
> 
> > Hi James,
> >
> > Sorry to e-mail you directly rather than using the mailing list. I'm not
> > presently subscribed to the development list, but have a feature
> suggestion
> > you may wish to give some consideration (Post-1.4, perhaps much further
> down
> > the development path).
> >
> > I was wondering if it would be possible to allow OpenVPN to use multiple
> > paths to connect two networks? E.g. use two Internet connections here to
> > connect to a single remote VPN. I see no reason both ends couldn't use
> > multiple paths, but a simple one to many relationship alone would be
> handy.
> >
> > The reason for this is, Internet access in NZ is very expensive. I have a
> > 128k connection, and am looking at getting 128k a wireless connection as
> > well for use with a laptop. The VPN terminates in the US, where bandwidth
> is
> > plentiful, and supplying the VPN with 256k wouldn't be a problem.
> >
> > I would like to be able to join the two channels when the laptop is
> > connected to the LAN, and when unavailable, have all traffic automatically
> > sent through a single interface.
> >
> > Each interface would be with a different ISP, so traditional routing
> > protocols to one IP address wouldn't work in this case. In fact, the local
> > telephone company specifically disallows static IPs on the 128k
> > connections - they are only permitted on the expensive (pay per MB)
> > high-speed ADSL connections.
> >
> > I believe this would be possible using two instances of OpenVPN, and
> > NetGraph on FreeBSD, but unfortunately the remote end uses Linux. If
> > possible to do this in OpenVPN, it would provide a hardware-independant
> way
> > to link multiple channels. Currently NetGraph contains no code for
> > intelligently determining the path, it simply alternates between ports. It
> > would be great if OpenVPN could additionally favour one link over another
> > based on actual performance.
> >
> > I've been using OpenVPN since the FreeBSD port became available, and it
> > works very well. Thanks for such a great tool, and I hope you'll give my
> > suggestion some thought.
> >
> > Thanks,
> >
> > - R. Latimer
> >
> >
> 
> 
> 
> --
> 
> 
> 
> 
> 
> 



-- 

Re: [Openvpn-devel] Re: New beta available + progress update

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

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

> On Thu, 17 Apr 2003, James Yonan wrote:
> 
> > A better alternative (orginally suggested by you) is to avoid fragmenting in
> > the first place by bouncing back ICMP_DEST_UNREACH/ICMP_FRAG_NEEDED to the TUN
> > device.  This won't work on TAP devices because the ethernet MTU is fixed
at 1500.
> > 
> > Unfortunately (or fortunately depending on your perspective), my network
> > connections are not broken enough to benefit from the FRAGMENT_ENABLE stuff
> > just yet, so I can't really test it properly.
> 
> Well, the peer that was behind an overloaded 1 Mbps 2 km radio link has
> now moved and has become a V.34+ modem link (33k6 bps), with
> corresponding effects on the MTU. I wonder if running a local pppd pair
> with properly MTU can be used to figure if fragmentation works, but
> there's yet have to be someone who drops individual fragments (unless
> gremlin mode does it already) for real testing.

Gremlin tests that the dynamic MTU/bandwidth algorithm can survive, but
doesn't really help when it comes to tuning the algorithm for optimality in
real-world conditions.

The nice part about a radio link is that it is probably under your control,
meaning that you can ensure that ICMPs get properly passed.  This allows path
MTU discovery to work and therefore solves a lot of the harder problems.

In this case, the FRAGMENT_ENABLE code would take the Path MTU hint from the
OS rather than trying to figure it out empirically by trial-and-error.  The
current FRAGMENT_ENABLE code knows how to get the PMTU from Linux, but still
needs code for other OSes.

> OTOH, fragmenting links also have a natural impact on the packet loss:
> if you assume 10% packet loss on the transport layer (that transports
> the fragment), and you fragment a TAP packet of 1500+ bytes into 3 of
> approx 500 bytes (say, MTU=552), the effective packet loss for TCP or
> something is much higher: it takes losing a single fragment to
> retransmit, so the effective packet loss will come out as 27% (not
> taking burst loss into account).

Good point.
 
> I also have another patch to fix prototype warnings:

Merged.

James

> 
> diff -u thread.h thread.h
> --- thread.h	17 Apr 2003 10:51:21 -0000
> +++ thread.h	17 Apr 2003 11:05:38 -0000
> @@ -118,17 +118,17 @@
>  #define MUTEX_UNLOCK(lock)
>  
>  static inline void
> -thread_init()
> +thread_init(void)
>  {
>  }
>  
>  static inline void
> -thread_cleanup()
> +thread_cleanup(void)
>  {
>  }
>  
>  static inline int
> -thread_number()
> +thread_number(void)
>  {
>    return 0;
>  }
> @@ -139,7 +139,7 @@
>  }
>  
>  static inline void
> -work_thread_join ()
> +work_thread_join (void)
>  {
>  }
>  
> 
> -- 
> Matthias Andree
> 
> 
> -------------------------------------------------------
> 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] Re: New beta available + progress update

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

On Thu, 17 Apr 2003, James Yonan wrote:

> A better alternative (orginally suggested by you) is to avoid fragmenting in
> the first place by bouncing back ICMP_DEST_UNREACH/ICMP_FRAG_NEEDED to the TUN
> device.  This won't work on TAP devices because the ethernet MTU is fixed at 1500.
> 
> Unfortunately (or fortunately depending on your perspective), my network
> connections are not broken enough to benefit from the FRAGMENT_ENABLE stuff
> just yet, so I can't really test it properly.

Well, the peer that was behind an overloaded 1 Mbps 2 km radio link has
now moved and has become a V.34+ modem link (33k6 bps), with
corresponding effects on the MTU. I wonder if running a local pppd pair
with properly MTU can be used to figure if fragmentation works, but
there's yet have to be someone who drops individual fragments (unless
gremlin mode does it already) for real testing.

OTOH, fragmenting links also have a natural impact on the packet loss:
if you assume 10% packet loss on the transport layer (that transports
the fragment), and you fragment a TAP packet of 1500+ bytes into 3 of
approx 500 bytes (say, MTU=552), the effective packet loss for TCP or
something is much higher: it takes losing a single fragment to
retransmit, so the effective packet loss will come out as 27% (not
taking burst loss into account).

I also have another patch to fix prototype warnings:

diff -u thread.h thread.h
--- thread.h	17 Apr 2003 10:51:21 -0000
+++ thread.h	17 Apr 2003 11:05:38 -0000
@@ -118,17 +118,17 @@
 #define MUTEX_UNLOCK(lock)
 
 static inline void
-thread_init()
+thread_init(void)
 {
 }
 
 static inline void
-thread_cleanup()
+thread_cleanup(void)
 {
 }
 
 static inline int
-thread_number()
+thread_number(void)
 {
   return 0;
 }
@@ -139,7 +139,7 @@
 }
 
 static inline void
-work_thread_join ()
+work_thread_join (void)
 {
 }
 

-- 
Matthias Andree

Re: [Openvpn-devel] Re: New beta available + progress update

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

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

> > http://openvpn.sourceforge.net/beta/openvpn-1.3.2.21.tar.gz (or CVS)
> 
> I have a next round of patches to fix prototypes and types to quench
> compiler warnings and get a more robust source code against changed
> environments, to aid possible later debugging; it also includes GCC
> extensions (only used when GCC is being used) that allow stricter msg()
> and buf_printf() format string vs. argument checking, to avoid printing
> bogus data when type sizes differ (think 64 bit).

Yes, very good ideas.  I will merge.

> 
> One problem remains after applying the patch:
> openvpn.c: In function `openvpn':
> openvpn.c:470: warning: cast discards qualifiers from pointer target type

That's a tricky matter, because the struct options object is const, but it
needs to be passed to a thread, and normally you need to cast something to a
void* if you want to pass it to a thread as an argument, which then causes the
constness to be lost.

> Other than that, we have unused parameter warnings (you said before
> you're not fixing them), shadow parameter warnings (variable names being
> the same as system functions, such as time or nice)

I'm not too worried about the shadow parameters.  I think it's pretty obvious
when something is being used as a variable vs. a function call.

As for the unused parms, they are mostly a result of conditional compilation
making certain variables unnecessary.  OpenVPN has a large conditional
compilation state-space, so I'm not sure that it makes sense to try to
eliminate all such warnings.

> and in particular,
> aggregate (struct) values in function calls and function returns, these
> are inefficient (as the compiler must toss the whole struct on the
> stack, which involves copy overhead), and some of them (buffer.c in
> particular) look pretty suspicious. Is there any C standard that
> guarantees that returning an auto struct works and copies the return
> value?

While I can't quote chapter and verse, being able to manipulate structures in
a value context, such as returning them from functions or passing them on the
stack, has been a part of C for ages, and for a long time compilers have tried
very hard to optimize this usage as much as possible.

For example, when a function returns an automatic structure, most compilers
will optimize this into a zero-copy operation, where the functions's
references to the automatic structure go directly into a variable allocated by
the caller for its return.

My attitude towards optimization has been to optimize the code across the
critical path only, which is essentially the event loop in openvpn.c.  Code
outside the event loop (such as the SSL negotiation) does not need to be
optimized with respect to CPU usage, because it is executed infrequently in
relation to the main event loop and OpenSSL EVP crypto code.

Most of the expensive buffer.[ch] code is only executed on startup, shutdown,
SIGHUP, or when the debug level is high.

[ patch deleted ]

James