Repository navigation
fix(toolkit): the dpkt and scapy engines drop TCP behind an IPv6 extension header carried in IPv4 #1606
Description
With engine='dpkt' or engine='scapy', TCP carried behind an IPv6 extension header placed directly in IPv4 (protocol 0 Hop-by-Hop or 60 Destination Options) is dropped from TCP reassembly. The #1600 review also reports the same for AH (protocol 51).
Repro on main (c43e9318c). Each capture is Ethernet, then IPv4 with protocol 0 or 60, then one extension header (next header 6, PadN 4), then TCP carrying data. TCP datagrams reassembled:
| Capture | default | dpkt | scapy |
|---|---|---|---|
| protocol 0 | 1 | 0 | 0 |
| protocol 60 | 1 | 0 | 0 |
| plain TCP (control) | 1 | 1 | 1 |
The default engine walks the chain, and pypcapfile matches it after #1600. Expected: dpkt and scapy step over the same chain and agree with the default engine, within the #1604 depth bound.
Found by the #1581 worker; I reproduced it. Blocked until #1605 and the #1604 PR merge, because both edit pcapkit/toolkit/dpkt.py and scapy.py.
Activity
JarryShaw commentedon Oct 10, 2026
Blocked until #1605 and the #1604 PR merge: both edit
pcapkit/toolkit/dpkt.pyandscapy.py.fix(protocols): bound the IPv6 extension-header chain at 32 headers (#…
fix(protocols): bound the IPv6 extension-header chain at 32 headers (#…
JarryShaw commentedon Oct 10, 2026
Unblocked: #1605 and #1608 merged. A worker is on it together with #1617, since both fix how the dpkt and scapy adapters find the TCP carrier.
fix(toolkit): dpkt and scapy find TCP in IPv4 where the default engin…
fix(toolkit): dpkt and scapy find TCP in IPv4 where the default engin…
fix(toolkit): dpkt and scapy find TCP in IPv4 where the default engin…