Re: [PATCH 6/10][CTNETLINK] dump counters iif connection ended or counters filled up

[Pablo Neira Ayuso <pablo@netfilter.org>]

Patrick McHardy wrote:
> Pablo Neira Ayuso wrote:
> 
>>Patrick McHardy wrote:
>>
>>
>>>Pablo Neira Ayuso wrote:
>>>
>>>
>>>>I think that this patch should also reset counters upon fill up event,
>>>>comments?
>>>
>>>
>>>Not sure, do you know any users of the counters besides conntrackd?
>>
>>
>>I don't know any ctnetlink user of the counters. Thinking it well this
>>"counters fill up" issue is tricky. Since netlink is unreliable, what if
>>the fill up event gets lost? we could reset counters and nobody would
>>apparently notice. I think that we need an overflow bit in the conntrack
>>that must be set whenever and overflow happens and unset such bit once
>>the overflow event has been caught.
> 
> If a message is lost userspace simply _must_ resync if it wants
> reliability. If we reset the counter its impossible for userspace
> to reconstruct the value at which it overflowed, so I don't think
> we should do that. But you raise a good point, how should userspace
> react to lost DESTROY messages that contain new information (like
> counter values)? I don't see how it could reliable handle that case.

I can't see any either at the moment :(

BTW, something related to the overflow issue: what I'm currently doing 
in conntrackd is the following thing, if an overflow is detected, the 
size of socket buffer is duplicated via RCVBUFFFORCE and then it 
resyncs. I'll add a clause to limit the socket buffer maximum growth. 
Can you see any problem with this?

-- 
The dawn of the fourth age of Linux firewalling is coming; a time of 
great struggle and heroic deeds -- J.Kadlecsik got inspired by J.Morris