https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=14462
Bug ID: 14462
Summary: QUIC dissector produces incorrect packet numbers
(wrong-endian)
Product: Wireshark
Version: unspecified
Hardware: x86
OS: Windows 10
Status: UNCONFIRMED
Severity: Major
Priority: Low
Component: Dissection engine (libwireshark)
Assignee: bugzilla-ad...@wireshark.org
Reporter: afra...@jdpw.com
Target Milestone: ---
Build Information:
Version 2.4.5 (v2.4.5-0-g153e867ef1)
Copyright 1998-2018 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.6.3, with WinPcap (4_1_3), with GLib 2.42.0, with
zlib 1.2.8, with SMI 0.4.8, with c-ares 1.12.0, with Lua 5.2.4, with GnuTLS
3.4.11, with Gcrypt 1.7.6, with MIT Kerberos, with GeoIP, with nghttp2 1.14.0,
with LZ4, with Snappy, with libxml2 2.9.4, with QtMultimedia, with AirPcap,
with
SBC, with SpanDSP.
Running on 64-bit Windows 10, build 16299, with Intel(R) Core(TM) i7-4600M CPU
@
2.90GHz (with SSE4.2), with 11974 MB of physical memory, with locale
English_United Kingdom.1252, with WinPcap version 4.1.3 (packet.dll version
4.1.0.2980), based on libpcap version 1.0 branch 1_0_rel0b (20091008), with
GnuTLS 3.4.11, with Gcrypt 1.7.6, without AirPcap.
Built using Microsoft Visual C++ 14.0 build 24215
Wireshark is Open Source Software released under the GNU General Public
License.
Check the man page and http://www.wireshark.org for more information.
--
The QUIC dissector incorrectly decodes the packet number once it is more than
one byte long. The more significant bits come first - so for example in a
stream that I have decoded the packet numbers in "one direction" go from 1 to
63 (which are all represented in a single byte) 01 to 3f, the next packet uses
two bytes to represent the packet number (so the public flags are 0x10 instead
of 0x00); those two bytes are 00 and 40 which are incorrectly decoded as 16384,
with the next packet being 16640 (00 41)... eventually we get to packet number
65280 (00 ff) which is followed by packet number 1 (01 00)... and you can see
where we are going here.
The capture that I have is too long to add as an attachment, but if you cannot
reproduce simply I can happily provide it (or probably another one).
Thanks,
Alastair France
--
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
