[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 #1619

• Cause (confirmed). Each layer from_data rebuilds parses its own octets again. A constructed Internet layer started at _exthdr_depth = 0, so each rebuilt extension header counted its chain from itself, and each parse that reached the 32-header bound warned. A trace shows every nested HOPOPT warning with _rebuilding set.
• Fix. Internet._make_payload (internet.py:336) hands the payload its place in the chain, one past this layer's, through _exthdr_rebuilt (:64). This mirrors how fix(protocols): bound a frame's dissection at 64 layers (#1610) #1620 carries _frame_depth. A constructed IPv6_Ext takes that place (:261, :315). _next_layer_class skips the warning while _rebuilding is set (:409), as _parse_next_layer already does for the frame bound.
• Measured on Ethernet with HOPOPT or Destination Options chains, rebuilding via Ethernet.from_data(info.to_dict()). The cells are rebuild warnings, before → after; the parse gives 0 at 32 headers and 1 past that, both before and after:

Frame	32	33	100	1,000
IPv6	0 → 0	2 → 1	2 → 1	2 → 1
IPv4, protocol 0	0 → 0	2 → 1	33 → 1	33 → 1

In the mixed case the 33rd header is also the 65th layer: 31 IPv4 tunnels under Ethernet, or 30 in a PCAP frame. Its rebuild warnings drop from 33 to 1 for both carriers. On the IPv4 frame with 1,000 headers, the rebuild ran +123 Python frames deeper than the parse, built 1,121 Internet layers and took 155 ms. It now runs +2 deeper, builds 594 and takes 79 ms. Bytes and protocol chain are identical in every case.

• Tests. tests/protocols/internet/test_ext_chain_limit_rebuild_1619_unit.py has 48 subtest failures with the fix reverted, under both pytest and unittest, and passes with it. All 202 files under tests/protocols/, plus the fix(protocols): a chain of ~80+ IPv6 extension headers exhausts recursion and leaves the payload undissected #1604 engine and toolkit tests and the docstring and isort checks, pass one file at a time on 3.14. The chain-bound and frame-bound files also pass on 3.11.

[JarryShaw]

Verdict: GOOD TO GO at 16910f495.

Sonnet cross-review. It confirmed the cause: each rebuilt extension header restarted the chain count. It reproduced the fail-before (the new file fails with the fix reverted), and measured the IPv4 1,000-header rebuild at 155 ms → 76 ms, with 1,121 → 594 Internet layers built.

Non-blocking notes:

• An explicit _exthdr_depth keyword on a constructed layer is dropped (internet.py:261). Nothing passes it.
• The extension-header test is by class, so a user-registered non-IPv6_Ext class under an extension-header number costs extra rebuild work. The output does not change.

Not checked: ESP with a configured SA decrypting a chain of 33 or more headers, and the Sphinx build.

I re-ran the new test file at this head: 5 passed, 119 subtests.

[github-actions]

Coverage: 89.69% (unit tier, Python 3.14, 16910f495, 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	17166	226	4580	191	98.06%
pcapkit/toolkit	1020	154	380	5	83.50%
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.