On May 4, 2011, at 3:58 PM, Mr Dash Four wrote: > >> 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.
Thanks, but I think I'll keep the current "least-common-denominator" version. I expect distributions to provide more robust versions in the RPMs that they package. I personally count on the init.d script at reboot; which I do every several months. All other times, I run /sbin/shorewall directly. > >>>>> 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. Prioritization only occurs if there is queuing on the device. So there really isn't much point unless you restrict the bandwidth to the point where there *is* queuing. > >>> 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. I've added that test. > > 2. > tcdevices > 0ff:ifb0 > > tcfilters > 0ff:14 ... > ... > ERROR: Unknown INTERFACE (0ff) : /etc/shorewall/tcfilters (line 11) I have a fix for that one. > > 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)? When I used complex TC, I used nothing but tcfilters (and I had no IFB). > > 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). I had already added a test for that case when I started enforcing the limit. Those changes aren't in the pre-release. > > 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) Think I've fixed that one too. > > 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. No. Once again; packet marks have *many* uses other than traffic shaping. If I could go back to day 1, I would name the file 'marks' rather than 'tcrules' so that people didn't automatically connect the two. > Same is valid for "unused" classes as well (i.e. when I define a class and do > not use it anywhere). I'll put that on my 'to-do' list. > > 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. Thanks. > > Also, I was not able to test the range restriction (0-FF) in tcdevices as > this was not yet implemented there. Yep. I will upload a new 4.4.19.2 preview that I believe corrects these issues. Please stand by. -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 \________________________________________________
PGP.sig
Description: This is a digitally signed message part
------------------------------------------------------------------------------ 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
