[JarryShaw]

• Searched for similar pull requests
• Followed the coding style (make pylint, make mypy, make isort) — not run
• make test passes, and a test case covers the change — the new module, util/run_unittest_leg.py protocols/internet (566 OK) and tests/project (399 passed, 1 skipped)
• Added a changelog entry — N/A, added centrally

What is the purpose of your pull request?

• 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

CALIPSO changes in HOPOPT and IPv6-Opts:

• make() overflow: 8 + bitmap + pad > 255 now raises ProtocolError. Before, a 248-octet pad wrote length 00 and a 1000-octet pad wrote f0.
• make() bad pad: a non-bytes pad now raises ProtocolError, not struct.error or TypeError.
• make() bad bitmap: an octet out of 0–255 or not an int raised ValueError/TypeError, a str bitmap raised TypeError, and an int bitmap was misbuilt (4 became 4 zero octets). All now raise ProtocolError. A bool octet, which main wrote as 01, is now rejected too.
• Reader, odd Cmpt Length (behaviour change): make() emitted it but the reader rejected it. RFC 5570 §5.2 sizes the bitmap in 32-bit quanta ("0 bits, 32 bits, 64 bits, 96 bits"), and §5.1.3 says why. So the reader now accepts it. It still rejects a Cmpt Length that Opt Data Len does not cover.

Valid input builds unchanged bytes. That covers the 255-octet boundary and any bytes-like object (bytearray, memoryview) or iterable of ints (tuple, list, range, a generator); each matches main's octets.

Tests: test_ipv6_calipso_make_validation_unit.py passes 7 tests and 56 subtests. On origin/main's two source files, 36 subtests fail (18 per protocol). The equal-output cases pass on both.

Closes #1408

[github-actions]

Coverage: 89.41% (unit tier, Python 3.14, c2280075a, 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	16443	219	4394	182	98.04%
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.

[JarryShaw]

Cross-review verdict on 5a3cfb5cd: NEEDS CHANGES. One narrowing (Sonnet reviewed; author Opus).

• The narrowing. The new bitmap type whitelist (bytes/bytearray/tuple/list) rejects inputs that build on main: memoryview(bytes(8)), range(8), a set, and a generator. That is a public-behaviour narrowing the issue never asked for. Accept any bytes-like object or iterable of ints, validate each element as 0–255 int (rejecting bool), and keep a bare int refused.

Everything else holds:

• RFC 5570, fetched by the reviewer. §5.1.3 sizes the field "in 32-bit words", and §5.2 gives "quanta of 32-bit words (e.g., 0 bits, 32 bits, 64 bits, 96 bits)". So relaxing the reader to accept an odd Cmpt Length is correct; §5.1.8's "64-bit words" is the RFC contradicting itself.
• Fuzz. 3,948 parse→from_data→pack cases. Every accepted input rebuilds byte-exact, 524 odd-cmpt_len inputs are newly accepted, and none is newly rejected.
• make() and tests. Output for every valid bitmap and pad is byte-identical to main. The 255-octet boundary builds and 256 raises. Revert proof: 30 failed.
• Leg. I re-ran protocols/internet myself at this head: 566/0.

[JarryShaw]

Delta verdict on c2280075a: GOOD TO GO. This resolves the round-2 narrowing.

• Accepted bitmaps. I checked this myself on both trees: memoryview, range, a generator and bytes bitmaps build byte-identical HOPOPT output to main (3b02 0710 … 0001020304050607 …).
• Rejected inputs. A bare int, a str and a bool octet now raise ProtocolError. The bool octet built as 01 on main; the PR body states that narrowing, which matches the rule the other address fields follow.
• Unchanged from the reviewed round. Everything else is as the cross-review covered it. Revert proof: 36 subtests fail. protocols/internet 566/0; tests/project 399.