Re: [RFC] [PATCH] ctnetlink updates

[Pablo Neira <pablo@eurodev.net>]

Patrick McHardy wrote:
> Pablo Neira wrote:
>> There are some issues I'd like to discuss:
>>
>> o Declaring ID as unsigned int. I think it's just fine.
>>
>>     - A conntrack must be identified with one of the tuples (original 
>> or reply) and its id. That way it can be uniquely identified.
> 
> Good idea, although I'm not completely convinced.

Now I've changed my mind :).

I think that we can identify a connection with both the original and 
reply tuple. Since a connection is represented by means of a conntrack, 
if a user kills a conntrack via ctnetlink, he's willing to kill the 
connection that the conntrack represents, and not to such conntrack itself.

There aren't two conntracks with the same original and reply tuples. I 
can't see anymore why we need such id.

>>     - Using u_int64_t just reduces the possibility of the wrapping 
>> around but such possible problem is still there.
> 
> 
> The time until a wrap is many many years even if you assume very
> high connection rate and many CPUs, so its not a practical problem.
> The difference to your solution is that you can tell for sure that
> clashes won't occur until a date under known conditions. I dislike
> the idea of an unreliable API that has no possibilty of even noticing
> and/or handling the error, so I'm not sure about this.

Yes, you are right this is not a practical problem. Well, if we keep 
using the id, we could detect a wrap and adjust all sequence numbers. Of 
course that this is a expensive operation but it would happen once in a 
blue moon :).

--
Pablo