> Create the file /etc/shorewall/compile with that single line. > Yep, I could do that.
>> Alternatively, I could use the shorewall init.d script as this is normally >> executed when shorewall starts/stops/reloads etc. >> > > Not recommended since that file gets replaced on each upgrade. > I am replacing this file anyway because the one you supply with the rpm is, quite frankly, crap! When the service runs - i.e. it is started and/or stopped - I get no indication whatsoever whether there was an error or whether the service started OK and I have to look at the syslog to see what has happened. That also means my gdm error log daemon won't pick it up and won't show on the status screen (of the gdm when it starts) if that service fails. I can provide you with a more "glamorous" init.d file if you like - just let me know if you need it. >>>> Right! I am not sure I understand what "miniburst" is, but if I turn TSO >>>> and GCO off (via shorewall init) would that be OK? What should I specify >>>> in the bandwidth limit of lo though (I have no idea how much the loopback >>>> can handle)? >>>> >>>> >>> No idea. >>> >>> >> Google says there is no limit - the only limit is how much the CPU/kernel >> can handle, so I might go for 0.5gbits (500mbits) and see how it goes. One question relating to that - if there is enough bandwidth available for two services with different priorities (one low, one high) do they get served at the same time or is the priority value honoured and the high-priority service gets served first regardless of the fact that there is a bandwidth available to serve both services, while the low priority one waits? If they both get served when a bandwidth *is* available then I do not see any sense in applying traffic shaping on the loopback device as its bandwidth exceeds (by a factor of 5) what my CPU/kernel can handle, compared to my real network interface. >> On another note, I think I've discovered another 2 bugs (1 in tcclasses and >> 1 in tcrules) - will post details later on. >> > > Okay -- I'll hold off releasing 4.4.19.2 until I hear from you. > OK, here goes: 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. 2. tcdevices 0ff:ifb0 tcfilters 0ff:14 ... ... ERROR: Unknown INTERFACE (0ff) : /etc/shorewall/tcfilters (line 11) 3. Same concerns about the use of anything other than ifbX device classes in tcfilters as with the use of ifbX device classes in tcrules - should this be allowed by shorewall (and, more importantly, if it *is* allowed, is there a probability of a match at all)? 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). 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) 6. tcdevices 1:eth0 ... 2:ifb0 ... tclasses 1:11 .... (default class) 1:12 .... 2:21 .... (default class) 2:22 .... tcrules 1:11 ... 11 .... (N.B. this is simply a mark, not a class definition!) 2:22 ... So, shorewall passes all this despite the fact that the mark defined as "11" is never used - there, I think, should at least be a warning issued that this mark is never used. Same is valid for "unused" classes as well (i.e. when I define a class and do not use it anywhere). That is for now. I have tested all this with the "19.2" version specified by the link you provided me with (which was wrong, by the way) in one of your previous posts. Also, I was not able to test the range restriction (0-FF) in tcdevices as this was not yet implemented there. ------------------------------------------------------------------------------ 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
