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(protocols): a trial next-layer parse that is replaced by Raw still emits its SchemaWarnings #1580
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.
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.
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.
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
Activity
JarryShaw commentedon Oct 10, 2026
Root cause corrected: this is not specific to PCAP-NG or to the SPB schema. The schema reads the truncated block correctly.
_spb_data_lengthreturns 10, and the block's 28 octets add up._parse_next_layer(pcapkit/protocols/protocol.py:2286). It buildsEthernetfrom the 10 captured octets, and the reads ofsrcandtypewarn atprotocols/schema/schema.py:1154-1156.protocol.py:2291-2293) then sees 10 < 14 and replaces that layer withRaw. The warnings describe a layer the result never contains.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_layerbuffers warnings through aContextVarinpcapkit/utilities/warnings.py. It re-emits them if the parse is kept and discards them if the layer becomesRaw. This avoidscatch_warnings, because of the registry problemBaseWarningdocuments.A worker is on it.
[-]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[/+]fix(protocols): drop the warnings of a next layer replaced by Raw (#1580
fix(protocols): drop the warnings of a next layer replaced by Raw (#1580