You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
fix(toolkit): scapy engine raises MissingKeyError('IP') on a PCAP-NG interface with raw-IP link type #1517
On main6af87f608, extract(fin=..., engine='scapy', tcp=True, trace=True) raises MissingKeyError('IP') from pcapkit/toolkit/scapy.py:358. The input is a PCAP-NG whose second interface is LINKTYPE_RAW (101), carrying examples/captures/tcp.pcap's IPv4 frames with the Ethernet header stripped. The default engine reads the same file: 7 frames, flows [(1, 7), (3, 4, 5)].
Cause: the link type is looked up by scapy's layer name, Enum_LinkType.get(packet.name.upper()). A raw-IP packet's first layer is named IP, and IP is not a link-type name.
Expected: take the link type from the interface, as the dpkt engine does with reader.datalink().
The #1511 review found this. It also happens with trace_format='json', so #1511 did not cause it. It is blocked until #1511 merges, because that PR is editing toolkit/scapy.py.
Unblocked: #1511 has merged (2d088a745). A worker is on this together with #1503, since both fixes are in pcapkit/toolkit/scapy.py. One PR will close both.
Blocked again, this time on the #1522 fix. The worker found that the link type and the "no timestamp" signal are only visible in _reader_type() (pcapkit/foundation/engines/scapy.py:61-121). scapy never copies either onto the packet, and the #1522 fix edits that same function. Once the #1522 PR merges, one PR will fix #1503 and #1517 across the engine and toolkit/scapy.py. Two corrections to the description: the raise is now at pcapkit/toolkit/scapy.py:431, and tcp.pcap's default-engine flows are [(1, 2, 6, 7), (3, 4, 5)], not [(1, 7), (3, 4, 5)]. The default engine also does not dissect link type 101 (that is #1502), so the regression fixture will use 228 (IPv4) instead.
Unblocked: #1546 has merged, so the scapy reader now resets its interfaces per section. A worker is fixing #1503, #1517 and #1549 together in one PR, because all three need _reader_type() in pcapkit/foundation/engines/scapy.py.
Activity
JarryShaw commentedon Oct 10, 2026
Unblocked: #1511 has merged (
2d088a745). A worker is on this together with #1503, since both fixes are inpcapkit/toolkit/scapy.py. One PR will close both.JarryShaw commentedon Oct 10, 2026
Blocked again, this time on the #1522 fix. The worker found that the link type and the "no timestamp" signal are only visible in
_reader_type()(pcapkit/foundation/engines/scapy.py:61-121). scapy never copies either onto the packet, and the #1522 fix edits that same function. Once the #1522 PR merges, one PR will fix #1503 and #1517 across the engine andtoolkit/scapy.py. Two corrections to the description: the raise is now atpcapkit/toolkit/scapy.py:431, andtcp.pcap's default-engine flows are[(1, 2, 6, 7), (3, 4, 5)], not[(1, 7), (3, 4, 5)]. The default engine also does not dissect link type 101 (that is #1502), so the regression fixture will use 228 (IPv4) instead.JarryShaw commentedon Oct 10, 2026
Unblocked: #1546 has merged, so the scapy reader now resets its interfaces per section. A worker is fixing #1503, #1517 and #1549 together in one PR, because all three need
_reader_type()inpcapkit/foundation/engines/scapy.py.fix(engines): take a scapy packet's link type and clock from its inte…
fix(engines): take a scapy packet's link type and clock from its inte…