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

John S. Denker writes:
> Simpler indeed. Writing such scripts from

I've leave ipsec.conf alone as much as possible and instead trap the tunnel up/down actions that FreeS/WAN pushes out via its existing script hooks.

> In fact if you adopt that approach, multiple types

That's because dhcpcd shouldn't be taking the interface up or down, its only business should be setting the IP address and default gateway on an interface that is up (ok it also does some other things like set up nameserver, ntp server ... etc.)

> There may be cleverer ways than that to get the

Scripts aren't necessarily the best or cleverest way of getting the information but it is possible to do quite a lot with them.

> > However, anyone can do that right now, it

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

There might well be a perfect solution for all possible scenarios but if a simple script covers the majority of users (who just have one IPsec interface) then doing it right can be left to those who need it done right.

> I suspect that as of yesterday hardly "anyone" even knew that it

I can't speak for anyone else nor do I have any idea as to how many people run FreeS/WAN on a box with DHCP and so need to do any scripting at all. I do know the first thing I did when asked to put FreeS/WAN on a box running DHCP was to do a couple of basic tests to see how FreeS/WAN reacted if the DHCP server didn't renew an address or if it handed out a different address. That's not something I'd have done if I'd been doing this for personal use since none of the tunnels I create are important enough to warrent the effort. However, if tunnel connectivity was important to me then I would have done the tests (how else would I know if my tunnels would stay up otherwise?) and so I assume that anyone else in a similar position would do similar tests and install some scripts.

If it is true that hardly anyone new scripts were necessary until yesterday then that either says something about the number of people running FreeS/WAN and DHCP or about how much they care about their tunnel connectivity.

> Except that the project has a strict policy against

Just because they won't or don't pick it up it doesn't mean you can't implement it and distribute it. There are large patches for FreeS/WAN that have been available for years from non-US citizens which have not been integrated into the core FreeS/WAN. That hasn't deterred the authors from continuing to maintain and distribute those patches. Having observed this, I knew last October/November when I wrote a port&protocol selector patch that the chances of it ever being accepted into FreeS/WAN ranged from slim to none (even though I'm a non-US citizen). That didn't stop me writing the patch and making it available to those users who had expressed an interest in that functionality.