Can anyone explain why IP id 76 keeps getting reused in this packet capture https://drive.google.com/file/d/1N0hV...
Closed for the following reason "the question is answered, right answer was accepted" by Musky3913 2021-05-21 13:29:25 +0000
The RFC (rfc6864 - Updated Specification of the IPv4 ID Field) mentions that the field has been used for various reasons in the past.
Are the MAC addresses real or was the capture modified?
It's only one vendor (example: eth.addr == 00:09:fb:c8:88:7e) that is doing this.
The device mainly uses 76 but in frame 369 has what looks more normal - 59103.
Can you open a support ticket directly with that vendor?
$ ./tshark -r /tmp/mozilla/*BFR -T fields -e ip.id | sort | uniq -c | sort -n | tail -10
46 0x000000d0
56 0x0000006a
57 0x0000009c
58 0x00000042
105 0x00000068
205 0x0000005c
363 0x00000046
607 0x00000090
1433 0x00000000
5612 0x0000004c
$
The MAC addresses are real the capture was taken using a tap
The IP identification being unique is only important if packets are fragmented. Multicast packets are assigned special MAC multicast and routing is layer 3 multicast. IGMP doesn't use the IP ID for membership. Per RFC 5225, it has been observed to being constant. It still works, but not conformant with RFC 791. It still works, but the Firewalls like manipulating the IP ID and other stuff to make it harder to follow the packets.
Per RFC 5225, 6.3.3. IP-ID Behavior
The IP-ID field of the IPv4 header can have different change patterns: sequential in network byte order, sequential byte-swapped, random or constant (a constant value of zero, although not conformant with [RFC0791], has been observed in practice).
Comments