Brian J. Murrell wrote:
On Tue, 2008-02-12 at 13:37 +0000, Andrew Suffield wrote:
It would be nice if the outage could be completely
eliminated. However, this is a problem for the kernel people - we'd
need atomic whole-configuration changes in netfilter and tc, rather
than the current rule-at-a-time system.

We do have that now with Netfilter under Shorewall-perl (one atomic update per table). But nothing for the other bits.


Indeed, but we could take quite a large step towards that goal by only
modifying an existing configuration to make the changes needed to affect
an interface change.

Anyway, unless this topic takes an interesting turn in dicussion, I will
stop beating this drum.  I've put the idea out there for consideration
but unfortunately don't really have the time to hack on it myself.  My
perl-fu is getting older and rustier as each day goes by as well.

IIRC, this thread started with the lament that your PPP device was taking so long to come up that Shorewall was getting started ahead of it. If that is the immediate problem that you are trying to solve, there is a capability in the Debian init script (init.debian.sh) that you should take advantage of in your OpenWRT package. The script defines a 'wait_interface' variable which may be set in /etc/default/shorewall and contains a space-separated list of interface names. The 'start' command waits for 90 seconds for each interface to come up (you can hack the script to change the timeout).

While the standard init script doesn't include support for 'wait-interface', the 'waitforifup' script (which does the actual waiting) is installed in /usr/share/shorewall and can be invoked from the 'init' extension script.

As to the loftier goal of dynamically reacting to interfaces going up and down like yo-yos, I've long resisted producing any Shorewall code that dynamically modifies the configuration in reaction to changes in the environment. Among the reasons are:

1) The supportability of the product suffers. A static dump of the running configuration is no longer sufficient to analyze problems. The original configuration and a detailed log of alterations are also required.

2) A whole new class of problem is created -- "My firewall worked correctly for 27 days and then it suddenly quit working -- what's wrong?". Today, we can be sure that such problems are not Shorewall-related and I like it that way.

3) The 'save' and 'restore' commands become nearly impossible to implement so that they behave correctly (they work questionably today when DYNAMIC_ZONES=Yes).

-Tom
--
Tom Eastep    \ Nothing is foolproof to a sufficiently talented fool
Shoreline,     \ http://shorewall.net
Washington USA  \ [EMAIL PROTECTED]
PGP Public Key   \ https://lists.shorewall.net/teastep.pgp.key

Attachment: signature.asc
Description: OpenPGP digital signature

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Shorewall-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/shorewall-users

Reply via email to