Repository navigation
fix(toolkit): scapy hands IPv4 reassembly the octets past the carrying IPv6 Payload Length #1623
Description
With engine='scapy', IPv4 carried in IPv6 is handed to IPv4 reassembly with octets beyond the carrying IPv6 packet's Payload Length. The default engine stops at the Payload Length, and so does dpkt once #1622 lands.
Repro on main (ee324e1dc): two IPv4 fragments (16 + 8 octets) carried in IPv6 (next header 4).
| Case | default | scapy |
|---|---|---|
| 6 trailer octets after each IPv6 packet: payloads handed over | 16, 8 | 22, 14 (trailer included) |
| IPv6 Payload Length 30 and 24, shorter than the IPv4 inside: payloads | 10, 4 → datagram partial |
16, 8 → datagram complete |
Expected: scapy cuts the IPv4 octets at each IPv6 Payload Length above them, as the default engine does (pcapkit/toolkit/pcap.py, ipv4_reassembly).
The #1615/#1616 worker found this; I reproduced it.
Blocked until the PR for #1606 and #1617 merges, because it edits pcapkit/toolkit/scapy.py.
Activity
JarryShaw commentedon Oct 12, 2026
Unblocked: #1624 merged. A worker is on it together with #1627, since both edit
pcapkit/toolkit/scapy.py.fix(toolkit): scapy cuts 4in6 at each Payload Length and skips ICMP q…
refactor(toolkit): revert scapy's agreement-only code (#1708)
refactor(toolkit): revert scapy's agreement-only code (#1708) (#1724)