>> 1. >> tcfilters >> ba:25 - - all >> (ba is on ifb0) >> >> Passes compilation, but then I get this: >> >> RTNETLINK answers: Invalid argument >> We have an error talking to the kernel >> ERROR: Command "tc filter add dev ifb0 protocol ip parent be:0 prio 10 u32 >> flowid ba:25" Failed >> > > > This is not enough information to understand the problem. Please include a > tarball of /etc/shorewall (with capabilities file) so that I can reproduce > the problem. Thanks. > The class in question is created on ifbX device. The statement I included above is from tcfilters - it lists nothing specific in terms of source and destination (address or subnet) and the protocol is specified as "all". That passes check/compilation, but gives the error I indicated above when shorewall (tries to) restart/reload. If you bother to try it out my guess is that you will run into the same error.
>> 2. >> tcrules >> bb:12 $FW +[mickey-mouse,ip-port] tcp >> >> "shorewall check/compile" passes, but it fails when shorewall reload/restart >> is executed with "...Set mickey-mouse doesn't exist.". In other words, >> shorewall don't capture this error. I am not sure whether shorewall used to >> capture this before - i.e. the (non)existence of insets. >> > > Shorewall hasn't, doesn't and won't verify the existence of ipsets. Shorewall > rulesets can be compiled on one system and executed on another system running > shorewall-lite. Or, as you do, the /etc/shorewall/init file can create and > load ipsets that don't exist before the script runs. I'm sure that if the > Shorewall compiler generated a compile-time error or warning message about a > missing ipset, you would be on this list pointing out how stupid the product > is. > And you know this how exactly? I wasn't aware that you became Mystic bloody Meg all of a sudden! >> 3. >> tcfilters >> ba:12 212.... - tcp 17001 1193:2193 >> >> The above has absolutely *no* chance on gods green Earth to produce a match >> - EVER! Unless the destination IP address is also specified, that is! I >> don't know why that is, but if it is some sort of misconfiguration error >> then I should at least be given a warning. >> > > Why could no packet ever match that? Is there an RFC that prohibits sending > TCP packets to address 212.., port 17001 when the source port is in the range > 1193:2193? If so, I am not familiar with it. > Try it out and see if you are ever going to get any matches! My guess is that you won't! >> In relation to this, I have another query: I found out that this >> "requirement" for specifying a destination ip address is only valid when I >> have selected the source ip address as well. If I have a tcfilters statement >> which matches on just the port part (source and/or destination ports) then >> it all seems fine and matches are produced. I have no idea why that is! >> >> If I have to specify a destination ip address/range when I filter on the >> source address what would happen if I use a device which may change its ip >> address regularly (dhcp, tunX to name a few possibilities) - do I have to >> then reload/restart shorewall every time that happens? >> > > I'm sorry. I have no idea what you are talking about. Are you suggesting that > the generated 'tc filter add' command is malformed? Are you getting confusing > error messages? ??? > My query was in relation to the above "requirement" (if it is indeed a requirement) for specifying a destination IP address in tcfilters (for ifbX classes) in order to get a match - if that is indeed the case this would pose difficulties with devices which change their IP address frequently (say if ethX is relying on dhcp or a tunX device is used and ifbX is derived from these devices) as in order to get a match I have to change the destination address in tcfilters and restart/reload shorewall every time that happens. Is it clearer for you now or would you like me to explain it in another - different - way for you? >> 4. dmax values >> When I have dmax=375ms the resulting flow (as seen with shorewall show tc >> ethX/ifbX) is set as 75ms. In other places where I have dmax=100ms the >> actual value is 0 - it looks as though the first digit of what I specified >> in tcclasses seems to be "eaten up" by shorewall. >> > > Have you confirmed that Shorewall is doing the truncation? My reading of the > code indicates that Shorewall doesn't alter the user-supplied value. > How do I confirm that? I have specified 100ms and 375ms in my tcclasses and when I run "shorewall show tc <device>" I see 0 and 75ms respectively, so I do not know what else might have truncated these values apart from shorewall? If you know, please do elaborate! >> 5. Not a bug, just a query: When I have not specified umax shorewall/tc >> assumes some spectacularly wrong values - I had anything ranging from 2500b >> to 20000b! Why is that and how can this be corrected? >> > > Why do you believe that Shorewall is supplying this value? Have you generated > a script that includes this 'spectacularly wrong' value'? Possibly Shorewall > should raise an error if dmax isn't specified on a leaf HSFC class? > I have no idea who specifies what as I am not intimately involved with the development of shorewall to know its internal routines and peculiarities. The classes in question have no specific dmax and umax values set (though the bandwidth available to them is quite a lot I have to admit) so when I look at these with "shorewall show tc <device>" I see them as they appear on my screen. As I pointed out above, they differ very wildly. Why is that? I have always assumed that if umax is not specified the default value would be taken from the MTU value of the device this class relates to, but, evidently, this is not the case here and I wonder why that is? > a) It sources /etc/rc.d/init.d/functions which is not available in all > distros. > This is available in all Fedora versions, which is what I use here. > c) Contrary to your interpretation, 'restart' is not 'stop' followed by > 'start'. It is rather a minimally-intrusive operation that conditionally > compiles (based on the -f option) and reloads the configuration. It is much > closer to 'start' than it is to 'stop' followed by 'start'. > This is what I have amended a while ago - the script I attached is a mixture of the standard script supplied by Fedora distribution of the shorewall package, the script supplied with your own rpm and I have made a few changes myself on top of everything else. > d) Your script unconditionally uses a lockfile. Not all distributions > use/support them. > I am not and have never pretended that the script I attached could be used in "all distributions" - you asked a while ago to see my script and I attached it. If you still wish to distribute rpms with the most-common denominator shorewall script which has crappy functionality, but "runs on all distros" then I won't try to stop you, I'll just patch it up with my additions/changes (as I started doing recently) and compile the shorewall package from source disregarding the Tom Eastep-distributed rpm completely. > So, while it works for you on Fedora, I'll stick with my version. > This is your prerogative, of course. ------------------------------------------------------------------------------ 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
