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     
r...@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.
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);
_______________________________________________
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

Reply via email to