[JarryShaw]

• Searched for similar pull requests
• Followed the coding style (make pylint, make mypy, make isort) — mypy clean on both files; isort flags only pre-existing wrapping; pylint not run
• make test passes, and a test case covers the change — legs protocols/internet 559/0/0, protocols --exclude protocols/internet 1025/0/0, integration 186/0/0; tests/project 399 passed, 1 skipped
• Added a changelog entry — N/A, added centrally

What is the purpose of your pull request?

• fix — corrects a defect

---

Description of your pull request and other information

• fix(ipv4,tcp): a header length declared past the data zero-fills the missing octets on rebuild #1404: IPv4.read() / TCP.read() (ipv4.py:328, tcp.py:515) raise ProtocolError when ihl / Data Offset exceeds the data, so the parent keeps a Raw payload. Ethernet+IPv4 ihl=6, 20 octets: 34 → 38 before, 34 → 34 after; TCP offset 6 in IPv4: 54 → 62 before, exact after.
• fix(ipv4): make() rejects a TS timestamp dict keyed by address strings #1402: _make_opt_ts converts address keys with parse_ip_address(..., version=4) on both paths. '1.2.3.4' builds like IPv4Address('1.2.3.4'); True raises FieldValueError.
• Breaking: a standalone IPv4/TCP header shorter than its declared length now raises ProtocolError instead of parsing with zero-filled options. TS make() now refuses keys main silently coerced with int(): bool, float, IPv6Address, and digit strings such as '16909060' (all FieldValueError).
• Tests: new tests/protocols/test_ipv4_tcp_header_overrun_unit.py. Three tests that pinned the zero-fill parse now pin the refusal: fix(protocols)!: a declared length running past the data is accepted and zero-filled on rebuild #1398's ..._still_ends_at_eool (renamed ..._is_kept_as_captured, asserts the round trip), plus the IPv4/TCP ..._still_parses tests, which keep OptionField.unpack never returns for a well-formed HOPOPT header with an SMF_DPD option #431's EOOL loop pinned through the schema. With ipv4.py/tcp.py from origin/main: 13 failed, 6 passed, plus 2 failed in the IPv4/TCP unit modules.
• fix(protocols): a declared length running past the data is accepted and zero-filled on rebuild #1325's option check still fires on a complete IPv4 header, so the IPv4 overrun fixtures now carry a complete header plus payload and assert has an option that runs past; the header check is asserted separately on header length N runs past. With pre-fix(protocols): a declared length running past the data is accepted and zero-filled on rebuild #1325 collections.py (6f4bf9dc8^) those option-check assertions fail, the IPv4 ones included.

Closes #1402
Closes #1404

[github-actions]

Coverage: 89.40% (unit tier, Python 3.14, 98c97bf06, Unit Tests run success)

Package	Statements	Missed	Branches	Partial	Cover
pcapkit (top level)	104	4	20	4	93.55%
pcapkit/const	18791	968	2352	869	90.90%
pcapkit/corekit	2038	89	634	25	94.76%
pcapkit/dumpkit	234	2	84	2	98.74%
pcapkit/foundation	2637	98	928	48	94.78%
pcapkit/interface	112	7	40	5	92.11%
pcapkit/protocols	16412	219	4374	182	98.03%
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.

[JarryShaw]

Cross-review verdict on e1158688d: NEEDS CHANGES. The code fix holds; one test-coverage regression (Sonnet reviewed; author Opus; I reproduced the finding).

• fix(protocols): a declared length running past the data is accepted and zero-filled on rebuild #1325's IPv4 option check is still reachable, so the PR's claim that it isn't is wrong. With a complete header (ihl=7, an option 1f0caabbccddeeff, and a payload), IPv4() raises the option check's ProtocolError: … runs past the end of the data ….
• The regression. The 'IPv4 unassigned' fixture in OVERRUNS (test_declared_length_overrun_unit.py:81, ihl=9) now trips the new header check first, and so does the rewritten test_ipv4_unit pin. Both still pass only because their regex matches both messages. No IPv4 test exercises fix(protocols): a declared length running past the data is accepted and zero-filled on rebuild #1325's check any more. Fix: give those fixtures a complete header plus payload, and correct the test_ipv4_unit.py docstring that says the header check runs "ahead of" it.

Everything else holds:

• Fixtures. Across 1,588 frames, the only change is test.pcapng frame 2, which is Raw on both trees and now carries an informative error.
• Fuzz. 1,500 Ethernet frames (IPv4/TCP with random ihl/offset, IPv4-in-IPv4, 6-in-4, 4-in-6, GRE): mismatches drop from 198 on main to 1, and that 1 also mismatches on main.
• Reassembly is unaffected.
• fix(ipv4): make() rejects a TS timestamp dict keyed by address strings #1402. All 30 key types give FieldValueError or correct octets.
• Legs: internet 559, protocols 1025, integration 186, toolkit 287, corekit 633, foundation 522, all with 0 failures.

PR body: bool, float, IPv6Address and digit-string keys used to be silently coerced and now raise. Please list these under the breaking change.

[JarryShaw]

Delta verdict on 98c97bf06: GOOD TO GO. The round-1 coverage gap is closed.

• Tests-only delta. git diff e1158688d touches three test files (+21/−19) and no source.
• fix(protocols): a declared length running past the data is accepted and zero-filled on rebuild #1325's option check is covered through IPv4 again. The 'IPv4 unassigned' fixture and the IPv4 truncated-option pin now use a complete header (ihl=7) plus payload, and assert the option check's own message. The header-length tests assert header length N runs past separately.
• Revert proof. With collections.py taken from 6f4bf9dc8^ (before fix(protocols): a declared length running past the data is accepted and zero-filled on rebuild #1325), every option-check assertion fails, including 'IPv4 unassigned', while the header-length assertions still pass.
• Results. I re-ran the four touched modules myself at this head and got 55/0. The author reports internet 559/0 and protocols 1025/0.
• PR body. It now lists the newly refused TS keys (bool, float, IPv6Address, digit strings) under breaking, and corrects the earlier "unreachable" claim.