problem with conntrack utility and kernel 2.6.14

[Krzysztof Oledzki]

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

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

> 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?


Best regards,

 				Krzysztof Olędzki