https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=15712
--- Comment #1 from Jaap Keuter <jaap.keu...@xs4all.nl> ---
When looking at the capture I've come to a different conclusion.
In the provided capture file frame #4 is the offending frame. Let's take a
closer look at that.
Using tcpdump it says on frame #4:
15:23:49.581476 ... : UDP, bad length 4372 > 1472
So, the IP protocol interpreter sees (the start of) an IP payload with protocol
ID 17 (==UDP) and lets the UDP protocol interpreter interpret the header.
Indeed there the UDP length is 4380, which minus 8 octets for the UDP header is
4372 for the UDP payload.
Using Wireshark to load the file shows something different for frame #4. It
says:
4 0.001953 ... IPv4 1514 Fragmented IP protocol (proto=UDP 17, off=0, ID=02f7)
So, the IP protocol dissector sees the start of an IP payload with protocol ID
17 (==UDP) but keeps it to itself because the 'More fragments' flag is raised.
Another IP payload for that same ID (=027f) has to be found first to complete
the payload to be handed of to the UDP dissector.
Can Wireshark be set to show the same as tcpdump does? Yes, by going into the
IP dissector preferences and reset the 'Reassemble fragmented IPv4 datagrams'
option. Now it shows the UDP header, with the length field of 4380, which goes
to a 4372 octet payload.
Why is this not an error in Wireshark? Since the IP dissector is explicitly
told not to reassemble fragmented IPv4 datagrams, it would be a bit annoying to
have the UDP dissector whine about its length being too long for the underlying
IP datagram. That would be true for every first fragment of a fragmented IP
datagram (with protocol ID 17).
So why does tcpdump complain about it then? The answer is in the manual page:
BUGS
Some attempt should be made to reassemble IP fragments or, at least to
compute the right length for the higher level protocol.
So, what else is there? The most important part of this capture, being frame #4
shows it. There's the first part of the fragmented datagram, but where's the
rest? Where are the other IP datagrams which make up the complete UDP packet?
Why are these not in the capture? How and where was this capture made? Do they
appear on other interfaces along the path between the endpoints? What
intervening components are there blocking the fragments?
--
You are receiving this mail because:
You are watching all bug changes.___________________________________________________________________________
Sent via: Wireshark-bugs mailing list <wireshark-bugs@wireshark.org>
Archives: https://www.wireshark.org/lists/wireshark-bugs
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-bugs
mailto:wireshark-bugs-requ...@wireshark.org?subject=unsubscribe
