Date: Thu, 10 Nov 2011 10:51:35 +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: <20111110065135.GS71907@FreeBSD.org> In-Reply-To: <96A5211A-398B-4773-8C6A-2D772D241CF0@msu.edu> References: <96A5211A-398B-4773-8C6A-2D772D241CF0@msu.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
--uZ3hkaAS1mZxFaxD
Content-Type: text/plain; charset=koi8-r
Content-Disposition: inline
Alexander,
On Tue, Nov 08, 2011 at 05:14:45PM -0500, Alexander Wittig wrote:
A> I upgraded one of my machines from FreeBSD 8 to 9.0-RC1 (FreeBSD bt.pa.msu.edu 9.0-RC1 FreeBSD 9.0-RC1 #3: Fri Oct 28 16:45:28 EDT 2011 root@bt.pa.msu.edu:/usr/obj/usr/src/sys/ALEX i386), and ever since that upgrade the kernel keeps flooding my log files with messages like these:
A> Nov 7 16:40:01 bt kernel: in_arp: source hardware address is multicast.in_arp: source hardware address is multicast.
A> Nov 7 16:42:02 bt kernel: in_arp: source hardware address is multicast.in_arp: source hardware address is multicast.
A>
A> A Google search for these didn't reveal any useful results as to why this happens or how to fix it. So I did a tcpdump and matched the time stamps with packets, and I found the ones causing problems (the only ones with a multicast bit set) to be like this:
A> 16:40:01.099823 02:02:23:09:44:3c > 03:bf:23:09:44:87, ethertype ARP (0x0806), length 60: Ethernet (len 6), IPv4 (len 4), Reply 35.9.68.228 is-at 03:bf:23:09:44:e4, length 46
A> 0x0000: 03bf 2309 4487 0202 2309 443c 0806 0001
A> 0x0010: 0800 0604 0002 03bf 2309 44e4 2309 44e4
A> 0x0020: 02bf 2309 443c 2309 4487 0000 0000 0000
A> 0x0030: 0000 0000 0000 0000 0000 0000
A>
A> It appears the broadcast MAC 03:bf:23:09:44:87 is part of Microsoft's network load balancing mechanism, with the 03:bf indicating that much and the 23:09:44:87 containing the IP address of the load balance cluster (35.9.68.228). These types of MACs seem to be commonly used in their load balancing implementation.
A>
A> To prevent these messages from producing thousands of lines of logs each day, I added the following two IPFW rules and enabled ethernet package filtering (sysctl net.link.ether.ipfw=1):
A> deny ip from any to any MAC 03:bf:00:00:00:00/16 any layer2
A> allow ip from any to any layer2
A>
A> This effectively blocks those packages and the resulting error messages. But I'm wondering if the newly added(?) ARP code in FBSD 9 is a bit too fussy about these, or if MS is abusing the ARP protocol here. Either way, this was never a problem with FBSD 7 or 8.
Can you try attached patch. It reduces severity level of all ARP
messages, that can be triggered by packet on network, with expection to
"using my IP address".
With default syslog.conf, now ARP errors won't get to console.
Also, the multicast message lacked "\n" newline character, that's why,
I suppose, syslogd failed to coalesce a number of messages into a single
entry "last message repeated X times".
--
Totus tuus, Glebius.
--uZ3hkaAS1mZxFaxD
Content-Type: text/x-diff; charset=koi8-r
Content-Disposition: attachment; filename="if_ether.c.diff"
Index: if_ether.c
===================================================================
--- if_ether.c (revision 227416)
+++ if_ether.c (working copy)
@@ -433,7 +433,7 @@
if (m->m_len < sizeof(struct arphdr) &&
((m = m_pullup(m, sizeof(struct arphdr))) == NULL)) {
- log(LOG_ERR, "arp: runt packet -- m_pullup failed\n");
+ log(LOG_NOTICE, "arp: runt packet -- m_pullup failed\n");
return;
}
ar = mtod(m, struct arphdr *);
@@ -443,7 +443,7 @@
ntohs(ar->ar_hrd) != ARPHRD_ARCNET &&
ntohs(ar->ar_hrd) != ARPHRD_IEEE1394 &&
ntohs(ar->ar_hrd) != ARPHRD_INFINIBAND) {
- log(LOG_ERR, "arp: unknown hardware address format (0x%2D)\n",
+ log(LOG_NOTICE, "arp: unknown hardware address format (0x%2D)\n",
(unsigned char *)&ar->ar_hrd, "");
m_freem(m);
return;
@@ -451,7 +451,7 @@
if (m->m_len < arphdr_len(ar)) {
if ((m = m_pullup(m, arphdr_len(ar))) == NULL) {
- log(LOG_ERR, "arp: runt packet\n");
+ log(LOG_NOTICE, "arp: runt packet\n");
m_freem(m);
return;
}
@@ -527,7 +527,7 @@
req_len = arphdr_len2(ifp->if_addrlen, sizeof(struct in_addr));
if (m->m_len < req_len && (m = m_pullup(m, req_len)) == NULL) {
- log(LOG_ERR, "in_arp: runt packet -- m_pullup failed\n");
+ log(LOG_NOTICE, "in_arp: runt packet -- m_pullup failed\n");
return;
}
@@ -537,13 +537,14 @@
* a protocol length not equal to an IPv4 address.
*/
if (ah->ar_pln != sizeof(struct in_addr)) {
- log(LOG_ERR, "in_arp: requested protocol length != %zu\n",
+ log(LOG_NOTICE, "in_arp: requested protocol length != %zu\n",
sizeof(struct in_addr));
return;
}
if (ETHER_IS_MULTICAST(ar_sha(ah))) {
- log(LOG_ERR, "in_arp: source hardware address is multicast.");
+ log(LOG_NOTICE, "in_arp: %*D is multicast\n",
+ ifp->if_addrlen, (u_char *)ar_sha(ah), ":");
return;
}
@@ -645,7 +646,7 @@
if (!bcmp(ar_sha(ah), enaddr, ifp->if_addrlen))
goto drop; /* it's from me, ignore it. */
if (!bcmp(ar_sha(ah), ifp->if_broadcastaddr, ifp->if_addrlen)) {
- log(LOG_ERR,
+ log(LOG_NOTICE,
"arp: link address is broadcast for IP address %s!\n",
inet_ntoa(isaddr));
goto drop;
@@ -681,7 +682,7 @@
/* the following is not an error when doing bridging */
if (!bridged && la->lle_tbl->llt_ifp != ifp && !carp_match) {
if (log_arp_wrong_iface)
- log(LOG_ERR, "arp: %s is on %s "
+ log(LOG_WARNING, "arp: %s is on %s "
"but got reply from %*D on %s\n",
inet_ntoa(isaddr),
la->lle_tbl->llt_ifp->if_xname,
@@ -716,10 +717,10 @@
if (ifp->if_addrlen != ah->ar_hln) {
LLE_WUNLOCK(la);
- log(LOG_WARNING,
- "arp from %*D: addr len: new %d, i/f %d (ignored)",
- ifp->if_addrlen, (u_char *) ar_sha(ah), ":",
- ah->ar_hln, ifp->if_addrlen);
+ log(LOG_WARNING, "arp from %*D: addr len: new %d, "
+ "i/f %d (ignored)\n", ifp->if_addrlen,
+ (u_char *) ar_sha(ah), ":", ah->ar_hln,
+ ifp->if_addrlen);
goto drop;
}
(void)memcpy(&la->ll_addr, ar_sha(ah), ifp->if_addrlen);
--uZ3hkaAS1mZxFaxD--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20111110065135.GS71907>