[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. Narrow runs only, listed below.

• 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 #1717. The scapy engine cut any record longer than 65,535 octets. Behind that cap sit two more, which each scapy version hits in a different mix:

Cap	Scapy versions	Fix
sniff() reads with recv(), whose size defaults to MTU (0xffff), and every reader slices to it	2.6.0, 2.7.0, 2.8.0	recv() defaults to 0xFFFFFFFF, the most a 32-bit captured length can count
scapy 2.6 reads each PCAP-NG block at MTU	2.6.0	the _read_block() override defaults to the same
scapy 2.8's PCAP reader reads at most MTU * 4 (262,140) octets of a record	2.8.0	the PCAP reader reads the record itself, in 256 KiB chunks

Reading in chunks means a forged captured length costs only the octets the file actually holds.

Tests:

• Synthesised PCAP and PCAP-NG records up to 600,000 octets, plus frame 13 of options-ipv6.pcap (65,590 octets). They pass on scapy 2.6.0, 2.7.0 and 2.8.0, and 9 of the 11 checks fail on main on each.
• Across all 23 generated captures, the only frame whose length changes is that 65,590-octet one.

[JarryShaw]

Verdict: GOOD TO GO at 910d10345. A Sonnet cross-review checked it (author: Opus).

• Records arrive whole: records of 65,536, 262,144 and 600,000 octets come through intact on scapy 2.6.0, 2.7.0 and 2.8.0, for PCAP and for PCAP-NG Enhanced, obsolete and Simple Packet Blocks. Frame 13 of options-ipv6.pcap keeps its sha1.
• Forged length: a record claiming 0xFFFFFFFF octets in a 100-octet file gives [60, 100], peaking at about 110 MiB under a 3 GiB address cap.
• Other captures: across all 23 captures (1,616 frames) on each version, the only length that changes is frame 13, 65,535 → 65,590.
• Fail before: the tests fail on main (9 failed, 2 passed per version). Reverting each of the three parts on its own fails the scapy version it targets.

[github-actions]

Coverage: 89.61% (unit tier, Python 3.15, 910d10345, Unit Tests run success)

Package	Statements	Missed	Branches	Partial	Cover
pcapkit (top level)	104	3	20	3	95.16%
pcapkit/const	18860	954	2368	868	91.06%
pcapkit/corekit	2384	67	764	35	96.51%
pcapkit/dumpkit	275	3	100	3	98.40%
pcapkit/foundation	2907	164	1016	34	93.58%
pcapkit/interface	138	7	52	5	93.68%
pcapkit/protocols	17174	226	4590	190	98.07%
pcapkit/toolkit	1015	173	372	10	80.89%
pcapkit/utilities	508	4	154	4	98.79%
pcapkit/vendor	4417	2342	1010	157	43.38%

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