UDP datagram wrongly reassembled

edit

This looks like an example of analysis issues caused by ip.id reuse.

Excluding the TCP and ICMP packets (!tcp && !icmp), the sample capture shows reconstituted UDP packets from ip address 192.168.1.145 to ip address 192.168.1.3, with each UDP packet made from 17 IP packets of which which the first 16 IP packets have ip.flags.mf == True. IP level fragmentation makes use of the ip.id field to help identify the relevant fragments. Reuse of ip.id values can trigger analysis ambiguities when an aip.id is used more than once and an earlier fragmented UDP packet is not fully resolved.

In In the case of frame.number == 1125980 we have ip.id == 0xb002 and in the case of frame.number == 1125995 we have ip.id == 0xb003.

With ip.id == 0xb002 we see that we have only 12 of the expected 17 ip packets at approximately 23.293 seconds into the capture (frame.number in {19306..19317}). Several seconds later at approximately 33.266 seconds into the capture (frame.number in {1125964..1125980}) we have a second group of packets with ip.id == 0xb002. If we expand the [IPv4 Fragments] tree in the packet details of frame.number == 1125980 we see this UDP packet appears to be composed of 29 IP packets.

With ip.id == 0xb003 at approximately 23.293 seconds into the capture (frame.number in {19318..19319}) we see the last two IP packets of an expected 17 ip packets for an expected UDP packet. At approximately 33.266 seconds into the capture (frame.number in {11259581..1125997}) for we see a complete set of 17 ip packets for a UDP packet. On frame.number == 1125995 the [IPv4 Fragments] field only shows 17 IP packets with the last two parts of the UDP packet reconstituted with frame.number in {19318..19319} and notframe.number in {1125996..1125997}. One could argue that we should see a list of 19 IP packets for this particular UDP packet.