[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 #1606.
Closes #1617.

• fix(toolkit): the dpkt and scapy engines drop TCP behind an IPv6 extension header carried in IPv4 #1606: inside IPv4, dpkt decodes protocol 0 as IPv4, an AH as dpkt.ah.AH, and keeps 43/44/60/135/139 as octets. scapy keeps them all as Raw, except AH, behind which it dissects no TCP. Both now step over these headers with pypcapfile._past_extension_headers, which uses the default engine's own rules and stops at EXTENSION_HEADER_LIMIT. The TCP segment or tunnel behind the headers is decoded from the captured octets. Behind such a header, TCP counts only if the default TCP parser accepts it, as in pypcapfile's _transport.
• fix(toolkit): scapy reads TCP behind 6in4 in a later IPv4 fragment #1617: scapy binds IPv6 (inet6.py:4233 in 2.7.0, :4256 in 2.8.0) and AH (ipsec.py:111) to IPv4 without frag=0. Its carrier walk now runs top-down and stops at a later IPv4 fragment.
• AH (51): the default engine reads past an AH with Payload Length ≥ 1. With 0 (8 octets, under the 12-octet fixed header), it reads nothing. dpkt and scapy now do the same.
• Two dpkt crashes this exposed are fixed. _decode_ip now treats any exception as "not decoded", as the engine does for a whole frame (AttributeError from dpkt's ip6.py:96, fix(dpkt): extract(engine='dpkt') lets a raw AttributeError escape on an IPv6 Fragment header followed by ESP or Destination Options #1351). packet2dict and packet2chain (verbose mode) now treat only packet-like payloads as layers, so VRRP's '' is leaf data and ends the chain. dpkt still reads no TCP in the first frame; that is fix(toolkit): dpkt, scapy and pyshark drop TCP and IPv4 behind some IPv6 extension-header chains #1626.

I measured 45 crafted frames for TCP/trace input counts and records. Before the fix, 26 or 27 of them disagreed with default: the cross-review counts 26 on these same frames (dpkt 22, scapy 25) on 3.11 and 3.14, and the author counted 27 on 3.11 (dpkt 1.9.8, scapy 2.8.0). After the fix, 0 of the 45 disagree there or on 3.14 (scapy 2.7.0). pypcapfile still differs only on TCP over IPv6, which it declines by design. This PR drops the #1606 Gap row in test_ext_chain_limit_agreement_1604_unit.py.

[github-actions]

Coverage: 89.67% (unit tier, Python 3.14, 6c7b4d066, 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	2884	145	1010	35	94.14%
pcapkit/interface	138	7	52	5	93.68%
pcapkit/protocols	17115	226	4570	191	98.06%
pcapkit/toolkit	990	154	364	5	82.94%
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: NEEDS CHANGES at e0aff304a.

Sonnet cross-review. The fix holds: on 216 hand-built frames, disagreements with the default engine fall from 390 to 3, and #1617's second cause (scapy binds AH to proto 51 without frag=0) is confirmed in scapy's source. But dpkt now crashes the whole extraction on two frames that main skipped. I reproduced both on the PR tree; main reads each without raising:

1. IPv4 proto 0, Hop-by-Hop (next header 41), IPv6 with next header 44, a Fragment header (offset 0), Hop-by-Hop, then TCP: AttributeError: 'IP6HopOptsHeader' object has no attribute 'frag_off' at dpkt's ip6.py:96. _decode_ip catches only KeyError/UnpackError, whereas the engine itself catches any Exception (foundation/engines/dpkt.py:491-493).
2. IPv4 proto 0, Hop-by-Hop (next header 6), then TCP with source port 112, in trace mode: dpkt decodes the octets as IPv4 carrying VRRP whose data is '', and packet2dict's wrapper (toolkit/dpkt.py:692) recurses into the str.

Required: catch as the engine does in _decode_ip, and correct its comment and docstring. Skip a non-packet payload in packet2dict. Add a fail-before test for each. Minor: the review counts 26 frames disagreeing before the fix, not 27; and inet6.py:4233 is the scapy 2.7.0 line.

[JarryShaw]

Verdict: GOOD TO GO at 6c7b4d066.

Sonnet cross-review, round 2. Both dpkt crashes are gone.

• Fuzz and handcrafted frames: the 216 handcrafted frames, the 900 fuzz frames (the same 90 disagreements before and after, none added or removed) and 380 new crash-family frames (52 errors before, 0 now) all run cleanly.
• Remaining disagreements: the 100 left on those 380 are fix(toolkit): dpkt, scapy and pyshark drop TCP and IPv4 behind some IPv6 extension-header chains #1626's shapes, which also disagree in controls that bypass this code.
• Output unchanged: packet2chain and packet2dict give identical output on main and the PR for 2961 of 2965 frames, including all 16 fixture captures and verbose mode. The 4 that differ are the frames that raised on main.
• Scope of except Exception: it wraps only dpkt's constructor, as the engine does.

I reproduced the three new tests' fail-before myself: 3 failed with dpkt.py at e0aff304a, 28 passed at this head. The one required change was the body's before-fix count. The two counts differ by one on the same 45 frames, and I have reworded the body to say so. Non-blocking: unlike the engine, _decode_ip drops the frame without a DPKTWarning; and one test pins dpkt 1.9.8's VRRP data == '', which will catch it if dpkt changes that.