Re: [Design] temporary wild-side problems cause long-term conn problems

John S. Denker writes:
 > It is particularly distasteful on a system with
 > multiple interfaces (eth0, eth1, ...).  If there
 > is a DHCP failure or other low-level problem with
 > eth0, that shouldn't force me to restart _all_ the
 > connections including the ones using eth1.

The boxes I did the above were only running DHCP + IPsec over one
interface.  If I had been given boxes running IPsec over multiple
interfaces then I'd have written some scripts that only took the
affected connections down and ensured that the eroutes/routes were
clean.  This is all possible without requiring any more cooperation
from FreeS/WAN, though cooperation might well make it simpler
(i.e. require less use of awk/sed to munge the eroute and routes to
find the ones affected).


 > 3) IMHO it is not optimal to put the solution in
 > dhcpcd-eth0.exe, because we are dealing with a wide
 > class of wild-side problems that includes but is
 > not limited to DHCP issues.  Consider for example
 > the case of inserting a PCMCIA card that uses a
 > fixed (non-DHCP) address.

A dhcpcd script isn't *the* solution to all address problems, it is
*a* solution the the DHCP problem.  In the case of PCMCIA cards then
the appropriate ifup script gets called when it goes up/down and so
hooks can be put in there to prod FreeS/WAN.


 > Additional complexities arise because some people run
 > dhclient (from ISC), some run dhcpcd, and some run
 > pump (from redhat).

That's not really that much of a problem.  I shipped dhcpcd and pump
versions of the stop/start FreeS/WAN solution.  I notice that pump
isn't on my RedHat 7.3 box so perhaps RedHat have now settled on
dhcpcd.


 > Note that dhcpcd does not even call dhcpcd-eth0.exe
 > at the time the problem begins (expiration), but
 > only at the time the problem ends (new grant).
 > That means that your ability to do good things
 > (e.g. routing traffic through a secondary interface)
 > is severely compromised.
 > 
 > This would seem to be a reason for preferring the
 > ultra-flexible dhclient over dhcpcd, which is in
 > turn preferable over pump.

I don't think that anyone would argue that getting the information
sooner rather than later is better.  However, unless the intent is
that FreeS/WAN mandates that dhclient be used then the DHCP issue is
out of FreeS/WAN's hands.  The best they could do would be to
distribute some scripts that that did something useful for each
possible DHCP client.  However, anyone can do that right now, it
doesn't have to come from FreeS/WAN.


 > 4) IMHO it would be nice for FreeS/WAN to provide
 > something more than a three-sentence mention of the
 > problem in the introductory documentation.
 > [snip]

It would be nice if FreeS/WAN did a lot of things but sometimes either
those things don't match their goals or it is simply a matter of not
having the time to do it.  IMHO the best way to make FreeS/WAN do
those things is to implement them and offer them to FreeS/WAN (or pay
someone else to do them, I'm available for contracts :-)  Even if
FreeS/WAN don't pick it up Ken might and include it in Super FreeS/WAN.