https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=15712
Bug ID: 15712
Summary: Wireshark hides length and does not fully display
UDP/Ethernet packets if packet is > 1415 bytes.
Product: Wireshark
Version: 3.0.1
Hardware: x86
OS: Windows 10
Status: UNCONFIRMED
Severity: Normal
Priority: Low
Component: Dissection engine (libwireshark)
Assignee: bugzilla-ad...@wireshark.org
Reporter: brco...@gmail.com
Target Milestone: ---
Created attachment 17072
--> https://bugs.wireshark.org/bugzilla/attachment.cgi?id=17072&action=edit
TCPDUMP ethernet tcapture of "cleartool lsview"
Build Information:
Wireshark 3.0.1 (v3.0.1-0-gea351cd8)
Copyright 1998-2019 Gerald Combs <ger...@wireshark.org> and contributors.
License GPLv2+: GNU GPL version 2 or later
<http://www.gnu.org/licenses/old-licenses/gpl-2.0.html>
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
Compiled (64-bit) with Qt 5.12.1, with WinPcap SDK (WpdPack) 4.1.2, with GLib
2.52.2, with zlib 1.2.11, with SMI 0.4.8, with c-ares 1.14.0, with Lua 5.2.4,
with GnuTLS 3.6.3 and PKCS #11 support, with Gcrypt 1.8.3, with MIT Kerberos,
with MaxMind DB resolver, with nghttp2 1.14.0, with LZ4, with Snappy, with
libxml2 2.9.9, with QtMultimedia, with AirPcap, with SBC, with SpanDSP, with
bcg729.
Running on 64-bit Windows 10 (1809), build 17763, with Intel(R) Core(TM)
i7-6820HQ CPU @ 2.70GHz (with SSE4.2), with 32555 MB of physical memory, with
locale English_United States.1252, with libpcap version 1.9.0 (packet.dll
version 0.992), with GnuTLS 3.6.3, with Gcrypt 1.8.3, without AirPcap, binary
plugins supported (0 loaded).
Built using Microsoft Visual Studio 2017 (VC++ 14.12, build 25835).
--
In the attached network trace, I am using a VM to capture a trace of UDP
packets for ClearCase registry lookups. The default buffer size CC uses for a
call/response is 4KB. When I look at the packet trace in wireshark, it only
shows the first 1514 bytes of the packet.
When I look at the same trace using tcpdump -r, it shows me that the packet
size is odd by printing this:
09:15:01.295139 IP 10.134.57.194.50323 > 10.134.49.78.clearcase: UDP, length
136
09:15:01.295866 IP 10.134.49.78.clearcase > 10.134.57.194.50323: UDP, bad
length 4288 > 1472
09:15:01.352985 IP 10.134.57.194.50323 > 10.134.49.78.clearcase: UDP, length
136
09:15:01.353809 IP 10.134.49.78.clearcase > 10.134.57.194.50323: UDP, bad
length 4052 > 1472
The data is all present, as a "strings" output shows all the expected text data
in the list.
tshark traces of the same test also report this when opened with TCPDUMP,
however, tshark ALSO hides the packet size mismatch when displaying packets.
This issue was discovered during an investigation to determine why the data was
not reaching a client host and led us to incorrectly blame the server sending
the 4KB replies.
Wireshark and tshark should at the very least report the size mismatch. I
expect that this may also be an issue with Jumbo packets on Ethernet for both
tcpdump and npcap as neither seems to "notice" the size mismatch during the
capture. Both, however DO capture the entire data stream, so there is that.
--
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
