Skip to content

fix(protocols): a trial next-layer parse that is replaced by Raw still emits its SchemaWarnings #1580

Closed

Description

@JarryShaw

Parsing a Simple Packet Block truncated by its interface's snaplen emits two spurious SchemaWarnings, packet length < 0: -2 and packet length < 0: -4. The parse itself is correct.

Repro on main (cc084357f): a PCAP-NG with one SHB, one IDB (link type 1, snaplen 10) and one SPB with original length 57 and 10 octets of data. extract(...) gives captured_len 10 and the right 10 octets, but warns twice. The #1573 review saw the same warning on from_data and make for truncated SPBs. Re-packing is byte-identical, so only the warnings are wrong.

Expected: no warning. A truncated SPB is legal: the captured length is min(Original Packet Length, SnapLen).

Found by the #1573 review. The cause is not yet traced; it is likely a padding or length computation in pcapkit/protocols/schema/misc/pcapng.py that subtracts the original length rather than the captured length.

Activity

  1. added
    fixPull requests that fix a defect (fix: subject prefix)
    pendingAccepted and unstarted - nobody is on it and nothing blocks it
    wipWork in flight - a covering PR is open or an agent is actively on it
    and removed
    pendingAccepted and unstarted - nobody is on it and nothing blocks it
    on Oct 10, 2026
  2. JarryShaw commented on Oct 10, 2026

    @JarryShaw
    OwnerAuthor

    Root cause corrected: this is not specific to PCAP-NG or to the SPB schema. The schema reads the truncated block correctly. _spb_data_length returns 10, and the block's 28 octets add up.

    • Where the warnings come from: a trial parse in _parse_next_layer (pcapkit/protocols/protocol.py:2286). It builds Ethernet from the 10 captured octets, and the reads of src and type warn at protocols/schema/schema.py:1154-1156.
    • Why they are spurious: the fix(protocols): a payload layer parsed from a short stream rebuilds default-filled octets #1170 guard (protocol.py:2291-2293) then sees 10 < 14 and replaces that layer with Raw. The warnings describe a layer the result never contains.
    • Same in plain PCAP: a PCAP record with caplen 10 warns identically.
    • Scope: the sample captures hit it 0 times. It needs a capture length below the 14-octet link header.

    Decision: drop the warnings of a trial parse that is replaced by Raw, and keep every warning for a layer that stays. A cut header that is kept still warns, as #1470 intends.

    Mechanism: _parse_next_layer buffers warnings through a ContextVar in pcapkit/utilities/warnings.py. It re-emits them if the parse is kept and discards them if the layer becomes Raw. This avoids catch_warnings, because of the registry problem BaseWarning documents.

    A worker is on it.

  3. changed the title [-]fix(protocols): parsing a snaplen-truncated Simple Packet Block emits spurious negative-length SchemaWarnings[/-] [+]fix(protocols): a trial next-layer parse that is replaced by Raw still emits its SchemaWarnings[/+] on Oct 10, 2026
  4. 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