A Digital Garden - frequent growth but a bit weedy in the back corner
A gratuitous ARP that names a MAC address in its Target MAC field. Sender IP equals Target IP, as in every gratuitous packet. The Target MAC field changes neither who receives the packet nor what it means.
Why the field doesn’t matter - Ethernet dst decides who receives the packet, not Target MAC. A broadcast Ethernet dst reaches every host and a unicast one reaches only one. Your GratuitousARPRequestBroadcastVsBlankTargetMAC note warns about mixing up these two fields. - Sender MAC and Sender IP carry the meaning. Receivers update their caches from that pair. In a gratuitous packet the target fields only repeat information: Target IP is the sender’s own address, and Target MAC is ignored. Your private GratuitousARPMessages quotes the source saying so (“the contents of this field are irrelevant – they are ignored”).
Where the unicast value comes from
Your shape notes say it is “often the sender’s own” MAC. From memory, not checked against the source or your captures:
- iputils arping -A (reply mode) puts the sender’s own MAC in Target MAC.
- arping -U puts ff:ff:ff:ff:ff:ff there.
- The Linux kernel’s own announcements leave it 00:00:00:00:00:00.
So a unicast Target MAC mostly tells you which software sent the packet. BroadcastVsBlank calls the field a rough fingerprint for that reason.
Shapes in your notes
A unicast Target MAC occurs in four shapes, plus their SenderMACMismatch twins:
| Ethernet dst | Request | Reply |
|---|---|---|
| broadcast | GratuitousARPRequestUnicastTarget | GratuitousARPReply (row 511) |
| unicast | UnicastGratuitousARPRequest (row 1) | UnicastGratuitousARPReply |
Requests with a unicast Target MAC get a shape of their own, because the request shapes are named by Target MAC. Replies don’t: GratuitousARPReply covers all three Target MAC values in one shape.
I can run the categoriser over your captures to see whether any of these turn up, and from which hosts.