[JarryShaw]

Please follow the guide below

• You will be asked some questions, please read them carefully and answer honestly

• Put an x into all the boxes [ ] relevant to your pull request (like that [x])

• Use Preview tab to see how your pull request will actually look like

• Searched for similar pull requests

• Followed the coding style (make pylint, make mypy, make isort)

• make test passes, and a test case covers the change

• Added a changelog entry under docs/source/changelog/ and regenerated CHANGELOG.md, if the change is user-visible — N/A — centralised in docs(changelog): shared 1.5.0 changelog — long-lived, merges last (#610, #616, #617, #618, #620) #657

What is the purpose of your pull request?

Tick the commit type your subject line carries.

• fix — corrects a defect
• feat — adds a feature
• perf — changes performance, not behaviour
• refactor — changes neither behaviour nor performance
• test — tests only
• docs — documentation only
• ci — workflows or build tooling
• release — bumps the version or rolls up a distribution
• chore — anything else

---

Description of your pull request and other information

Closes #1607.

dpkt and scapy decode any IPv4 EtherType or tunnel payload as IPv4, whatever its version, and check none of its options, so a header the default engine rejects still produced IPv4 and TCP input.

Each now asks the default engine's own IPv4 parser, reusing pcapkit.toolkit.pypcapfile._default_accepts from #1600 rather than a third copy of the rules (pypcapfile.py itself is unchanged):

• _ipv4_accepted in each toolkit; a version-4, IHL-5 header skips the parser.
• dpkt _tcp_carrier and scapy _carrier check every IPv4 header between the frame and the TCP segment, so outer and tunnelled headers are both covered (fix(toolkit): key tunnelled TCP by the innermost IP header (#1581) #1605).
• ipv4_reassembly of both checks its IPv4 layer too, as the default engine hands no IPv4 input for a rejected header.

Fields checked: the default engine rejects a bad version, an IHL below 5 or past the capture, and bad options. It does not check the header checksum, so that already agreed. Across 42 crafted frames, the cases where IPv4, TCP or flow counts disagree went from 28 to 2. Both remaining cases are dpkt finding no IPv4 inside IPv6 for IPv4 reassembly. The cross-review found further pre-existing dpkt and scapy disagreements that are not about header validity, tracked separately.

New tests: tests/toolkit/test_dpkt_scapy_ipv4_header_checks_1607_unit.py (4 tests, all fail on main). The full suite was not run locally, only narrow selections.

[github-actions]

Coverage: 89.70% (unit tier, Python 3.14, f03b34e4d, Unit Tests run success)

Package	Statements	Missed	Branches	Partial	Cover
pcapkit (top level)	104	3	20	3	95.16%
pcapkit/const	18858	954	2366	868	91.06%
pcapkit/corekit	2366	67	760	35	96.48%
pcapkit/dumpkit	275	3	100	3	98.40%
pcapkit/foundation	2883	147	1010	36	94.07%
pcapkit/interface	138	7	52	5	93.68%
pcapkit/protocols	17089	226	4566	191	98.06%
pcapkit/toolkit	923	134	332	6	84.22%
pcapkit/utilities	494	4	146	4	98.75%
pcapkit/vendor	4409	2342	1006	157	43.25%

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

[JarryShaw]

Verdict: GOOD TO GO at f03b34e4d. This was a Sonnet cross-review; the author ran on Opus.

The review built its own corpus of about 61,000 frames:

• the full IPv4 options grid;
• every version and IHL value against short captures;
• fragments;
• tunnels three deep, behind VLAN, with the outer or the inner header bad;
• 20,000 fuzzed frames.

Results:

• Validation: dpkt and scapy now accept and reject exactly the IPv4 headers the default engine does, with 0 disagreeing frames. On main, 23,334 options-grid frames disagree.
• Fast path: skipping the parser for a version-4, IHL-5 header is safe. The default parser rejected 0 of 396,608 such headers.
• Regressions: none. All 26 generated fixtures give byte-identical dpkt and scapy output.
• Imports: no import-time dependency on pcapfile and no cycle, checked on Python 3.14.
• Tests: every new test fails on main.

Non-blocking:

• Cost: checking a header with options costs about 0.4 ms (4-octet option) to 1.5 ms (40-octet area). It stays below the default engine's own time. _default_accepts has a 2-entry lru_cache, which deep tunnels can thrash.
• Pre-existing gaps: the review found further disagreements that predate this PR and are not about header validity. I will file them separately. So the body's "both remaining cases" and its Total Length remark were too strong, and I have corrected both.