Skip to content

fix(toolkit): scapy engine raises MissingKeyError('IP') on a PCAP-NG interface with raw-IP link type #1517

Closed

Description

@JarryShaw

On main 6af87f608, 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.

Activity

  1. added
    fixPull requests that fix a defect (fix: subject prefix)
    blockedDeferred pending another issue or decision; see the last comment for what unblocks it
    on Oct 9, 2026
  2. JarryShaw commented on Oct 10, 2026

    @JarryShaw
    OwnerAuthor

    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.

  3. added
    wipWork in flight - a covering PR is open or an agent is actively on it
    and removed
    blockedDeferred pending another issue or decision; see the last comment for what unblocks it
    on Oct 10, 2026
  4. JarryShaw commented on Oct 10, 2026

    @JarryShaw
    OwnerAuthor

    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.

  5. added
    blockedDeferred pending another issue or decision; see the last comment for what unblocks it
    and removed
    wipWork in flight - a covering PR is open or an agent is actively on it
    on Oct 10, 2026
  6. moved this from WIP to Blocked in PyPCAPKiton Oct 10, 2026
  7. JarryShaw commented on Oct 10, 2026

    @JarryShaw
    OwnerAuthor

    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.

  8. added
    wipWork in flight - a covering PR is open or an agent is actively on it
    and removed
    blockedDeferred pending another issue or decision; see the last comment for what unblocks it
    on Oct 10, 2026
  9. moved this from Blocked to WIP in PyPCAPKiton Oct 10, 2026
  10. removed
    wipWork in flight - a covering PR is open or an agent is actively on it
    on Oct 10, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    fixPull requests that fix a defect (fix: subject prefix)

    Projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions