In a trace file I captured today, I noticed four packets that Wireshark identified as “Gratuitous ARP for 0.0.0.0 (request).” I know that an ARP probe should come from 0.0.0.0, but these four packets were both FROM and TO 0.0.0.0. They are not RARPs or inverse ARPs. eth.type is ARP (0x0806), not RARP (0x8035). arp.opcode is 1 (request), not 3 (reverse request) or 8 (inverse request). In the ARP portion of the packet, the Sender MAC Address is 00:00:85:9c:21:ca, which is the same as the Ethernet source address. The 00:00:85 OUI identifies this as a Canon NIC. It's probably a small all-in-one printer/scanner/copier/fax. The Sender IP Address and Target IP Address are both 0.0.0.0. The Target MAC Address is 00:00:00:00:00:00. With a Target IP address of 0.0.0.0, it's not doing address conflict detection, and it's not looking up the MAC address associated with an IP address. What is the purpose of these packets? asked 22 Jul '11, 21:16  Jim Aragon edited 22 Jul '11, 21:20 |
2 Answers:
I've seen this happen when an embedded platform starts up, the network software stack starts and attaches to the Ethernet interface. Since it's not configured with an IP address yet (DHCP pending) the attachment takes place with the Null IP address. This results in the mentioned ARP. After the DHCP client does its thing, a new ARP is seen, with the correct IP address. answered 24 Jul '11, 09:14  Jaap ♦ |
First thing that comes to mind is that these arp packets might be used to advertise ones presence on the network to some managing software. Maybe a Canon Camera that want to be found by the camera software? Or like you said, a printer that wants to be found automagically by the driver? Please note that this is just a hunch, not from real life experience! :-) answered 23 Jul '11, 01:15  SYN-bit ♦♦ |
