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

John S. Denker writes:
> It is particularly distasteful on a system with

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

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

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

Do you need help?

In addition to our free technical library, Pantek provides professional IT services to companies who utilize Open Source software: Learn more about Pantek's Technical Support offerings Place an order for 24/7/365 Technical Support here Learn more about Pantek, who we are, and what we do Chat with a Live Operator Related lists.freeswan.org Links 1998-fall 1998-spring 1998-summer 1998-winter 1999-winter announce briefs bugs design freeswan-list hipsec ietf-sectest users users-admin Request more information about Pantek

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

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.