[JarryShaw]

• 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
• Changelog entry: N/A — centralised in chore(docs): centralise changelog entries for unreleased versions #2483

What is the purpose of your pull request?

• feat — adds a feature

---

Description of your pull request and other information

A new pcapkit.protocols.link.ieee802_11.IEEE802_11 dissects the IEEE 802.11 MAC header behind radiotap.

• Fields: the per-type header layout (Address 2/3/4, Sequence, QoS and HT Control as clause 9 places them), the Frame Control flags, Control Frame Extension, and S1G Beacon flags. The body stays Raw, and a protocol version other than 0 is refused.
• Radiotap registry: Radiotap gets its own __proto__, keyed by LinkType, with Radiotap.register and register_radiotap. It also fixes Radiotap._get_payload, which included the radiotap fields in the payload.
• Registries: the 802.11 type and subtype registries become pcapkit.const.ieee802_11, built by DATA crawlers that regenerate byte-identically.

Measured:

• 49,152 built frames and every truncation of them round-trip byte-exact.
• tshark agrees on every field value. It differs only on header length, for the control subtypes this dissector deliberately reads at the minimal header.
• Against main, a 4,292-case radiotap differential shows only intended changes, and the 23 sample captures are byte-identical.
• No new docs warnings.

Settled on the worker's recommendations:

• the FCS stays in the body until feat(link): decode radiotap's optional fields #2576 decodes radiotap's Flags;
• the module keeps the name ieee802_11.

A refused frame's CRITICAL log is #2588's ruling: once #2597 merges, it is quiet under the fallback.

Follow-up: bind LinkType.IEEE802_11 (105) and IEEE802_11_RADIOTAP (127) in Frame and PCAP-NG for native 802.11 captures. Until then the dissector is reached through LinuxSLL or direct use.

Closes #2575

[JarryShaw]

GOOD TO GO at b258b984d. A three-lens Sonnet review (spec, conventions, integration) passed, then a delta review of the fix round, then my own check of the final nits. Control Frame Extension's 16-octet header matches Wireshark and Linux, the S1G flags round-trip all 256 values, and _import_next_layer's removal is byte-identical across 71,719 radiotap cases. The dispatch-generator, regeneration and registry-driven tests each fail when the code they pin is broken.

[JarryShaw]

Question for the owner: the five pcapkit.const.ieee802_11 registries are transcribed from a pinned Wikipedia revision (802.11 frame types, rev 1369762968). IEEE Std 802.11-2020 is paywalled, and Table 9-1 is the only source in the standard. The values agree with the Linux kernel header and Wireshark, and vendor/ipx already uses a Wikipedia-oldid DATA literal.

1. Accept it, and record it on const-vendor-pairing.rst: a pinned secondary revision is allowed where the primary source is paywalled and the values are cross-checked (recommended).
2. Require a primary source: hold the registries until someone with access to the standard checks Table 9-1.
   The PR is complete under 1.

[github-actions]

Coverage: 94.05% (unit tier, Python 3.15, 53185d8e0, Unit Tests run success)

Package	Statements	Missed	Branches	Partial	Cover
pcapkit (top level)	104	4	20	2	95.16%
pcapkit/const	20229	149	2740	130	98.74%
pcapkit/corekit	2664	74	836	37	96.60%
pcapkit/dumpkit	281	3	100	3	98.43%
pcapkit/foundation	3370	27	1190	32	98.71%
pcapkit/interface	138	4	52	3	96.32%
pcapkit/protocols	20507	219	5412	204	98.35%
pcapkit/toolkit	961	28	342	10	96.32%
pcapkit/utilities	506	7	144	5	98.15%
pcapkit/vendor	5141	2227	1174	187	53.35%

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

[JarryShaw]

take 1

[JarryShaw]

Owner chose 1, paraphrased: a pinned secondary revision is an acceptable DATA source where the primary source is paywalled and the values are cross-checked, as here against the Linux kernel and Wireshark. The rule is being written onto const-vendor-pairing.rst in this PR, so the next crawler of this kind has a page to cite.

[JarryShaw]

GOOD TO GO at 53185d8e0. I checked the fold myself. It adds only the owner's DATA-source rule, as a 5-line paragraph in const-vendor-pairing.rst's DATA section, citing it as "ruled in review of :pr:2607 (:issue:2575)". The rest of the commit is unchanged from the reviewed b258b984d.

[JarryShaw]

Prefer to move the _make_uint helper into Protocol base class's utilities. I've made a similar request in another open PR. The work seems overlap.

[JarryShaw]

Owner request, paraphrased: move this PR's _make_uint (a range check that an int fits in N bits) into the base Protocol's utilities. It overlaps the request on #2595.
To land the shared helpers once, #2595's fix round is adding the same check to Protocol, beside its vector and uint-list helpers. Blocked: once #2595 merges, this PR rebases onto it and switches its 16 call sites to the Protocol method. Moving to review: needs-changes, with CI on this head cancelled.

[JarryShaw]

#2595 has merged, so _make_uint(self, value, *, bits, name) is on ProtocolBase. A fix round is rebasing this PR onto main (f9d5f0d1d) and switching its call sites to the base method; the check and message are identical. A rebase note and a re-review follow the push. The MAC helpers are unified later under #2614, after this merges.

[JarryShaw]

Fix round pushed: 53185d8e0 → 845c94eaa, rebased onto main f9d5f0d1d.

• Helper move. The PR's own _make_uint is deleted, and its call sites in ieee802_11.py call ProtocolBase._make_uint with the same widths and field names. A before/after differential of every build and refusal the tests and a type/subtype sweep produce is byte-identical, error messages included.
• Conflicts. Six conflicts are resolved by keeping both sides: FRAD and radiotap in the dispatch generators, and the four const pins plus the dispatch-case pin. Each number was re-derived by running the enumeration code.
• Rest of the patch. Outside the resolved files and ieee802_11.py, the per-file patch-ids are unchanged. The protocols/link leg passes.
• Review. The patch changed, so it is back to review: running and a Sonnet delta review is in progress.

[JarryShaw]

GOOD TO GO at 845c94eaa, from a Sonnet review of the fix round.

• The 15 call sites match the deleted helper site for site, by AST, in bit width, field name and value expression, and ProtocolBase._make_uint's body is the same check.
• Across 1,218 builds wrapped in radiotap and parsed back, the built bytes and the error messages are identical at both heads, and the bool handling is unchanged.
• Each re-derived pin equals main's value plus this PR's additions. Only context lines changed in the rest of the patch, and the changelog is untouched.
• Follow-up: six narrowing mutants of the bit widths survive, because no test builds those fields' maximum values. They are control_frame_extension, fragment_number, sequence_number, ack_policy and bits_8_15. The gap predates this round, so the maximum-value builds go in as a test-only change once this merges.