Shorewall users - May 2009 - multi-isp, dhcp provider and gateway type detect

I think we discussed this in the past and I floated a hack at the time,
but I don''t recall any real resolution.  I want to see if time has
solved my problem or if it still exists.

My scenario is that I have two ISPs, one of which uses DHCP.  Because I
have two ISPs, history has shown that allowing the provisioning script
for the interface to plumb a default route is troublesome and it''s
better left to shorewall to handle.

The problem with this is that because the DHCP provided interface is
dynamic, I should use "detect" in the gateway column of the providers
file.  However, gateway detect, for DHCP interfaces relies on the
interface provisioning script plumbing the default interface, which as
I''ve mentioned, causes more problems than it solves, with shorewall and
multi-isp.

The hack I had proposed at the time was to allow the specification of a
scriptlet in the gateway column of the providers file to alternately
tell shorewall how to get the default interface.

Any suggestions?  I''d even happy to put the scriplet somewhere else
(i.e. in params), setting a variable and having the variable
de-referenced in the providers file if that''s possible but it
doesn''t
seem so.

Would a patch to expanding the methods used to "detect" a gateway be
welcomed?

b.



------------------------------------------------------------------------------
Crystal Reports - New Free Runtime and 30 Day Trial
Check out the new simplified licensing option that enables 
unlimited royalty-free distribution of the report engine 
for externally facing server and web deployment. 
http://p.sf.net/sfu/businessobjects

Brian J. Murrell wrote:
> I think we discussed this in the past and I floated a hack at the time,
> but I don''t recall any real resolution.  I want to see if time has
> solved my problem or if it still exists.
> 
> My scenario is that I have two ISPs, one of which uses DHCP.  Because I
> have two ISPs, history has shown that allowing the provisioning script
> for the interface to plumb a default route is troublesome and it''s
> better left to shorewall to handle.
> 
> The problem with this is that because the DHCP provided interface is
> dynamic, I should use "detect" in the gateway column of the
providers
> file.  However, gateway detect, for DHCP interfaces relies on the
> interface provisioning script plumbing the default interface, which as
> I''ve mentioned, causes more problems than it solves, with
shorewall and
> multi-isp.
> 
> The hack I had proposed at the time was to allow the specification of a
> scriptlet in the gateway column of the providers file to alternately
> tell shorewall how to get the default interface.
> 
> Any suggestions?  I''d even happy to put the scriplet somewhere
else
> (i.e. in params), setting a variable and having the variable
> de-referenced in the providers file if that''s possible but it
doesn''t
> seem so.
> 
> Would a patch to expanding the methods used to "detect" a gateway
be
> welcomed?
Check out the detect_dynamic_gateway() function in the 4.2.9 version of
/usr/share/shorewall-perl/prog. If your DHCP client is placing its lease
file in either of the places that the function is looking then your are
all set. If not, then you''ll neeed to modify the file slightly.

In 4.4, there is also a findgw user exit (extension script) that gets
called at the top of that routine.

-Tom
-- 
Tom Eastep        \ When I die, I want to go like my Grandfather who
Shoreline,         \ died peacefully in his sleep. Not screaming like
Washington, USA     \ all of the passengers in his car
http://shorewall.net \________________________________________________



------------------------------------------------------------------------------
Crystal Reports - New Free Runtime and 30 Day Trial
Check out the new simplified licensing option that enables 
unlimited royalty-free distribution of the report engine 
for externally facing server and web deployment. 
http://p.sf.net/sfu/businessobjects

On Mon, 2009-05-18 at 14:28 -0700, Tom Eastep wrote:
> Check out the detect_dynamic_gateway() function in the 4.2.9 version of
> /usr/share/shorewall-perl/prog.
Indeed, I actually saw that earlier, not long after posting.  It is in
prog.header in 4.2.8.  It is exactly the sort of "extending" that I
had
in mind.  I almost have a working patch but for one thing:

--- /usr/share/shorewall-perl/prog.header.dist	2009-05-18 16:25:52.000000000
-0400
+++ /usr/share/shorewall-perl/prog.header	2009-05-18 16:25:58.000000000 -0400
@@ -824,6 +824,10 @@
 	gateway=$(grep ''option routers''
/var/lib/dhcp/dhclient-${1}.lease | tail -n 1 | while read j1 j2 gateway; do
echo $gateway; return 0; done)
     fi
 
+    if [ -z "$gateway" -a -x /sbin/uci ]; then
+        gateway=$(uci -p /var/state get network.wan0.gateway)
+    fi
+
     [ -n "$gateway" ] && echo $gateway
 }

I had to hard-code "wan0" (for the moment and to prove the concept).
The real interface is in fact eth0.1, but openwrt''s configuration has
this concept of "abstracting" the wan interfaces, whatever they may
be,
in to "pretty" aliases.  The alias exists only in the configuration
however and I can''t see a (more elegant than brute-force searching) way
for to turn the real interface specification that shorewall wants into
the "pretty" alias.  Certainly, going in the other direction is easy.
> If not, then you''ll neeed to modify the file slightly.
Right, as above.
> In 4.4, there is also a findgw user exit (extension script) that gets
> called at the top of that routine.
Interesting, although I think OpenWRT is generic enough in this respect
that it would be nice for shorewall to handle it as one of it''s
"smarter
detection" cases and not require every OpenWRT user to concoct up the
same findgw user exit.

I will update you with a final patch once I have figured how to get
from ???? to wan?.

b.



------------------------------------------------------------------------------
Crystal Reports - New Free Runtime and 30 Day Trial
Check out the new simplified licensing option that enables 
unlimited royalty-free distribution of the report engine 
for externally facing server and web deployment. 
http://p.sf.net/sfu/businessobjects

I see I never did follow-up on this as I promised.  So here it is...

On 09-05-18 07:46 PM, Brian J. Murrell wrote:
> 
> I had to hard-code "wan0" (for the moment and to prove the
concept).
> The real interface is in fact eth0.1, but openwrt''s configuration
has
> this concept of "abstracting" the wan interfaces, whatever they
may be,
> in to "pretty" aliases.  The alias exists only in the
configuration
> however and I can''t see a (more elegant than brute-force
searching) way
> for to turn the real interface specification that shorewall wants into
> the "pretty" alias.  Certainly, going in the other direction is
easy.
I ended up having to brute-force this.  I can''t imagine a gateway with
enough WAN ports to make this prohibitive though.
> I will update you with a final patch once I have figured how to get
> from ???? to wan?.
So here is my "findgw" extension script:

# ~sigh~  brute-force seems to be the only way to get a virtual
#         interface name from a physical one
x=0
while [ $x -lt 1000 ]; do
    if [ $(uci -p /var/state get network.wan$x.device) = $1 ]; then
        uci -p /var/state get network.wan$x.gateway
        break
    fi
    let x=x+1
done

Of course, the search should stop way before wan1000 when the wan$x
device is found for the interface being looked for.  The 1000 is just a
safety plug to prevent a never ending loop in some unforeseen
circumstance.  I tend to like to try to program for the unexpected.  :-)

b.



------------------------------------------------------------------------------
Enable your software for Intel(R) Active Management Technology to meet the
growing manageability and security demands of your customers. Businesses
are taking advantage of Intel(R) vPro (TM) technology - will your software 
be a part of the solution? Download the Intel(R) Manageability Checker 
today! http://p.sf.net/sfu/intel-dev2devmar