Repository navigation
fix(protocols): a cut header parses with a Raw next layer but rebuilds with NoPayload #2717
Description
Found by the Sonnet review of the #2710 fix, and reproduced on main at 57a6c366d. A header cut by the capture ends its parse with a Raw next layer, but from_data(info) ends with NoPayload. The rebuilt octets match; only the info differs.
- Ethernet:
001122334455aabbccddeeff08(record('type', 1)) parses asRawand rebuilds asNoPayload. A full 14-octet frame with no payload isNoPayloadboth ways. - GRE:
2000(('protocol_type', 0)) and200008(('protocol_type', 1)) show the same. - FRAD: every direct, SNAP and pad-zero cut shows the same.
A round trip should give back the same layer chain. This touches the from_data rebuild path that #2712 changes, so it is blocked until #2712 merges.
Activity
JarryShaw commentedon Nov 3, 2026
#2712 has merged, but #2711 item 3 (the ruling just taken there) also changes how a cut is recorded on a layer. This holds until #2711 merges, so the two do not reshape the same path at once. Still
blocked.JarryShaw commentedon Nov 3, 2026
#2711 has merged (#2738), so the earlier hold has cleared. This now waits on the #2534 regrouping, which is running in the serial window and moves every protocol module. It is dispatched as soon as that lands, so the fix is written against the new layout.
JarryShaw commentedon Nov 4, 2026
#2534 has landed (#2753), so this is unblocked. A fix is in progress on a branch off
1b4f9703e, in the shared rebuild path rather than a per-protocol override. It includes a registry-wide sweep for siblings.fix(protocols): rebuild a cut header with the next layer it parsed wi…
fix(protocols): rebuild a cut header with the next layer it parsed wi…