Hi Michael,
On Fri, 5 Apr 2013, Michael Zintakis wrote:
> Jozsef Kadlecsik wrote:
> > On Thu, 4 Apr 2013, Michael Zintakis wrote:
> >> Something we've discovered with regards to the nfacct match recently. If
> >> I have the following iptables statement:
> >>
> >> iptables -A INPUT -m nfacct --nfacct <nfacct_obj> -m <match2> -m <match3>
> >>
> >> The above aklways updates the "nfacct_obj" byte and packet counters,
> >> regardless of whether "match2" and "match3" actually matches. However,
> >> if we have:
> >>
> >> iptables -A INPUT -m <match2> -m nfacct --nfacct <nfacct_obj> -m <match3>
> >>
> >> then "nfacct_obj" counters are updated only when "match1" is satisfied,
> >> but if we have:
> >>
> >> iptables -A INPUT -m <match2> -m <match3> -m nfacct --nfacct <nfacct_obj>
> >>
> >> then "nfacct_obj" counters are updated when both match2 and match3 are
> >> matched (which was the initial intention).
> >>
> >> This inconsistency stems from the fact that the nfacct match in the
> >> kernel (xt_nfacct.c::nfacct_mt) always returns true, but also because of
> >> how iptables evaluates matches: it does so from left to right.
> >>
> >> Since there isn't a callback in the xt_match struct which is called
> >> after ALL matches have been satisfied (xt_match.match is called for each
> >> registered match in that statement), this causes the nfacct counters to
> >> be updated (or not) depending on the position of the nfacct match.
> >>
> >> What I have done locally is to add a separate callback (I called it
> >> "matched") which is called for all matches after all such matches in a
> >> particular statement have been satisfied, but that obviously will break
> >> lots of code depending on the old xt_match struct if such approach is
> >> adopted. My question is: is there more elegant solution to do this?
> >
> > In my opinion this is not inconsistency at all, but the intended
> > behaviour. So I don't see any reason to add such a hack to override it.
> I meant inconsistent in terms of the end result, which in the example
> above is packet/bytes counting.
>
> That result is different depending on the order of the conditions (i.e.
> matches) attached to the iptables rule. With the 'old' accounting we
> didn't have that. In other words, with the old accounting we've had:
>
> If (match1 && match2 && matchN) {
> do_packet_and_bytes_counting();
> }
>
> No matter how we arrange the order of match1, match2 and matchN, the end
> result is (or should be) the same. With the nfacct match that isn't the
> case, but that isn't nfacct match's fault, but I guess it is because of
> the way iptables is examining the matches.
Yes, exactly. And actually it supports rules like this:
iptables -A INPUT -m <match0> -m nfacct --nfacct acct0 \
-m <match1> -m nfacct --nfacct acct1 \
...
Also, this is a new accounting method, which is just not the same as the
old one.
> We would have had the consistency (in other words, getting a consistent
> result regardless of the order of the various conditions/matches) if
> nfacct was a target, not a match, but I know that would be difficult (I
> already examined that possibility) since the x_tables target does not
> provide a 'destroy' method, so there isn't a way to track the 'refcnt'
> in the nfacct kernel struct, so inventing this method is as equally as
> ugly as the hack I did with the nfacct match above, so I thought to ask
> and see whether there is a better solution.
Targets do have a destroy method.
Best regards,
Jozsef
-
E-mail : kadlec@xxxxxxxxxxxxxxxxx, kadlecsik.jozsef@xxxxxxxxxxxxx
PGP key : http://www.kfki.hu/~kadlec/pgp_public_key.txt
Address : Wigner Research Centre for Physics, Hungarian Academy of Sciences
H-1525 Budapest 114, POB. 49, Hungary
--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
