Repository navigation
frame.py:199 seeds packet['bytesorder'] where readers expect 'byteorder', and no big-endian PCAP fixture exists to catch it #605
Description
Activity
Adding the mechanism, which neither I nor the original reporter had, and which explains why no test catches this.
The consumer is
pcapkit/protocols/schema/misc/pcap/frame.py:29, insidebyteorder_callback:field._byteorder = packet.get('byteorder', sys.byteorder)
and that callback is attached to four fields —
ts_sec(:39),ts_usec(:41),incl_len(:43) andorig_len(:45).So because
pcapkit/protocols/misc/pcap/frame.py:199writespacket['bytesorder']rather than'byteorder', the.get()never finds the key and always falls through tosys.byteorder— the host's native order rather than the capture's declared order.That is why nothing catches it: on a little-endian host reading a little-endian capture, the fallback coincidentally produces the right answer for every field. Every fixture and every CI runner in this repository is little-endian, so the wrong code path has always produced correct results.
The asymmetry is also clear evidence of a copy-paste slip rather than an intentional second key: the sibling
pack()method atframe.py:176spellspacket['byteorder']correctly.Consequence beyond the crash. A big-endian classic PCAP read on a little-endian host would not merely crash — where it does not crash,
ts_sec,ts_usec,incl_lenandorig_lenwould all be byte-swapped, andincl_lenin particular feeds length arithmetic. So this is a correctness issue and not only an availability one.This reinforces the point already in this issue: a fix needs a big-endian fixture, otherwise the corrected code path remains as untested as the broken one.
examples/generators/make_samples.pyis where sample captures are produced.Verified by reading both writers and the consumer on
origin/main(13a75dfcd). The crash itself remains unreproduced — no big-endian.pcapexists to reproduce it with.- added a commit that references this issue
on Sep 22, 2026
pcapkit/protocols/misc/pcap/frame.py:199seedspacket['bytesorder']where every reader expectspacket['byteorder']. The same file spells it correctly eleven lines earlier.The two sites
Same value, same source, two spellings, in one file. Readers use
byteorder—pcapkit/protocols/misc/pcapng.pyandpcapkit/protocols/schema/misc/pcapng.pyeach consult it twice.Effect
The #594 worker reports that a big-endian classic PCAP crashes outright as a result, and that the one-character fix resolves it.
I have confirmed the typo by reading both lines. I have NOT reproduced the crash, and neither did the worker: it states plainly that no big-endian
.pcapfixture exists in the repository, so the failure path is untested. That absence is itself worth noting — a byte-order branch with no fixture is a branch nothing exercises.Notes
examples/generators/make_samples.pyis where sample captures are produced.rjustversusljustfor little-endian short reads, which is a different defect on a different path.