fix(sctp)!: keep the octets after the last whole chunk as captured (#1468)

[JarryShaw]

• Searched for similar pull requests

• Followed the coding style: mypy on the 3 SCTP files reports nothing on the new lines; pylint and isort not run to completion

• make test passes, and a test case covers the change: the new module, the protocols-rest leg (1159 OK), test_capture_roundtrip_runtime.py (4 passed), the transport edge module (6 passed) and tests/project (419 passed, 1 skipped)

• Changelog entry — N/A — centralised in docs(changelog): shared 1.5.0 changelog — long-lived, merges last (#610, #616, #617, #618, #620) #657

• fix — corrects a defect

---

Closes #1468

SCTP has no packet length, so octets after the last whole chunk can't be told apart from a cut chunk. Per #1458, the packet now parses and keeps them as trailer, as #1431/#1460/#1467 do. A raw last element was considered but not used: chunks is keyed by chunk type, so bytes would need a fake key, and from_data could not rebuild from it. A ChunkListField stops at the last chunk whose declared length is present (≥ 4). make(trailer=) writes the trailer under the checksum. A raw chunk passed to make() that is not whole is still rejected.

Before: COOKIE ACK + b'x' (and 3, 4, 5 octets, or a chunk declaring 40 with 8 present) raise ProtocolError. After: each parses and rebuilds exactly, through from_data(info) and from_data(info.to_dict()), alone and under IPv4.

tests/protocols/transport/test_sctp_stray_octets_unit.py: 7 tests, 36 subtests; before the fix, 6 tests and 33 subtests fail. Two existing tests pinned the old behaviour, a chunk running past the packet raising: I updated three test_sctp_unit cases so the declared octets are present, and dropped the SCTP case from test_declared_length_overrun_unit. Not in this PR: the last-chunk padding cut left over from #1465 (sctp/last-chunk-unpadded) is a different shape, octets missing rather than extra, and stays a known failure.

[JarryShaw]

Verdict: GOOD TO GO at ad90caeea. The cross-review ran on Sonnet.

• Byte-exact under both from_data(info) and from_data(info.to_dict()) for 1–7 stray octets, a cut INIT, declared lengths 0/1/2/65535 and mixed chunk runs, both bare and inside IPv4. The CRC32c of the make(trailer=…) output matches an independent computation.
• The tests bite. I re-ran this myself: with main's three SCTP sources the new module plus test_sctp_unit.py give 36 failed; with the PR's they all pass (7 and 37).
• The edits to existing tests are legitimate. The three malformed-length cases still pin the exactly-4 check. The dropped INIT-parameter overrun case now round-trips through trailer rather than raising, which is what fix(protocol): main is red, IPv4 make() with an unparsable raw item no longer raises the wrapped error #1394 is after.
• The per-frame to_dict() hashes over the 1590 frames of examples/captures are unchanged.
• Trailer over short read is the right model here: SCTP carries no packet length, and __short_read__ (fix(schema): a header cut inside a fixed-width field rebuilds as captured (#1458, #1451) #1465) only records cuts in the top-level header.

Not blockers, and both identical on main:

• A final DATA chunk with its padding cut (31 → 32 octets) is fix(corekit): a header cut inside a fixed-width field is zero-filled on parse and rebuilt at full width #1458 territory.
• A cut INIT's 28 octets stay unparsed in trailer. A typed partial chunk would need its own design.

[github-actions]

Coverage: 89.54% (unit tier, Python 3.14, ad90caeea, Unit Tests run success)

Package	Statements	Missed	Branches	Partial	Cover
pcapkit (top level)	104	4	20	4	93.55%
pcapkit/const	18795	960	2356	873	90.97%
pcapkit/corekit	2043	89	636	25	94.77%
pcapkit/dumpkit	242	2	88	2	98.79%
pcapkit/foundation	2648	98	930	48	94.80%
pcapkit/interface	112	7	40	5	92.11%
pcapkit/protocols	16924	227	4572	190	98.02%
pcapkit/toolkit	539	74	168	3	84.58%
pcapkit/utilities	429	4	122	4	98.55%
pcapkit/vendor	4409	2342	1006	157	43.25%

Per-file detail: the coverage-html artifact of this run.