Repository navigation
fix(toolkit): scapy reads TCP behind 6in4 in a later IPv4 fragment #1617
Description
With engine='scapy', TCP is read from behind 6in4 (IPv4 protocol 41) inside a later IPv4 fragment. Under RFC 791, a later fragment's data starts mid-datagram and carries no upper-layer header.
Repro on main (d6f627481): one IPv4 fragment at offset 5 (×8 octets), protocol 41, whose data starts with IPv6/TCP.
| Engine | IPv4 inputs | TCP inputs | Trace inputs |
|---|---|---|---|
| default | 1 | 0 | 0 |
| dpkt | 1 | 0 | 0 |
| scapy | 1 | 1 | 1 |
The same frame with protocol 4 (4in4) gives 0 TCP inputs on every engine.
Cause: scapy binds IPv6 under IP for protocol 41 without frag=0 (its 4in4 and TCP bindings have it). _carrier (pcapkit/toolkit/scapy.py:329-331) walks underlayer without checking frag.
Expected: _carrier returns nothing when an IPv4 layer above has a non-zero fragment offset, as the default engine does.
Found by the #1614 cross-review; I reproduced it. Blocked until #1614 merges, because it edits pcapkit/toolkit/scapy.py.
Activity
JarryShaw commentedon Oct 10, 2026
Blocked until #1614 merges, because it edits
pcapkit/toolkit/scapy.py.JarryShaw commentedon Oct 10, 2026
Unblocked: #1614 merged. A worker is on it together with #1606, since both fix how the scapy adapter finds 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…