Re: problem with conntrack utility and kernel 2.6.14

[Pablo Neira <pablo@eurodev.net>]

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

>> so we would need to walk through the buckets until we find a matching, 
>> not so good. Just a wild thought, how bad would be hashing the 
>> conntracks by its ID?
> 
> AFAIK quite bad since netfilter code really needs src/dst/proto hashing 
> when processing received packet.

Agreed, you can drop that idea to the trashcan :(

-- 
Pablo