> 1. When tcdevices is defined, but tcrules/tcfilters and tclasses are > empty shorewall compiles everything (without complaining!) and when it > (re)starts the whole network grinds to a screeching halt - no packets > in or out. I had a similar issue with this a while ago, which I > thought, wrongly, was because of the presence of the "hfsc" option in > my ifbX device. As it turned out, this all comes down to the absence > of a default class - everything grinds to a halt then! So, in short, > if there is *no* default classes defined in either of the interfaces > listed in tcdevices shorewall *should* produce an error as no packets > will be allowed over these interfaces. That's fixed.
> > 2. > tcdevices > 0ff:ifb0 > > tcfilters > 0ff:14 ... > ... > ERROR: Unknown INTERFACE (0ff) : /etc/shorewall/tcfilters (line 11) That's fixed. > 4. > tcdevices > 0ff:eth0 ... > ifb0 .... > > ifb0 is allocated "100" (hex) which is against the pre-defined limits > (0-ff). That, in turn, screws up the tcfilters statements completely > (they are simply ignored and everything is "routed" through the > default class defined for ifb0). That combination above causes the "number" for ifb0 (as "automatically" assigned by shorewall) to be 100 (hex) and therefore triggers the following error: "ERROR: Attempting to assign a device number > 255 : /etc/shorewall/tcdevices (line 12)". Perhaps you could try and issue an unused random number from the 0-FF range instead. > > 5. Similar to 4 above: > tcdevices > 0fe:eth0 ... > ifb0 ... > > tcfilters > ifb0:.... > > ifb0 has a major class number of "ff" defined. Whatever I put in the > tcfilters is completely ignored (everything is "routed" through the > "default" ifb0 class) That's fixed. I also noticed from the latest Changelog that you have fixed the ipset double-negative statement bug as I indicated a while ago. That particular bug is indeed cleared! However, when I have "ACCEPT:info $FW net:10.1.0.7,10.1.0.9,+[!my-host[src],!ssh-host[src]] tcp" I get "ERROR: Invalid host list (!my-host[src],!ssh-host[src]) : /etc/shorewall/rules (line 21)". This is a valid statement according to man shorewall-exclusion: "+[!set1,!set2,...!setN] produces a packet match if the packet does not match any of the sets. In other words, it is like NOT match set1 AND NOT match set2 ... AND NOT match setN.", so this statement should be allowed. ------------------------------------------------------------------------------ WhatsUp Gold - Download Free Network Management Software The most intuitive, comprehensive, and cost-effective network management toolset available today. Delivers lowest initial acquisition cost and overall TCO of any competing solution. http://p.sf.net/sfu/whatsupgold-sd _______________________________________________ Shorewall-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/shorewall-users
