Repository navigation
fix(toolkit): pyshark traces TCP behind an extension header in IPv4 that the default engine rejects, and misses it behind Mobility and HIP #1625
Description
With engine='pyshark', TCP behind an IPv6 extension header carried directly in IPv4 is traced differently from the default engine.
Repro on main (ee324e1dc), Python 3.11 and tshark 4.6.9. Each capture is Ethernet, then IPv4 whose protocol names the header, then that header (next header 6), then TCP. Each cell shows TCP reassembly inputs / trace inputs; - means pyshark declines TCP reassembly, as it does on every frame.
| Case | default | pyshark |
|---|---|---|
| plain TCP (control) | 1/1 | -/1 |
| Hop-by-Hop (0), then TCP | 1/1 | -/1 |
| Hop-by-Hop, then TCP with an MSS option of length 3 | 0/0 | -/1 |
| Hop-by-Hop, then TCP whose Data Offset 15 runs past the capture | 0/0 | -/1 |
| Mobility (135), then TCP | 1/1 | -/0 |
| HIP (139), then TCP | 1/1 | -/0 |
Expected: pyshark traces exactly the TCP the default engine reads there. Behind such a header, the default engine reads TCP only if its TCP parser accepts the header (pcapkit/toolkit/pypcapfile.py, _past_extension_headers, which #1624 reuses for dpkt and scapy).
Activity
JarryShaw commentedon Oct 10, 2026
A worker is on it.
fix(toolkit): pyshark traces TCP behind an IPv4 extension header as t…
JarryShaw commentedon Oct 12, 2026
#1628 was closed with a request to resolve conflicts: it overlaps #1624 in
tests/foundation/engines/test_ext_chain_limit_agreement_1604_unit.py. A worker is rebasing the fix ontomain(2e941bbb7). A fresh PR follows, since #1628's branch is gone.JarryShaw commentedon Oct 13, 2026
Widening to IPv4 protocol 140 (Shim6). The capture is IPv4 carrying an 8-octet Shim6 header (Next Header 6), then TCP. pyshark traces the TCP. The default engine traces nothing: it reads
IPv4:Shim6asRaw, becauseIPv6_Extwill not stand in for Shim6 outside IPv6 (pcapkit/protocols/internet/ipv6_ext.py:586). Measured onmain(b375656e1) (3.11, tshark 4.6.9), TCP reassembly / trace inputs:IPV4_EXTENSION_HEADERS(pcapkit/toolkit/pypcapfile.py:130) leaves 140 out for that reason, so a fix keyed on that set misses this case. Round 3 of the #1625 fix is taking this in.fix(toolkit): pyshark traces TCP behind an IPv4 extension header as t…
fix(toolkit): pyshark traces no TCP inside encapsulations the default…