Date: Mon, 21 Nov 2011 16:01:23 +0400 From: Gleb Smirnoff <glebius@FreeBSD.org> To: Alexander Wittig <wittigal@msu.edu> Cc: freebsd-net@FreeBSD.org Subject: Re: FreeBSD 9 and ARP multicast source address error messages Message-ID: <20111121120123.GC81136@FreeBSD.org> In-Reply-To: <6A964045-2ADF-42EC-8AC4-00179FDBE4D9@msu.edu> References: <96A5211A-398B-4773-8C6A-2D772D241CF0@msu.edu> <20111110065135.GS71907@FreeBSD.org> <6A964045-2ADF-42EC-8AC4-00179FDBE4D9@msu.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
Alexander, On Thu, Nov 10, 2011 at 12:42:15PM -0500, Alexander Wittig wrote: A> > Can you try attached patch. It reduces severity level of all ARP A> > messages, that can be triggered by packet on network, with expection to A> > "using my IP address". A> > A> > With default syslog.conf, now ARP errors won't get to console. A> > A> > Also, the multicast message lacked "\n" newline character, that's why, A> > I suppose, syslogd failed to coalesce a number of messages into a single A> > entry "last message repeated X times". A> A> Thank you very much for the patch, and for making this particular message a bit more helpful by including the MAC address. A> I tried it and indeed it stops the messages from going to the console. But the default syslog.conf still logs each one in /var/log/messages and they also show up in dmsg output. These happen quite frequently, so even on a not so busy network they will drown out almost everything else going on in dmsg or /var/log/messages. Unfortunately, having two (or more) different machines use these will prevent syslogd from combining messages into "last message repeated X times": A> A> /var/log/messages: A> [...] A> Nov 10 12:23:44 bt kernel: in_arp: 03:bf:23:09:44:e4 is multicast A> Nov 10 12:23:44 bt kernel: in_arp: 03:bf:23:09:44:87 is multicast A> Nov 10 12:25:45 bt kernel: in_arp: 03:bf:23:09:44:e4 is multicast A> Nov 10 12:25:45 bt kernel: in_arp: 03:bf:23:09:44:87 is multicast A> [...] Okay, I will apply patch. A> I'm not an expert on networking, but is this condition of ignoring such an ARP packet really a noteworthy event? I.e. is this something that should not occur in "normal" operation according to the ARP specifications? If this is mostly for kernel developers, maybe it should only be enabled in debug kernel builds? Nope, this isn't for kernel developers only but for sysadmins. Some bad traffic is present in your network, and it should be noticed by sysadmin, that's why LOG_NOTICE severity left. However, I understand how annoying it is when you are in a bad network, you don't admin it, you can't fix it and your logging system is too chatty. I am thinking of some generic way of supperssing or ratelimiting all logged events that can be triggered by host on LAN or even by remote host. -- Totus tuus, Glebius.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20111121120123.GC81136>