From owner-freebsd-net@FreeBSD.ORG Mon Jun 10 15:29:16 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 3B4978E3 for ; Mon, 10 Jun 2013 15:29:16 +0000 (UTC) (envelope-from gd@bluecubesystems.com) Received: from fallback-in2.mxes.net (fallback-out2.mxes.net [216.86.168.191]) by mx1.freebsd.org (Postfix) with ESMTP id 1A8831EBC for ; Mon, 10 Jun 2013 15:29:15 +0000 (UTC) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by fallback-in1.mxes.net (Postfix) with ESMTP id 8E91C2FDBDE for ; Mon, 10 Jun 2013 11:22:19 -0400 (EDT) Received: from serrano (unknown [196.213.208.10]) by smtp.mxes.net (Postfix) with ESMTPA id 358C722E256 for ; Mon, 10 Jun 2013 11:22:07 -0400 (EDT) X-Recieved: Authenticated email user (SMTP-AUTH) Message-ID: <51B5EF1D.1080204@bluecubesystems.com> Date: Mon, 10 Jun 2013 17:22:05 +0200 From: Gregor Dreijer User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130510 Thunderbird/17.0.6 MIME-Version: 1.0 To: freebsd-net@freebsd.org Subject: Gratuitous ARP increasing mbufs Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jun 2013 15:29:16 -0000 Hi, I am running a system on FreeBSD 9.1-RELEASE. I have a device on the network which is sending gratuitous ARP messages (used by a wireless mesh network for a "bridge-loop avoidance" protocol) every 10 seconds. This causes the mbuf clusters to slowly increase on FreeBSD, until the maximum is reached, which disables the networking. I am running netstat -m to keep track of the mbuf run away / leak. My understanding is that mbufs are allocated to hold these messages, but since they are "replys" they are never used. I am now using ipfw, to drop all ARP messages with the following rule: ipfw add 999 deny layer2 mac-type arp MAC ff:ff:ff:ff:ff:ff ac:86:74:02:8a:ff via vte0 It solves the problem. Luckily there are only offending gratuitous ARP messages from this MAC address, so I don't loose any ARP messages that I would need. I believe this might be a bug in FreeBSD. Shouldn't these gratuitous ARP packets be handled in a more elegant way? The increasing mbufs doesn't seem right. A timeout on these mbufs or a maximum number of mbufs that can be allocated for this type of packet might solve this problem. I just wanted to bring this to the developers attention. Thanks very much, Greg The details of the ARP message are as follows (from Wireshark): No. Time Source Destination Protocol Length Info 2450 4642.007546000 OpenMesh_02:8a:ff Broadcast ARP 60 Gratuitous ARP for 0.0.0.0 (Reply) Frame 2450: 60 bytes on wire (480 bits), 60 bytes captured (480 bits) on interface 0 Ethernet II, Src: OpenMesh_02:8a:ff (ac:86:74:02:8a:ff), Dst: Broadcast (ff:ff:ff:ff:ff:ff) Destination: Broadcast (ff:ff:ff:ff:ff:ff) Address: Broadcast (ff:ff:ff:ff:ff:ff) .... ..1. .... .... .... .... = LG bit: Locally administered address (this is NOT the factory default) .... ...1 .... .... .... .... = IG bit: Group address (multicast/broadcast) Source: OpenMesh_02:8a:ff (ac:86:74:02:8a:ff) Address: OpenMesh_02:8a:ff (ac:86:74:02:8a:ff) .... ..0. .... .... .... .... = LG bit: Globally unique address (factory default) .... ...0 .... .... .... .... = IG bit: Individual address (unicast) Type: ARP (0x0806) Padding: 000000000000000000000000000000000000 Address Resolution Protocol (reply/gratuitous ARP) Hardware type: Ethernet (1) Protocol type: IP (0x0800) Hardware size: 6 Protocol size: 4 Opcode: reply (2) [Is gratuitous: True] Sender MAC address: 43:05:43:05:00:00 (43:05:43:05:00:00) Sender IP address: 0.0.0.0 (0.0.0.0) Target MAC address: ff:43:05:02:a2:0c (ff:43:05:02:a2:0c) Target IP address: 0.0.0.0 (0.0.0.0)