Gratuitous ARP increasing mbufs

G

greg_bcs

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 ethernet interface. I am running netstat -m to keep track of the mbuf run away.

My understanding is that mbufs are allocated to hold these messages, but they are never used (or there are no replies). Is there a way that I can force FreeBSD to ignore these messages, or drop them somehow?

Thanks very much,
Greg

The details of the ARP message are as follows (from Wireshark)

Code: 
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)
 
I am trying to use IPFW to block those incoming messages. Is this possible?

I have added
Code: 
net.link.ether.ipfw=1
to the sysctl.conf file. This is meant to allow filtering of any ethernet packets, not just IP packets.

I have also added a rule for IPFW:
Code: 
deny ip from any to any MAC ff:43:05:02:a2:0c any layer2

So far, the rule is never triggered, and the packets still cause the mbufs to increase. :(

Any ideas?

Thanks,
Greg
 
Looks like I made a mistake in the above rule... I was looking inside the ARP protocol.

I actually need to block only certain broadcast messages from MAC ac:86:74:02:8a:ff, which are ARP messages of a specific type!

Can IPFW look inside an ethernet message, at the details of the ARP target address? Any IPFW experts? :)
 
Why are you so sure that the mbuf leak is related to these packets? Is this the only traffic the box receives?
 
glebius@ said:
Why are you so sure that the mbuf leak is related to these packets? Is this the only traffic the box receives?
Click to expand...

There is other traffic, but these ones arrive exactly every 10 seconds, and the mbufs increase at the exact time these packets arrive. I also counted the increase in mbufs and it is exactly the same as the number of these messages that I can see in Wireshark.
 
Well, I added a rule that fixes my problem... ;)

Code: 
ipfw add 999 deny layer2 mac-type arp MAC ff:ff:ff:ff:ff:ff ac:86:74:02:8a:ff via vte0

So that will deny any ARP broadcast packet from MAC
Code: 
ac:86:74:02:8a:ff
. Luckily the offending gratuitous ARP packets are the only ARP packets from that MAC, so it is safe to block them all.

I still believe there is 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 the same packet might solve this problem.

Is there a specific place where I could raise this potential issue with the FreeBSD kernel
developers?

Thanks,
Greg
 
You must log in or register to reply here.
Back
Top