On May 14, 2011, at 6:20 PM, Mr Dash Four wrote: > >> tcfilters always work with packets as they appear "on the wire". So the >> packets seen on ifb1 would be the same with or without DNAT. tcrules >> always work with packets before SNAT is applied. Hence, the asymmetry. >> > Well, the good news is that SNATed traffic shaping works as advertised! > Another bit of good news is that as a result of my new traffic shaping > polic(ies) my network is absolutely flying! Upgrading to the new iproute2 > package as well as iptables (1.4.10), which I compiled all from source and > optimised for my systems, had a massive effect on the speed of it all! > > Now, for the annoying bits: > > 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. > > 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. > > 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. > > 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? ??? > > 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. > > 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? > > Finally, I attach my "bog-standard" shorewall startup script (the one which > sits in /etc/init.d) which I use on all my machines - it is much better > version than the one supplied with the shorewall rpm. Thanks. My comments regarding the init script.f a) It sources /etc/rc.d/init.d/functions which is not available in all distros. b) As near as I can tell, the script's principal functional difference involves logging. The standard init script handles logging through the STARTUP_LOG and LOG_VERBOSITY settings in /etc/shorewall/shorewall.conf. And those settings also cause logging when /sbin/shorewall is run directly. 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'. d) Your script unconditionally uses a lockfile. Not all distributions use/support them. So, while it works for you on Fedora, I'll stick with my version. -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
------------------------------------------------------------------------------ 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
