Re: [netfilter-core] recent in_range fix uncovered another bug?

[Karlis Peisenieks <karlis@mt.lv>]

On Thu, Sep 11, 2003 at 03:45:53PM +1000, Rusty Russell wrote:
> In message <20030910110555.GA30240@mt.lv> you write:
> > Hello!
> > 
> > I came across "lockup" in conntrack code using 2.4 kernel with bridge 
> > netfilter (which is standart in 2.6 kernel) patch applied. Lockup can be 
> > reproduced by pinging some host over bridge interface if the host is 
> > unreachable in the beginning (e.g. ARP does not resolve) and then 
> > becomes reachable (ARP resolves).
> 
> Hmm, I've had a patch around for this code for a while now.  The code
> is simply wrong.  Does this work for you?

This patch solves "lockup" problem, but what about tons of equal 
conntracks?

I do not understand all logic beyond this, but perhaps tuples should get
linked in hashtable as they are created in prerouting/localout/whenever
and confirm would only increase refcount (and set appropriate bit in
status)?  This way kfree_skb of packet without confirmation would throw
conntrack out anyway, but while packets are sitting somewhere in the
stack, all "retransmissions" would get "accounted" for correct
conntrack.

Think about SYN retransmission - connection can be long over, but the 
duplicate (created because first syn was delayed) is still sitting 
around.


Karlis