Repository navigation
fix(sctp): a last chunk sent without its padding rebuilds with the padding zero-filled #1474
Description
Bug. When the last SCTP chunk arrives without its padding, the rebuild adds the missing padding octets as zeros.
Repro: the #1454 edge case sctp/last-chunk-unpadded, a DATA chunk of 1 octet with no padding, rebuilds 3 octets longer than captured. Four cut variants in tests/protocols/transport/test_transport_edge_roundtrip_unit.py fail the same way: data-1-octet-3-pad/cut31, data-nonzero-pad/cut31, unassigned-type-action-00/cut19 and unassigned-type-action-10/cut23.
This is not the #1458/#1465 short read, which only covers fields the capture ends inside. It is also not the #1468/#1472 trailer, which covers extra octets. Here the padding is simply absent, and padding_length, which chunks, parameters and causes share, always writes it.
Activity
JarryShaw commentedon Oct 9, 2026
Blocked until #1472 merges. #1472 rewrites SCTP's chunk-list parsing in
pcapkit/protocols/schema/transport/sctp.py, which is where this fix goes.fix(schema): a header cut inside a fixed-width field rebuilds as capt…
JarryShaw commentedon Oct 9, 2026
Unblocked: #1472 merged (
6323852a7). A worker is starting on it against currentmain.fix(sctp): rebuild a last chunk short of its padding as captured (#1474)
fix(sctp): rebuild a last chunk short of its padding as captured (#1474)
test(sctp): pin the nested last-item padding drop (#1474)
fix(sctp): rebuild a last chunk short of its padding as captured (#1474)
test(sctp): pin the nested last-item padding drop (#1474)
fix(sctp): rebuild a last chunk short of its padding as captured (#1474…