[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 #1604 for the default engine and pypcapfile. The ruling's bound for dpkt, scapy and pyshark follows in #1609.

• Cause. Inside IPv4, each extension header dissects the next one recursively (ipv6_opts.py:324 → Internet._import_next_layer → ProtocolBase._parse_next_layer, about 11 frames a header). The RecursionError was caught by beholder (decorators.py:128), which only logs it and leaves the rest Raw. So TCP was lost after 79 headers on 3.11, and after 85 to 90 on 3.14. IPv6's own walk is a loop with no bound.
• Fix. EXTENSION_HEADER_LIMIT = 32 in pcapkit/protocols/internet/internet.py. Internet._next_layer_class hands each header its depth in the chain. Past 32 the rest stays Raw, with one ProtocolWarning that names the bound. Any other layer between headers starts the count again. IPv6's walk stops at the same depth.
• pypcapfile. _past_extension_headers and _upper_layer stop at 32 too.
• dpkt, scapy, tshark. These walk the chain in their own parsers. Measured, they find TCP past 32: dpkt at any length, scapy up to about 245 layers, tshark up to about 496. They are Gap rows citing fix(toolkit): the dpkt, scapy and pyshark engines do not stop an extension-header chain at 32 #1609 in the new test_ext_chain_limit_agreement_1604_unit.py. One more row cites fix(toolkit): the dpkt and scapy engines drop TCP behind an IPv6 extension header carried in IPv4 #1606: dpkt and scapy dissect no extension header carried in IPv4, at any length.
• The two tunnel tests in test_pypcapfile_ext_chain_limit_1604_unit.py were updated for fix(toolkit): key tunnelled TCP by the innermost IP header (#1581) #1605's tunnel walk, which now reads TCP through IP-in-IP when the innermost layer is IPv4; TCP over IPv6 is still left out.
• Round trips stay byte-exact (frame.data, and from_data(info.to_dict())) at 32, 33 and 1,000 headers.

[github-actions]

Coverage: 89.72% (unit tier, Python 3.14, 254034005, Unit Tests run success)

Package	Statements	Missed	Branches	Partial	Cover
pcapkit (top level)	104	3	20	3	95.16%
pcapkit/const	18858	956	2366	870	91.04%
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	17115	227	4570	192	98.05%
pcapkit/toolkit	907	123	322	6	85.44%
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 d130f15c8. This was a Sonnet cross-review; the author ran on Opus.

All nine claims are confirmed.

• The bound holds: 32 headers still reach TCP and 33 or more do not. This was checked over IPv4 and IPv6, on HBH, Opts, Route, Frag, AH, HIP and mixed chains. Each cut raises one ProtocolWarning naming the bound.
• No RecursionError up to 20,000 headers (IPv6 jumbogram). Every size takes 4–9 ms, against 3.81 s on main at 20,000.
• Round trips are byte-exact at 1, 32, 33 and 1,000 headers.
• pypcapfile matches the default engine in all 30 IPv4 cases.
• No regressions: 291 protocol tests and 9,612 subtests give identical results on both trees.
• The new tests fail on main: 41 failed, 16 passed; the passing ones are boundary guards, mutation-checked.

I reproduced the 32/33/1,000 counts for default, dpkt and scapy myself.

Non-blocking:

• ESP, 253 or 254 as the 33rd header counts toward the bound. An ESP that main dissected after 32 headers is now Raw. RFC 8200 lists ESP as an extension header, so this reads as intended.
• The limit is imported by value. ipv6.py and pypcapfile.py import EXTENSION_HEADER_LIMIT by name, so patching the module attribute only moves the IPv4 path. The constant isn't public.
• Deep nesting is still unbounded. The count restarts at each tunnel, so deep IP-in-IP nesting still exhausts the stack silently, as it does on main. Filed as fix(protocols): deep layer nesting of any protocol exhausts the recursion limit and loses TCP silently #1610.

[JarryShaw]

Hold this until #1605 merges: combined with #1605, two of this PR's tests fail. I merged both heads (143d691ed + d130f15c8, clean textual merge) and ran the affected files on Python 3.11 and 3.14. All pass except tests/toolkit/test_pypcapfile_ext_chain_limit_1604_unit.py, which gives 2 failed / 6 passed on both versions:

• test_a_tunnel_behind_the_chain_warns_only_within_the_limit (count=32) expects the old tunnel warning. fix(toolkit): key tunnelled TCP by the innermost IP header (#1581) #1605 now reads TCP through the tunnel, so pypcapfile returns a packet. The 33 and 1,000 cases still pass, so the bound holds in the combination.
• test_a_new_chain_inside_a_tunnel_is_counted_afresh expects 'tunnelled' in the warning. Since fix(toolkit): key tunnelled TCP by the innermost IP header (#1581) #1605 the warning reads "TCP over IPv6 is left out…". On 3.14 the test also reaches fix(toolkit): key tunnelled TCP by the innermost IP header (#1581) #1605's inner-IPv4 decode, which imports pcapfile (not installed there).

Both are test expectations that predate #1605; the code is unaffected. Merge #1605 first. I'll then rebase this PR onto main with those two tests updated and get the delta re-reviewed. Relabelled review: needs-changes until then.

[JarryShaw]

Verdict: GOOD TO GO at 254034005. This is the round-3 delta review by Sonnet; the author ran on Opus.

This head is one commit on main (d6f627481). Its tree is identical to the re-stacked commit I checked earlier. Only test_pypcapfile_ext_chain_limit_1604_unit.py differs from the reviewed d130f15c8. The review confirmed four things:

• The two updated tests still catch a missing bound. With both limit checks removed: 14 failed / 7 passed on Python 3.11 and 3.14. Either check removed alone still fails both rewritten tests.
• The bound holds on both sides of a tunnel. The cases were 4in4, 4in6, 6in4 and 6in6, with 0, 31, 32 or 33 headers before the tunnel and inside it. Default finds TCP only when both sides are 32 or fewer, and pypcapfile agrees in all 64 cases.
• No test depends on the removed tunnel warning text.
• No regressions. The toolkit, pypcapfile and engine-agreement selection passes on both Pythons. The only additions over main are the PR's own tests.

I corrected the body's new bullet: #1605 reads TCP through IP-in-IP only when the innermost layer is IPv4.