From mboxrd@z Thu Jan 1 00:00:00 1970 From: Pablo Neira Ayuso Subject: Re: [PATCH 6/10][CTNETLINK] dump counters iif connection ended or counters filled up Date: Thu, 13 Jul 2006 22:09:41 +0200 Message-ID: <44B6A885.1010903@netfilter.org> References: <44ADC3BD.3050609@netfilter.org> <44ADE7BA.4030406@trash.net> <44AE66CA.8030705@netfilter.org> <44B1DBE4.7010109@trash.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: Netfilter Development Mailinglist Return-path: To: Patrick McHardy In-Reply-To: <44B1DBE4.7010109@trash.net> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: netfilter-devel-bounces@lists.netfilter.org Errors-To: netfilter-devel-bounces@lists.netfilter.org List-Id: netfilter-devel.vger.kernel.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