Hello Jozsef,
Jozsef Kadlecsik wrote:
> 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 \
> ...
Hm, never thought of that, but I guess one learns something new every day. Thanks Jozsef!
> Also, this is a new accounting method, which is just not the same as the
> old one.
Yes, I know, I wasn't disputing that - it is just that I am used to the 'old' accounting and when you've been using it for years it is not so easy to 'detach' yourself from that.
>> 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.
Haha, you are far too quick for me!
I just found that out - I don't know how I did not see it when I first looked at it. I guess if I 'convert' nfacct to a target I could get that 'consistency', but I appreciate the new example you gave above, which I have to admit is very useful indeed (one can hit two or more birds with one stone so to speak).
--
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
