problem with conntrack utility and kernel 2.6.14
pablo at eurodev.net
Tue Nov 1 17:39:23 CET 2005
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 126.96.36.199 --orig-dst 188.8.131.52 -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.
More information about the netfilter-devel