> It was introduced in 4.4.24 after a long discussion on this list. This > format (along with many other useful tips) is documented at > http://www.shorewall.net/configuration_file_basics.htm. > Very useful, thanks.
> I thought of that also. I suspect, however, that dealing with different > initializations in different rules might be tricky there; especially if > the rules were in different tables. My gut instinct tells me that the behaviour should be the same when a condition match with the same name is used in different rules - i.e. accept it and silently ignore the default value specified if this particular switch already exists. One example: if I create a rule containing a match called 'foo', then from the command line I set /proc/net/nf_condition/foo to 1, and then create another rule with the same switch name, the (already set) value of 'foo' remains intact. In other words: #iptables -N test #iptables -A test -m condition --condition foo #cat /proc/net/nf_condition/foo 0 #echo 1 > /proc/net/nf_condition/foo #cat /proc/net/nf_condition/foo 1 #iptables -A test -m condition --condition foo #cat /proc/net/nf_condition/foo 1 So, what I think should happen is, if I specify something like "iptables -A test -m condition --condition foo 0" and 'foo' already exists, the default value specified (0 in this case) should be silently ignored, simply because the existing condition implementation in xtables-addons does that implicitly. > It would probably be a case of 'first rule wins'. > Yep, the question is - how is shorewall currently handling this - silently ignore the default value, issue a warning or issue an error? ------------------------------------------------------------------------------ Keep yourself connected to Go Parallel: VERIFY Test and improve your parallel project with help from experts and peers. http://goparallel.sourceforge.net _______________________________________________ Shorewall-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/shorewall-devel
