Re: how FS is supposed to deal with problems further down the stack

I figured out how to prevent certain temporary
low-level problems from causing permanent high-level
problems:

Here's the scenario:

  ping 10.10.10.10	## confirm VPN is working initially

  dhcpcd -k eth0		## cause interface to stop working ...
  dhcpcd -n -d -R eth0	## ... but now interface works again

  ping www.google.com	## works as expected (in clear, no VPN)

  ping 10.10.10.10	## VPN traffic fails;  klips is wedged
ping: sendto: Invalid argument
                         ## pluto cannot fix it
                         ## ipsec auto cannot fix it

##!!!!  here's the crucial step:  !!!!
  ipsec tncfg --attach --virtual ipsec0 --physical eth0	## needed ...
	## ... because klips over-reacted to the temporary outage

  ping 10.10.10.10	## VPN works again

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

Let's again look at the documentation e.g. 
http://www.freeswan.org/freeswan_trees/freeswan-1.99/doc/intro.html

It says:

 >>> Road Wariors who get their addresses via DHCP may have a problem.
 >>>  FreeS/WAN can quite happily build and use a tunnel to such an
 >>> address, but when the DHCP lease expires, FreeS/WAN does not know
 >>>  that. The tunnel fails, and the only recovery method is to tear
 >>> it down and re-build it.

Hmmm.  I'd say that documentation is about as wrong as
it could be.
   1) FreeS/WAN _does_ notice the rtnetlink event that
      results from DHCP expiration.  It over-reacts thereto.
   2) Tearing down the tunnel and/or rebuilding it is
      neither necessary nor sufficient to recover from a
      temporary loss-of-lease.

IMHO it is suboptimal to need to use tncfg in the
way described above.  This is just a kludge to work
around a bug.

The root of the problem is that the whole notion of
"attaching" an ipsec device to a physical device is
a Bad Idea (tm).  Klips should not over-react if the
device goes down and comes back up with the same
properties.  But what if it comes back up with different
properties?  What if some wiseguy changes the device
properties without ever taking it down?  The ipsec
device should not depend on properties of the physical
device. Klips-ng is supposed to fix this, by means of
mast devices and all that.

In the meantime, it's probably not worth tooooo much
effort to find elegant solutions to klips-1 problems.
But (!) we need to find and document these problems,
so that they become "charter members" of the klips-ng
specifications and test suite.