From mboxrd@z Thu Jan 1 00:00:00 1970 From: Patrick McHardy Subject: Re: Every other char with LOG netfilter output (bug?) Date: Tue, 28 Oct 2008 19:13:33 +0100 Message-ID: <4907564D.5090103@trash.net> References: <49074E81.6010207@trash.net> <49075276.2686460a.0b00.ffff9f09@mx.google.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: QUOTED-PRINTABLE Cc: netfilter-devel@vger.kernel.org To: =?ISO-8859-15?Q?D=E2niel_Fraga?= Return-path: Received: from stinky.trash.net ([213.144.137.162]:41742 "EHLO stinky.trash.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751865AbYJ1SNg (ORCPT ); Tue, 28 Oct 2008 14:13:36 -0400 In-Reply-To: <49075276.2686460a.0b00.ffff9f09@mx.google.com> Sender: netfilter-devel-owner@vger.kernel.org List-ID: D=E2niel Fraga wrote: > On Tue, 28 Oct 2008 18:40:17 +0100 > Patrick McHardy wrote: >=20 >> Seems likely. Is that an SMP machine? Its possible that the ringbuff= er >> simply overflows before the logging daemon gets a chance to capture = it, >> but that should only cause truncated lines. >=20 > Yes, SMP (Athlon64 X2 and I noticed it on a Xeon 3040 too). >=20 >> What do your logging rules that might be responsible for this look l= ike? >=20 > My rules are pretty simple: >=20 > # Generated by iptables-save v1.4.2 on Tue Oct 28 15:49:09 2008 > *filter > :INPUT DROP [0:0] > :FORWARD DROP [0:0] > :OUTPUT ACCEPT [454613:1227743602] > :FLDR - [0:0] > :LDR - [0:0] > ... > -A FLDR -j LOG --log-prefix "DROP FORWARD: " --log-level 6=20 > -A FLDR -j DROP=20 > -A LDR -j LOG --log-prefix "DROP INPUT: " --log-level 6=20 > -A LDR -j DROP=20 > COMMIT > # Completed on Tue Oct 28 15:49:09 2008 >=20 > The interesting is that this behaviour started at 2.6.25 kernel vers= ion, but > I couldn't find anything that was changed between .24 and .25 to caus= e this. Very strange. I have no idea why the log output is corrupted like this, but some things you could try: - use serial console, which should at least avoid any corruption triggered by ringbuffer overflows. It many packets are logged it will slow down your system considerably though. - use ULOG or nfnetlink_log: this allows to capture a full copy of the packet in userspace, which might be helpful for further analysis. > Is there a way I can trace the function that generates the log outpu= t syslog line? > I use Function Tracer included in 2.6.27 kernel already, but I need a= way to stop the tracing > it exactly at the point when this happens, otherwise the tracing buff= er will be replaced... I'm not familiar with ftrace, but you could manually instrument it (net/ipv4/netfilter/ipt_LOG.c). I'd try nfnetlink_log first though. -- To unsubscribe from this list: send the line "unsubscribe netfilter-dev= el" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html