Re: Possible race condition in conntracking

[Tobias Klausmann <klausman@schwarzvogel.de>]

Hi! 

On Tue, 27 Jan 2009, Patrick McHardy wrote:
> Tobias Klausmann wrote:
>> So, as far as rule-matching is concerned, the two packets are
>> handled identically. Whatever happens after this:
>> Jan 27 11:00:39 fw2 kernel: TRACE: nat:POSTROUTING:policy:3 IN=
>> OUT=eth2.188 SRC=194.97.7.116 DST=194.97.3.83 LEN=66 TOS=0x00
>> PREC=0x00 TTL=63 ID=46964 DF PROTO=UDP SPT=53452 DPT=53 LEN=46 is making 
>> this very packet go away. The policy of nat/PR is
>> ACCEPT.
>
> This just means it passed through the last table/chain. The
> only one following is conntrack confirmation.
>
> Damn it :) I just noticed, we do indeed drop packets from
> duplicate new connections in conntrack confirmation.

So the question remains what to do instead and how to do it. That
probably is deep Netfilter mojo, so I could only speculate wildly.

> You should see the insert_failed conntrack counter show this
> (/proc/net/stat/nf_conntrack).

We do, as I said in my first mail. Near as I can tell,
nf_conntrack_confirm() is the only function that ever increases
that counter, so it's definitely dropped there. As to how one
could handle it differently, I have to defer to people with more
Netfilter expertise. No point in "fixing" this by breaking other
stuff.

Regards,
Tobias

-- 
printk("Cool stuff's happening!\n")
        linux-2.4.3/fs/jffs/intrep.c