Re: iptables nfacct match question

[Michael Zintakis <michael.zintakis@googlemail.com>]

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).