On Sat, 2008-03-22 at 16:00 -0700, Tom Eastep wrote:
> 
> Most systems won't allow two default routes with the same metric.

So for only two providers, this could work.  Two standard default routes
at meterics 100 and (say) 101 and then the nexthop routing before that.
When the ppp0 interface goes down the nexthop routing goes away and so
does one of the default routes leaving you with one.

Doesn't work for >2 providers though.

And it really seems to me that having shorewall replumb the routing with
the missing interface is more like the right thing to do.

And!  That does work.  I have a small very hackish hack here that proves
to work very well:

--- /usr/share/shorewall-perl/Shorewall/Providers.pm.dist       2008-03-22 
15:01:20.000000000 -0400
+++ /usr/share/shorewall-perl/Shorewall/Providers.pm    2008-03-22 
15:17:30.000000000 -0400
@@ -197,9 +197,14 @@
        fatal_error 'A non-empty COPY column requires that a routing table be 
specified in the DUPLICATE column' if $copy ne '-';
     }
 
-    if ( $gateway eq 'detect' ) {
+    if ( $gateway eq 'detect' || $gateway =~ /^\$\(.+\)/ ) {
        my $variable = get_interface_address $interface;
-       emit  ( "gateway=\$(detect_gateway $interface)\n",
+       my $gw_detect = "detect_gateway $interface";
+        if ( $gateway =~ /^\$\((.+)\)/ ) {
+            $gw_detect = $1;
+            $gw_detect =~ s/_/ /g;
+        }
+       emit  ( "gateway=\$($gw_detect)\n",
                'if [ -n "$gateway" ]; then',
                "    run_ip route replace $variable dev $interface table 
$number",
                "    run_ip route add default via \$gateway dev $interface 
table $number",

and providers configuration of:

CGCO    1       64      main            eth0.1          
$(uci_get_/var/state/network.wan0.gateway) track,balance,optional       
br-lan,tun0
IGS     2       128     main            ppp0            detect          
track,balance,optional  br-lan,tun0

The "s/_/ /g" ugliness has to do with what's allowed and what's not in a
configuration file.

Indeed, I could replace the $(uci ...) shenanigans with a params
variable, but as I've mentioned before, it appears that params are
evaluated at compile time and not policy rest{art,ore} time so the
ability to shorewall-lite rest{art,ore} will actually fail if the
gateway of the interface changes after the firewall script is compiled.

So, now that I think about it, this usability issue has morphed from
that of the default gateways getting lost when an interface goes down
(because that is solvable but for ...) into one of not being able to
define parameters that are evaluated at policy installation time.

There seems to be some indication that the "init" script is a kind of
params that is run exclusively on the shorewall-lite system but having
looked at the firewall script and how the whole gateway detection and
addition code works, I cannot see how setting a variable in the init
file is going to propagate into that code in the firewall script on the
-lite machine.  Am I wrong?

b.

Attachment: signature.asc
Description: This is a digitally signed message part

-------------------------------------------------------------------------
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