[JarryShaw]

• Searched for similar pull requests

• Followed the coding style (make pylint, make mypy, make isort) — pylint (Makefile flags), mypy and isort run on reassembly/ip.py: clean

• make test passes, and a test case covers the change — the modules listed below only, not the full suite

• Added a changelog entry — N/A, added centrally

• fix — corrects a defect

---

Closes #1357
Closes #1358
Closes #1359

One root cause: IP.reassembly wrote and marked octets from the declared Total Length rather than the octets held, and tested TDL for truthiness. A fragment now writes min(len(payload), TL-IHL) octets, clipped to the buffer, which never changes length. A truncated fragment leaves its partial last block clear. Strict runs stop at TDL and the last run is flushed. TDL is tested against -1, on every fragment.

Behaviour change: a datagram now completes on whichever fragment fills the last hole. Before, it completed only on the fragment with MF clear, and otherwise waited for a flush.

Repro	Before	After
2000 B, middle fragment 500/800 B (3 orders)	COMPLETE, 300 zeros, tail shifted	PARTIAL; strict [1296, 400]; loose 2000 B, [0:1300] real (incl. 4 unmarked tail octets), [1300:1600] zero
FO 0 1480 B + FO 2960 43 B, strict	[1480, 48]	[1480, 43]
FO 0 8 B + FO 65520 7 B, strict	[8]	[8, 7]
proto 59, TL=20, unfragmented	PARTIAL, ()	COMPLETE, b''

Loose mode and truncated tails (documented, not changed). Receipt is tracked in 8-octet blocks, so a truncated fragment's partial last block is not marked. Strict runs leave it out. While TDL is unknown, loose mode returns the prefix up to the first clear bit, so it is left out there too. Once TDL is known, loose mode keeps its real octets and zero-fills only the rest of the hole. The IP docstring and the submit comments now say this.

Tests: tests/foundation/reassembly/test_ip_reassembly_roundtrip_unit.py passes 6, with 8 subtests. With origin/main's ip.py written over the fix, all 6 fail (11 failed counting subtests). These also pass: test_ip, test_ipv6, test_timeout, test_reassembly_base, tests/integration/test_reassembly_end_to_end.py and test_reassembly_engine_parity.py, which include the ipv6.pcap 4-fragment fixture under all 3 engines. tests/project gives 382 passed, 8 skipped.

util/run_unittest_leg.py foundation gives 489 tests, 2 failures and 11 errors, none in reassembly. The 2 failures are test_runtime_engines PCAPEngineTests, which fail identically on origin/main's ip.py. The 11 errors come from #1372, a test on main that writes JSON without bound until the disk fills. Under a 200 MB file-size cap, the leg on this PR and on its base both give the same 2 failures and 2 Errno 27 errors.

[JarryShaw]

Cross-review verdict on 1273d3265: GOOD TO GO (Sonnet reviewed; author Opus).

• Repros: fix(reassembly): a snaplen-truncated IP fragment corrupts the datagram but reports COMPLETE #1357 gave COMPLETE with 300 zeros on main in all three orders; here it is PARTIAL with strict runs [1296, 400]. fix(reassembly): IP strict mode reports wrong runs: whole 8-octet blocks are copied and the last run is dropped #1358 goes from [1480, 48]/[8] to the right runs, [8, 7] for the FO 65520 case. fix(reassembly): an unfragmented IPv4 datagram with a zero-length payload never completes #1359 goes from PARTIAL () to COMPLETE b''. The revert proof fails 11 subtests across all six tests.
• Completing on any fragment: a datagram never completes before MF=0 is seen; TDL stays −1 until then. Out-of-order arrivals now complete on the last fragment instead of at flush. Duplicate, overlap and conflict handling is unchanged. TL < IHL no longer raises IndexError.
• Fixtures: 23 captures × 3 engines × strict on/off gave 138 runs and 0 errors, with frame counts and info identical to the base. Two expected changes in reassembly output: 7 zero-payload datagrams in options-ipv4.pcap now complete, and frame 3 of big_endian*.pcap/little_endian.pcap is truncated on the wire (96 of 1200 octets captured) and is now PARTIAL. ipv6.pcap still completes under all three engines.

Two body/docstring corrections, not blocking:

• Loose mode. The IP docstring and the PR table say holes are zero-filled. In the 500-of-800 case, loose output is 300 zeros plus 4 real octets from the unmarked tail. Either zero that tail or reword the docstring.
• The 11 leg errors are not a leg-ordering effect. test_extraction_record_header_unit writes JSON without bound on main, which is fix(dumpkit): JSON output of DPKT/Scapy frames grows without bound and fills the disk #1372. Under a file-size cap the PR's leg and the base's leg show the same 2 failures and 2 Errno 27 errors. The PCAPEngineTests failure is confirmed to come from fix(dumpkit)!: output writers drop or corrupt what the packets carried #1305 (9093061b3).

[JarryShaw]

Verdict re-pointed to f0dcf5d62: GOOD TO GO. I read the delta from 1273d3265 myself. It touches one file, reassembly/ip.py (+12/−3), and every changed line is a docstring or a comment. The IP docstring now says that the partial last block of a truncated fragment is left out of the strict runs. In loose mode it keeps its real octets and only the rest of the hole is zero-filled. The docstring and a comment also cover the unknown-TDL case. The PR body cites #1372 for the capped-leg errors in place of the ordering explanation. No code changed, so the round-1 verification still holds.

[github-actions]

Coverage: 88.98% (unit tier, Python 3.14, f0dcf5d62, Unit Tests run success)

Package	Statements	Missed	Branches	Partial	Cover
pcapkit (top level)	104	4	20	4	93.55%
pcapkit/const	18777	1032	2348	843	90.27%
pcapkit/corekit	1949	84	606	20	94.91%
pcapkit/dumpkit	189	1	68	1	99.22%
pcapkit/foundation	2452	102	858	39	94.41%
pcapkit/interface	112	7	40	5	92.11%
pcapkit/protocols	16013	206	4178	177	98.06%
pcapkit/toolkit	539	74	168	3	84.58%
pcapkit/utilities	429	4	122	4	98.55%
pcapkit/vendor	4409	2359	1006	158	42.84%

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