MIKE HIGGINBOTTOM

A Digital Garden - frequent growth but a bit weedy in the back corner

ARPFieldCombinationNotes

Columns

Combination topic links each row to a topic of its own, e.g. ARPFieldComboRow151, listing every topic the row fits, the one it’s counted as first.
Rows run in nested order: Eth dst changes slowest, then Eth src, Opcode, Sender MAC, Target MAC, IPs, and finally Eth src = Sender MAC, which changes fastest, so the two rows for a unicast Ethernet src and Sender MAC sit side by side.
IPs compares Sender IP with Target IP. It has five states rather than three, because 0.0.0.0 means something different in each IP field:
- equal: both IPs the same and not 0.0.0.0
- different: both real IPs, not the same
- sender 0.0.0.0: an ARP probe, if it’s a request
- target 0.0.0.0: a conflict defence, if it’s a reply
- both 0.0.0.0: always invalid
Eth src = Sender MAC says whether Ethernet src and Sender MAC are the same address. Where both are unicast it can go either way, so those rows appear twice, once for each answer. Otherwise it follows from the two values.
In the by-topic table, any means every value occurs among the rows that fit the topic, not X means every value except X, and a or b lists the values that occur. Each row covers every mix of its values, except Eth src = Sender MAC, which still follows from Eth src and Sender MAC when either isn’t unicast.
That makes 3 × 3 × 3 × 3 × 3 × 5 = 1,215 combinations, plus 135 where a unicast Ethernet src and unicast Sender MAC don’t match: 1,350 in all.
- 3 options for eth dst
- 3 options for eth src
- 3 options for opcode
- 3 options for sender mac
- 3 options for target mac
- 5 options for ips

Why rows are invalid

A row can break more than one rule. It fits each topic whose rule it breaks, and its row topic (e.g. ARPFieldComboRow151) lists them all. The first in this order is the one it’s counted as, which is what arp_packet_categoriser reports. Each topic’s Rows, Profile and filters cover every row that fits it, so they overlap.

Topic	Rule broken
InvalidEthernetSourceMAC	Ethernet src is `ff:ff:ff:ff:ff:ff` or `00:00:00:00:00:00`
BlankEthernetDestinationMAC	Ethernet dst is `00:00:00:00:00:00`, so no card receives it
InvalidARPSenderMAC	Sender MAC is `ff:ff:ff:ff:ff:ff` or `00:00:00:00:00:00`, which would put that address in receivers’ caches
ZeroIPsARPPacket	Both IPs are 0.0.0.0, so it asks and claims nothing
ZeroSenderIPARPReply	A reply from 0.0.0.0 answers nothing
ZeroTargetIPARPRequest	A request for 0.0.0.0 asks for nothing
UnusualARPOpCode	Opcode is neither 1 nor 2: RARP (3, 4), Inverse ARP (8, 9), or malformed

All 72 valid rows have Ethernet src and Sender MAC unicast. Half have them matching and half not. The 36 that don’t match have topics of their own, named after the matching row’s topic with SenderMACMismatch on the end.