From Tom's response I gather that he'd directing me to the shorewall doc'n in order that I might provide more diag info.

(In my own defence I would propose that I had been compliant with what's suggested therein: "If you receive an error message when starting or restarting the firewall and you can't determine the cause, then do the following:" ... I thought that I had somewhat identified the cause - two blacklist-optioned interfaces - but am truly more than happy to provide additional info...
=-=-=-=-=-=-=-=-


Make a note of the error message that you see.

local: 8: eth1:0.0.0.0/0: bad variable name =-=-=-=-=-=-=-=-

shorewall debug start 2> /tmp/trace

Well, the entire output is ~ 36,000 lines so I'll not include it. The context for the error message (which appears on line 7,685) is:


[...]
+ echo eth0:0.0.0.0/0
+ interface_has_option eth1 blacklist
+ local options
+ chain_base eth1
+ local c=eth1
+ true
+ echo eth1
+ return
+ eval options=$eth1_options
+ options=dhcp
+ list_search blacklist dhcp
+ local e=blacklist
+ [ 2 -gt 1 ]
+ shift
+ [ xblacklist = xdhcp ]
+ [ 1 -gt 1 ]
+ return 1
+ interface_has_option eth2 blacklist
+ local options
+ chain_base eth2
+ local c=eth2
+ true
+ echo eth2
+ return
+ eval options=$eth2_options
+ options=
+ list_search blacklist
+ local e=blacklist
+ [ 1 -gt 1 ]
+ return 1
+ interface_has_option ipsec0 blacklist
+ local options
+ chain_base ipsec0
+ local c=ipsec0
+ true
+ echo ipsec0
+ return
+ eval options=$ipsec0_options
+ options=
+ list_search blacklist
+ local e=blacklist
+ [ 1 -gt 1 ]
+ return 1
+ local hosts=ppp0:0.0.0.0/0 eth0:0.0.0.0/0
  *************** ERROR MSG HERE ***************
local: 1: eth0:0.0.0.0/0: bad variable name
  *************** ERROR MSG HERE ***************
+ find_file blacklist
+ local saveifs= directory
+ [ -n  -a -f /blacklist ]
+ saveifs=

+ IFS=:
+ [ -f /etc/shorewall/blacklist ]
+ echo /etc/shorewall/blacklist
+ IFS=
[...]

=-=-=-=-=-=-=-=-

Look at the /tmp/trace file and see if that helps you determine what the problem is.

Nothing enlightening for me.

Be sure you find the place in the log where the error message you saw is generated -- If you are using Shorewall 1.4.0 or later, you should find the message near the end of the log.

I didn't see any error msg at the end of the file, instead it appeared to occur in the place where one would expect it - in the early part of the shorewall sequence.
=-=-=-=-=-=-=-=-
=-=-=-=-=-=-=-=-


I've reviewed the support docs, etc, and am inclined to think that I've provided everything that I reasonably can in terms of reproducibility and figuring out what triggers the 'error'. To reiterate some comments I made previously:

I ultimately verified this with the 'virgin' floppy image of 2.2b5.

IOW I booted up a 'virgin' 2.2.b5 floppy, added in the blacklist options to the two interfaces, executed an 'svi shorewall restart' and observed the indicated error.


FWIW, if one or the other of the two interfaces in /etc/shorewall/interfaces is given the 'blacklist' flag then all is well, the problem only arises if both are flagged.

So I tend to think that the problem originates from > 1 interface having the option of 'blacklist'.
=-=-=-=-=-=-=-=-


If I'm omitting some obvious test method or info then please forgive me and let me know what I should be doing next. I have omitted identifying the shorewall version assuming that identifying the platform as Bering uClibc 2.2b5 would be sufficient. In case it's not:

[EMAIL PROTECTED] /root> # shorewall version
2.0.5

FWIW this appears to be a new bug in the b5 release - checking with an offsite up-and-running b4 release indicates that it doesn't complain ("bad variable name") about two interfaces having the blacklist option:


Adding Common Rules
Setting up Blacklisting...
   Blacklisting enabled on eth0
   Blacklisting enabled on eth1
Adding rules for DHCP

As well my up-and-running Bering 1.2 system doesn't mind two interfaces having the blacklist option either:


Enabling RFC1918 Filtering
Setting up Blacklisting...
   Blacklisting enabled on ppp0
   Blacklisting enabled on eth0
Setting up Kernel Route Filtering...

=-=-=-=-=-=-=-=-

Personally, I have a sneaking suspicion that it /might/ have something to do with the new 'dash' that is the shell on 2.2b5, but that's just a (long) shot, in the dark.

Thanks for LEAF!

scott; canada


Tom Eastep wrote:

freeman groups wrote:

Playing around with 2.2b5 I gave it my usual setup which includes having two interfaces flagged as blacklist-respecting (via /etc/shorewall/interfaces) even though I don't have any entries in the blacklist file.

Thus, upon shorewall's startup it gives this error message (middle line):

Adding Common Rules
Processing /etc/shorewall/initdone ...
local: 8: eth1:0.0.0.0/0: bad variable name

See http://shorewall.net/troubleshoot.htm under "shorewall start and shorewall restart Errors"

Setting up Blacklisting...
   Blacklisting enabled on eth0:0.0.0.0/0

-Tom




-------------------------------------------------------
This SF.Net email is sponsored by BEA Weblogic Workshop
FREE Java Enterprise J2EE developer tools!
Get your free copy of BEA WebLogic Workshop 8.1 today.
http://ads.osdn.com/?ad_id=4721&alloc_id=10040&op=click
------------------------------------------------------------------------
leaf-user mailing list: [EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/leaf-user
SR FAQ: http://leaf-project.org/pub/doc/docmanager/docid_1891.html

Reply via email to