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(pcap,pcapng): a cut PCAP header or PCAP-NG block rebuilds at full width #1470
Bug. A PCAP global header or a PCAP-NG block that is cut short rebuilds at full width. These classes live under pcapkit/protocols/misc/ and do not inherit the four layer bases, so the short-read recording in #1465 does not reach them.
Repro on main (94ae9664c), using the first 24 octets of any examples/captures/*.pcap:
The #1465 cross-review also found that cut PCAP-NG blocks fail 64–188 times per block type, some with ValueError or ProtocolError. Those numbers are the same on main. I have reproduced only the PCAP header case.
Decision needed (raised by #1475's review). Cut PCAP-NG blocks now keep their captured octets in a new info key, truncated_raw.
The corekit record from #1465 (__short_read__) can't be used here. The cut lands inside nested option and record schemas, and rebuilding from zero-filled fields recomputes the lengths, so the result isn't byte-exact.
The naming differs, though:
truncated_raw is visible. It shows up in to_dict() and in every dump of a cut file.
__short_read__ is a dunder key.
Options:
Keep truncated_raw as it is.
Rename it to a dunder key, __truncated_raw__, to match __short_read__ and keep it out of user-facing output.
Either way, whole files are unaffected. #1475 is already marked breaking, so the rename is cheapest now. My recommendation is (2).
Recorded: the owner chose option (2). Cut PCAP-NG blocks will carry their captured octets under the dunder key __truncated_raw__, matching __short_read__, so the key stays out of user-facing output.
The rename goes into #1475, the same PR. After the push I'll reset its review and re-run the cross-review against the new head.
Activity
JarryShaw commentedon Oct 9, 2026
A worker is on it now, on branch
fix/1470-misc-short-read. It builds on #1465's short-read helpers, so its PR will be a draft that depends on #1465.fix(pcap,pcapng)!: a cut PCAP header or PCAP-NG block rebuilds as cap…
JarryShaw commentedon Oct 9, 2026
Decision needed (raised by #1475's review). Cut PCAP-NG blocks now keep their captured octets in a new info key,
truncated_raw.The corekit record from #1465 (
__short_read__) can't be used here. The cut lands inside nested option and record schemas, and rebuilding from zero-filled fields recomputes the lengths, so the result isn't byte-exact.The naming differs, though:
truncated_rawis visible. It shows up into_dict()and in every dump of a cut file.__short_read__is a dunder key.Options:
truncated_rawas it is.__truncated_raw__, to match__short_read__and keep it out of user-facing output.Either way, whole files are unaffected. #1475 is already marked breaking, so the rename is cheapest now. My recommendation is (2).
JarryShaw commentedon Oct 9, 2026
take dunder key as (2)
JarryShaw commentedon Oct 9, 2026
Recorded: the owner chose option (2). Cut PCAP-NG blocks will carry their captured octets under the dunder key
__truncated_raw__, matching__short_read__, so the key stays out of user-facing output.The rename goes into #1475, the same PR. After the push I'll reset its review and re-run the cross-review against the new head.
fix(pcap,pcapng)!: a cut PCAP header or PCAP-NG block rebuilds as cap…
fix(pcap,pcapng)!: a cut PCAP header or PCAP-NG block rebuilds as cap…
fix(pcap,pcapng)!: a cut PCAP header or PCAP-NG block rebuilds as cap…