Guy Harris wrote:
That'll prevent reassembly. It couldn't reassemble the packet - there was data missing at the end of the first fragment, so there'd be a hole in the middle of the reassembled packet.
I guess then, this doesn't really help with why I started doing the
investigation, as this seems to be WireShark specific, not something in
the "data".
The doc probably needs *fixing*; it was probably *never* wrong. Even *before* "-s 0" was supported by tcpdump, "-s 65535" worked (and Wireshark/TShark/dumpcap without "-s", and "tcpdump -s 0", do the exact same thing at the libpcap/WinPcap layer that "tcpdump -s 65535" do). "Use the MTU with -s" is not only too much work (picking a value that's too big should be just fine, except perhaps with really old versions of libpcap on some OSes), it's also misleading, as you don't want the "MTU" in the sense of the biggest *payload*, you want the maximum *link-layer* packet size.
Where is that in the Wireshark manual? I'll look at fixing it.
The section I was looking at, was Appendix D:3.
Cheers, and Thanks.
