Reading ARP
A request asks who has an address. A reply binds that address to a hardware address. Two bindings are a conflict to report.
Request and reply
ARP maps an IPv4 address to a hardware address on the local link. A request has arp.opcode == 1 and reads, in the Info column, as a question: who has this address. A reply has arp.opcode == 2 and names a sender hardware address for that protocol address. Filter arp && ip.addr is the wrong habit. ARP is not an IP packet with an address pair in the IP header. Filter arp itself, then the opcode.
The fields to quote are arp.src.proto_ipv4, arp.src.hw_mac, and arp.dst.proto_ipv4. A normal request from the lab client asks who has the gateway, 10.8.0.1, and the reply comes from the gateway’s hardware address. That reply is why the next IP packet can be framed for the wire.
arp.opcode == 1 && arp.dst.proto_ipv4 == 10.8.0.1
Two hardware addresses for one protocol address
A single reply updates a cache. Two replies, close together, that give different sender hardware addresses for the same protocol address, are a conflict. On a network you administer, that is worth a note and a look at which ports those hardware addresses live on. Gratuitous requests, where the sender protocol address and the target protocol address are the same, show up when a host announces itself. Record them as announcements. Identify the speakers. Leave any response to the people who run the segment.
This page is a way to read a capture you already have. It is not a method for answering ARP on a network, and a lab that needs a broken cache can use a virtual network built for that exercise rather than the office.
Worked case: the gateway, then a second reply
After the DHCP ack, 10.8.0.40 asks who has 10.8.0.1. The reply says 10.8.0.1 is at 02:00:00:00:00:01, which is the lab router in your inventory. A minute later a second reply says 10.8.0.1 is at 02:00:00:00:00:99. You filter arp.opcode == 2 && arp.src.proto_ipv4 == 10.8.0.1 and sort by time. Two hardware addresses, one protocol address, a few seconds apart.
The note lists both hardware addresses, both frame numbers, and the inventory entry for 02:00:00:00:00:01. The unknown address is the change. You tell the lab owner. You do not send anything to “test” the cache. The capture already showed the disagreement.
arp.opcode == 2 && arp.src.proto_ipv4 == 10.8.0.1
No ARP can be normal
A capture taken above the local link, or a file that started after the cache was filled, can contain IP conversations and no ARP. That is a property of the capture point and the clock. It is not evidence that ARP “was disabled.”
Broadcast requests are easy to over-count. One client joining the lab produces a small burst for the gateway and a few neighbors. Quote the protocol address that was asked for, not a raw ARP total from the whole VLAN.
Diagram
From a who-has to the hardware address that answered
- Request
Opcode 1 asks who has a protocol address.
arp.opcode == 1 && arp.dst.proto_ipv4 == 10.8.0.1
- Reply
Opcode 2 binds that protocol address to a sender hardware address.
- Inventory
Compare the hardware address to the inventory for that IP.
- Second
A second hardware address for the same IP is the conflict you report.
Check yourself
1. Which filter shows ARP replies that claim the lab gateway 10.8.0.1?
2. What makes two ARP replies a conflict worth reporting on a network you administer?
3. You have the conflicting replies in the file. What is the useful next step?