Re: problem with conntrack utility and kernel 2.6.14

[Pablo Neira <pablo@eurodev.net>]

Krzysztof Oledzki wrote:
> On Tue, 1 Nov 2005, Pablo Neira wrote:
> 
>> Krzysztof Oledzki wrote:
>>
>>>> You can't kill conntracks *just* by the ID. The connection tracking 
>>>> table currently uses the tuple information (source, destination, 
>>>> protocol information) to place the conntrack in hashes, same thing 
>>>> to perform lookups.
>>>
>>> So, why do we need this conntrack ID? Only for userspace applications?
>>
>> Because of two reasons:
>>
>> a) We have to provide a way to uniquely identify a conntrack. On slow 
>> devices, it could happen that a connection with the same src/dst/proto 
>> could be re-created in a very short period of time. So the user can be 
>> sure that he's killing that conntrack, and not a similar that 
>> represents a re-opened connection.
> 
> So one can pass this id as an additional information? OK. :)

That is :)

> BTW: I think conntrack-tool should inform that conntrack killing fails 
> because kernel isn't able to find a matching conntrack.

That is what it currently does, are you observing a different behaviour?

# conntrack -D --orig-src 1.1.1.1 --orig-dst 2.2.2.2 -p tcp 
--orig-port-src 2005 --orig-port-dst 21
NFNETLINK answers: No such file or directory
Operation failed: such conntrack doesn't exist

>> b) Netlink dumping is not atomic, for that reason we need a way to 
>> know from which point we stopped dumping the connection tracking 
>> table. Keeping a pointer to the lastest conntrack processed won't work 
>> because of the timers. It could happen that a conntrack expires at the 
>> time that  the process of dumping continues. So the idea is using the 
>> ID to establish such breakpoint, and continue from the lastest 
>> conntrack ID processed if it's still present, otherwise we'll process 
>> the next conntrack ID higher than the lastest processed.
> 
> But to do this you need to travel the structure from the beginning and 
> so dumping may require operations like O(n) anyway?

No, we store the last bucket processed in a temporary control buffer, so 
we can continue from this bucket and then look for the last conntrack 
processed in the list associated to this bucket.

-- 
Pablo