Ask Your Question

Revision history [back]

click to hide/show revision 1
initial version

QUICK protocol - parsing the first byte?

Hi.

So I've been meaning to write a QUICK parser/plugin to extend on the existing parser, mainly for learning. And while using some example data I noticed the first byte changes in value but wireshark parses the values the same.

I can't find any information on why this is and where it's documented. In the example below, the first byte c2 is treated as Long Header, Fixed Bit: True, Packet Type: Initial, the reserved two bits and Packet Number Length: 2 bytes. But c5 in the second frame is parsed in the exact same way.

So my question is, how can c2 and c5 be parsed identically? gif

I suspected they might be part of the CRYPTO payload, but from what I've gathered the initial flags are not encrypted.

QUICK protocol - parsing the first byte?

Hi.

So I've been meaning to write a QUICK parser/plugin to extend on the existing parser, mainly for learning. And while using some example data I noticed the first byte changes in value but wireshark parses the values the same.

I can't find any information on why this is and where it's documented. In the example below, the first byte c2 is treated as Long Header, Fixed Bit: True, Packet Type: Initial, the reserved two bits and Packet Number Length: 2 bytes. But c5 in the second frame is parsed in the exact same way.

So my question is, how can c2 and c5 be parsed identically? gif

I suspected they might be part of the CRYPTO payload, but from what I've gathered the initial flags are not encrypted.

$ wireshark -v

Wireshark 4.0.0 (Git v4.0.0 packaged as 4.0.0-1).

Compiled (64-bit) using GCC 12.2.0, with GLib 2.74.0, with PCRE2, with zlib 1.2.12, with Qt 5.15.6, with libpcap, with POSIX capabilities (Linux), with libnl 3, with Lua 5.2.4, with GnuTLS 3.7.8 and PKCS #11 support, with Gcrypt 1.10.1-unknown, with Kerberos (MIT), with MaxMind, with nghttp2 1.50.0, with brotli, with LZ4, with Zstandard, with Snappy, with libxml2 2.10.2, without libsmi, with QtMultimedia, without automatic updates, with SpeexDSP (using system library), with Minizip, with binary plugins.

Running on Linux 6.0.2-arch1-1, with AMD Ryzen 9 5900X 12-Core Processor (with SSE4.2), with 64230 MB of physical memory, with GLib 2.74.0, with PCRE2 10.40 2022-04-14, with zlib 1.2.13, with Qt 5.15.6, with libpcap 1.10.1 (with TPACKET_V3), with c-ares 1.18.1, with GnuTLS 3.7.8, with Gcrypt 1.10.1-unknown, with nghttp2 1.50.0, with brotli 1.0.9, with LZ4 1.9.4, with Zstandard 1.5.2, with LC_TYPE=en_US.UTF-8, binary plugins supported.

click to hide/show revision 3
None

QUICK protocol - parsing the first byte?

Hi.

So I've been meaning to write a QUICK parser/plugin to extend on the existing parser, mainly for learning. And while using some example data I noticed the first byte changes in value but wireshark parses the values the same.

I can't find any information on why this is and where it's documented. In the example below, the first byte c2 is treated as Long Header, Fixed Bit: True, Packet Type: Initial, the reserved two bits and Packet Number Length: 2 bytes. But c5 in the second frame is parsed in the exact same way.

So my question is, how can c2 and c5 be parsed identically? gif

I suspected they might be part of the CRYPTO payload, but from what I've gathered the initial flags are not encrypted.

$ wireshark -v

Wireshark 4.0.0 (Git v4.0.0 packaged as 4.0.0-1).

Compiled (64-bit) using GCC 12.2.0, with GLib 2.74.0, with PCRE2, with zlib 1.2.12, with Qt 5.15.6, with libpcap, with POSIX capabilities (Linux), with libnl 3, with Lua 5.2.4, with GnuTLS 3.7.8 and PKCS #11 support, with Gcrypt 1.10.1-unknown, with Kerberos (MIT), with MaxMind, with nghttp2 1.50.0, with brotli, with LZ4, with Zstandard, with Snappy, with libxml2 2.10.2, without libsmi, with QtMultimedia, without automatic updates, with SpeexDSP (using system library), with Minizip, with binary plugins.

Running on Linux 6.0.2-arch1-1, with AMD Ryzen 9 5900X 12-Core Processor (with SSE4.2), with 64230 MB of physical memory, with GLib 2.74.0, with PCRE2 10.40 2022-04-14, with zlib 1.2.13, with Qt 5.15.6, with libpcap 1.10.1 (with TPACKET_V3), with c-ares 1.18.1, with GnuTLS 3.7.8, with Gcrypt 1.10.1-unknown, with nghttp2 1.50.0, with brotli 1.0.9, with LZ4 1.9.4, with Zstandard 1.5.2, with LC_TYPE=en_US.UTF-8, binary plugins supported.

click to hide/show revision 4
None

QUICK QUIC protocol - parsing the first byte?

Hi.

So I've been meaning to write a QUICK QUIC parser/plugin to extend on the existing parser, mainly for learning. And while using some example data I noticed the first byte changes in value but wireshark parses the values the same.

I can't find any information on why this is and where it's documented. In the example below, the first byte c2 is treated as Long Header, Fixed Bit: True, Packet Type: Initial, the reserved two bits and Packet Number Length: 2 bytes. But c5 in the second frame is parsed in the exact same way.

So my question is, how can c2 and c5 be parsed identically? gif

I suspected they might be part of the CRYPTO payload, but from what I've gathered the initial flags are not encrypted.

$ wireshark -v

Wireshark 4.0.0 (Git v4.0.0 packaged as 4.0.0-1).

Compiled (64-bit) using GCC 12.2.0, with GLib 2.74.0, with PCRE2, with zlib 1.2.12, with Qt 5.15.6, with libpcap, with POSIX capabilities (Linux), with libnl 3, with Lua 5.2.4, with GnuTLS 3.7.8 and PKCS #11 support, with Gcrypt 1.10.1-unknown, with Kerberos (MIT), with MaxMind, with nghttp2 1.50.0, with brotli, with LZ4, with Zstandard, with Snappy, with libxml2 2.10.2, without libsmi, with QtMultimedia, without automatic updates, with SpeexDSP (using system library), with Minizip, with binary plugins.

Running on Linux 6.0.2-arch1-1, with AMD Ryzen 9 5900X 12-Core Processor (with SSE4.2), with 64230 MB of physical memory, with GLib 2.74.0, with PCRE2 10.40 2022-04-14, with zlib 1.2.13, with Qt 5.15.6, with libpcap 1.10.1 (with TPACKET_V3), with c-ares 1.18.1, with GnuTLS 3.7.8, with Gcrypt 1.10.1-unknown, with nghttp2 1.50.0, with brotli 1.0.9, with LZ4 1.9.4, with Zstandard 1.5.2, with LC_TYPE=en_US.UTF-8, binary plugins supported.