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

Stephen J. Bevan wrote:

> If I had been given boxes running IPsec over multiple

OK.

> though cooperation might well make it simpler

Simpler indeed. Writing such scripts from scratch would require understand the syntax and a good bit of the semantics of ipsec.conf.

> A dhcpcd script isn't *the* solution to all address problems, it is

In fact if you adopt that approach, multiple types of hooks appear necessary, since dhcpcd does not call ifup or ifdown; apparently it does the re-routing itself. See below.

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

There may be cleverer ways than that to get the information sooner rather than later. For starters, one could imagine using rtnetlink(7). This is, after all, its intended purpose: passing routing information between kernel and userland.

Those who are allergic to writing C code could catch events sooner rather than later by using something like:

        tcpdump -nli eth0 less 1
and reacting if/when it exits due to a read error, as it will if the interface is pulled out of its socket or downed by the DHCP client daemon.

To summarize, in script-land I see a way to do it using three hooks:

• in ifup, to catch some "up" events
• in dhcpcd-eth0.exe, to catch other "up" events
• the i/o error trick, to catch "down" events although other solutions are certainly possible.

> However, anyone can do that right now, it

Maybe not quite "anyone", if you want it done right. I suspect that as of yesterday hardly "anyone" even knew that it was necessary to write such scripts. Hence my multiple pleas for more documentation of these issues.

> IMHO the best way to make FreeS/WAN do

Do you need more 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

Except that the project has a strict policy against "picking up" code written by US citizens and/or on US soil. So until the policy changes, I will continue doing as I have done since before the first FreeS/WAN release, namely making very specific suggestions on how things "could" be improved.