[JarryShaw]

• Searched for similar pull requests
• Followed the coding style (make pylint, make mypy, make isort) — not run as make; mypy reports nothing in frame.py, tests/project isort test passes
• make test passes, and a test case covers the change — the modules listed below, not make test
• Added a changelog entry under docs/source/changelog/ and regenerated CHANGELOG.md, if the change is user-visible — N/A, added centrally after the wave

What is the purpose of your pull request?

• fix — corrects a defect

---

Description of your pull request and other information

Closes #1385

Frame.make() defaulted incl_len to min(len(packet), snaplen), so snaplen 0 built a 16-octet record with no data. A zero snaplen now means no limit. Sources: draft-ietf-opsawg-pcap §4 says SnapLen "MUST NOT be zero"; libpcap's pcapint_adjust_snapshot (savefile.c) reads 0 as the link-type maximum; PCAP-NG here already treats 0 as no limit. Changed default in make() only for snaplen 0; an explicit incl_len, and so parse → from_data → pack, is unchanged.

• Before: make(packet=4 octets) under snaplen 0 → …00000000 04000000, no data. After: …04000000 04000000 deadbeef, and it parses and rebuilds byte-exact.
• New tests/protocols/misc/pcap/test_frame_snaplen_zero_1385_unit.py: 3 passed; with origin/main's frame.py, 2 failed, 1 passed (the snaplen-2 control).
• tests/protocols/misc/pcap/* all pass; run_unittest_leg.py foundation 522 OK; protocols --exclude protocols/internet 1021 OK; tests/integration 90 passed, 2 skipped; tests/project 399 passed, 1 skipped. All run under a 200 MiB file-size cap.

[JarryShaw]

Cross-review verdict on dc236a221: GOOD TO GO (Sonnet reviewed; author Opus).

• Sources check out. The reviewer fetched them directly. draft-ietf-opsawg-pcap-05 §4 says snaplen MUST NOT be zero and, with no limit specified, SHOULD be at least the largest packet. libpcap's pcapint_adjust_snapshot (savefile.c) treats 0 as bogus and substitutes the link-type maximum. pcapkit's own PCAP-NG reader treats 0 as no limit (pcapng.py:1083). Reading 0 as no limit is consistent; refusing it only in Frame.make would reject a header that parses fine.
• Fuzz. 10 snaplens × 7 packet sizes against main: the only 6 differences are snaplen 0 with a non-empty packet. Every snaplen other than 0 gives byte-identical output.
• Fixtures. All 16 fixture .pcap files (1,465 frames) round-trip with 0 mismatches, identical on both trees.
• Tests. The revert proof gives 2 failed (the two snaplen-0 tests). I re-ran the foundation leg myself at this head and got 522/0.

Nits: the PR cites pcapng.py:1081, but the line is :1083. Refusing to write a snaplen-0 header would be a separate, stricter change and is out of scope here.

[github-actions]

Coverage: 89.40% (unit tier, Python 3.14, dc236a221, Unit Tests run success)

Package	Statements	Missed	Branches	Partial	Cover
pcapkit (top level)	104	4	20	4	93.55%
pcapkit/const	18791	968	2352	869	90.90%
pcapkit/corekit	2038	89	634	25	94.76%
pcapkit/dumpkit	234	2	84	2	98.74%
pcapkit/foundation	2637	98	928	48	94.78%
pcapkit/interface	112	7	40	5	92.11%
pcapkit/protocols	16408	219	4370	182	98.03%
pcapkit/toolkit	539	74	168	3	84.58%
pcapkit/utilities	429	4	122	4	98.55%
pcapkit/vendor	4409	2342	1006	157	43.25%

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