Repository navigation
fix(corekit): a header cut inside a fixed-width field is zero-filled on parse and rebuilt at full width #1458
Description
Bug. When the capture ends inside a fixed-width field, the parse pads the missing octets with zeros (pcapkit/corekit/fields/field.py:586). Nothing records the shortfall, so the rebuild writes the field at its full width and the output is longer than the input.
Repro on main (b14d676c5):
e = bytes(12) + b'\x08' # Ethernet cut inside the EtherType
len(Ethernet.from_data(Ethernet(e, 13).info).data) # 14, not 13The #1454 edge-case suite hits this in about 300 cut cases: Ethernet, VLAN, ARP, RARP, L2TPv2, OSPF, IPX, IPv6, HIP, MH, AH, ESP, UDP and SCTP. It also shows up uncut, with an L2TPv2 Offset Size that points past the data and with a final SCTP chunk sent without its padding.
#1451 is the IPv6 extension-header instance of this same root cause. A fix in corekit would cover every family at once.
Activity
JarryShaw commentedon Oct 9, 2026
Needs a decision. There are two ways to make truncated headers round-trip, and they cover #1451 and this issue differently.
ProtocolError, and the captured octets are kept as captured:IPv6-Extinside an IPv6 chain,Rawelsewhere. This is what fix(protocols): a payload layer parsed from a short stream rebuilds default-filled octets #1170, fix(protocols): a declared length running past the data is accepted and zero-filled on rebuild #1325 and fix(ipv4,tcp): a header length declared past the data zero-fills the missing octets on rebuild #1404 already do. A worker has this ready for IPv6 extension headers (branchfix/1451-truncated-ext-header,96488354b). All 12 header kinds then rebuild exactly at every cut offset, for example Routing type 0 going from 32 failures to 0. The cost: a truncated header is no longer decoded, andIPv6_Route(short)raises. That is breaking.corekit/fields/field.py:586,strings.py:374), and pack would write back only that many. Every family keeps decoding a truncated header, and fix(corekit): a header cut inside a fixed-width field is zero-filled on parse and rebuilt at full width #1458's roughly 300 cases across Ethernet, VLAN, ARP, IPX, IPv6, HIP, MH, AH, ESP, UDP and SCTP close together. It is a larger change, but in one place.My recommendation is (2): it fixes the root cause once and loses no decoded detail. If you prefer (2), the #1451 branch would be dropped, because (2) makes its rejection redundant.
JarryShaw commentedon Oct 9, 2026
yea (2) sounds about right
JarryShaw commentedon Oct 9, 2026
Recorded: option (2) it is. Corekit fields will record a short read instead of zero-filling it, and pack will write back only the octets actually read, so every family keeps decoding a truncated header and rebuilds it exactly. The same worker is on it now, starting from
main; the PR will close both this issue and #1451. The reject-based branchfix/1451-truncated-ext-headergets dropped.test(protocols): edge-case round trips for every layer family (#1202)
test(protocols): edge-case round trips for every layer family (#1202)
test(protocols): edge-case round trips for every layer family (#1202) (…
test(roundtrip): drop the edge-case gaps that #1460, #1462 and #1463 …
fix(schema): a header cut inside a fixed-width field rebuilds as capt…
fix(schema): a header cut inside a fixed-width field rebuilds as capt…
fix(schema): a header cut inside a fixed-width field rebuilds as capt…