>> When I got this error I had a lot going on at the time, but from what I >> remember, after the numerous combinations I tried, was that at some >> stage I had a warning from shorewall (something about not using a class >> which is a parent or something) - that actually prompted me to re-adjust >> tcclasses and change tcrules to allocate that match to the first leaf >> child instead. I can't be more specific though. >> > > There is an error generated when a class with dmax and/or umax is > specified and the class is used as a parent class. > Yeah! That was exactly it!
> I have a two-line patch ready that rejects tcfilters and tcrules that > spacify a non-leaf class. > Small correction - when I have a non-leaf class (regardless of whether this is in tcrules or tcfilters) shorewall check/compile/reload/restart silently ignores this, but then there is never a match - tc as well as iptables just bypass this as if that class isn't there. Even if I do "a:12 - - tcp" (either in tcrules or tcfilters) and use the tcp protocol, "shorewall show tc" shows me that a:12 had no matches (all counts are 0). When I select a:12 to be the default class, however, everything is again accepted by shorewall, but no network traffic is going in or out. So, yes, I think this should not be ignored by shorewall, but flagged as a warning if non-leaf class is used in either tcrules or tcfilters and issue an error if this class is specified as the default class in tcclasses. ------------------------------------------------------------------------------ Achieve unprecedented app performance and reliability What every C/C++ and Fortran developer should know. Learn how Intel has extended the reach of its next-generation tools to help boost performance applications - inlcuding clusters. http://p.sf.net/sfu/intel-dev2devmay _______________________________________________ Shorewall-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/shorewall-users
