Tom Eastep wrote: >> rules >> ~~~~~ >> SFLOG(-,-,-,-,ACCEPT,-,log_test_related=0) $FW local:+test >> >> produces: >> >> -A +fw2local -m set --match-set test dst -j ACCEPT >> >> Please note that this is a straight ACCEPT jump with no conditional >> switch. The rule produced should have been: >> >> -A +fw2local --condition fw2local_log_test_related -m set --match-set >> test dst -j ACCEPT >> > > I'm not even sure what the semantics of applying raw input to an inline > invocation should be. Apply it to every entry in the action body? What if an > entry in the body has raw input supplied? > Yes, if the action is inline, then apply the switch to every statement in that action - I used to get this in previous versions and now I have a "wrapper" (called WSFLOG, funnily enough), which takes the "core" chain name, has a switch condition to a separate (action) chain where the rest of the statements are executed. That way, the switch is applied only once followed to a separate (action name) jump where everything else is executed.
All this is broken now though, because, I suspect, the optimizer is optimizing away too much. If the action entry has an INLINE entry, then take it as it is (don't try and add a switch if it is too much trouble): the premise on which the INLINE statement is executed was that whoever wrote it should take full responsibility over what needs to be present in that iptables statement. ------------------------------------------------------------------------------ Get 100% visibility into Java/.NET code with AppDynamics Lite It's a free troubleshooting tool designed for production Get down to code-level detail for bottlenecks, with <2% overhead. Download for free and get started troubleshooting in minutes. http://p.sf.net/sfu/appdyn_d2d_ap2 _______________________________________________ Shorewall-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/shorewall-devel
