Repository navigation
fix(transport): the SCTP schema on its own repacks a final chunk cut inside its padding at full width #2680
Description
Found while reviewing #2679, and unchanged by it. Schema_SCTP.unpack(raw) or unpack(raw, len(raw)), given a packet whose final chunk is cut inside its padding, packs it back at full width:
data = struct.pack('!BBHIHHI', 0, 3, 21, 7, 1, 2, 0) + b'abcde' # DATA, Length 21, 3 pad octets follow
raw = (struct.pack('!HHI', 5000, 5001, 1) + bytes(4) + data + bytes(3))[:34]
s = pcapkit.protocols.schema.transport.sctp.SCTP.unpack(raw)
len(bytes(s)) == 34; len(s.pack()) == 36Protocol-level rebuilds are exact (SCTP(raw, 34) and SCTP.from_data(info) both give 34). The schema itself is not: nothing records the cut, so PaddingField(length=padding_length) repacks at full width. blocked until #2679 merges, since both edit the SCTP schema.
Activity
JarryShaw commentedon Nov 2, 2026
#2677 and #2679 have merged, so this is unblocked. A worker is on it now. Moved from
blockedtowip.JarryShaw commentedon Nov 2, 2026
The fix is ready at
4c4b0a324. Opening its PR is held because the Actions queue is at 21, and new PRs wait for fewer than 20. A Sonnet review is running on the local commit in the meantime.JarryShaw commentedon Nov 2, 2026
The PR is #2682. A Sonnet review is running.
fix(protocols): record a cut option area or SCTP padding where the da…
fix(protocols): record a cut option area or SCTP padding where the da…