[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

The owner asked on #2576 for radiotap's mixed bitmaps to be decoded properly, in their final shape for 1.6.0. MCS flags, HE data1/data2, HE-MU flags1/flags2 and U-SIG common each decode into a typed data model: integer value subfields plus a known member.

• New registries: HEData1Known, HEData2Known, HEMUFlags1Known, HEMUFlags2Known and USIGCommonKnown. They are crawled through the shared radiotap flag template, which gains a VALUES tuple so value rows stay subfields. Names come from Linux ieee80211_radiotap.h. Undefined bits are kept. MCS flags needs no registry, since its known bits are MCSKnown.
• New field: BitmapField in pcapkit.corekit.fields.numbers reads a word into value subfields and a remainder. The layouts are concrete RadiotapField schemas, per the ruling on feat(link): decode radiotap's optional fields (#2576) #2657.
• make(): it takes each bitmap as a mapping and range-checks every subfield with _make_uint. known takes a member or an int, and a remainder that sets a subfield's bit raises ProtocolError.

Every subfield mask is checked against Linux, Wireshark and radiotap.org. Recomposed, every bitmap is identical to main across #2576's vectors and the fuzz cases, and every record rebuilds exactly.

Closes #2647

[JarryShaw]

NEEDS CHANGES at e212650b0, from a Sonnet cross-review. The code is sound: every mask and known bit matches Linux and radiotap.org, the crawlers regenerate byte-identically, 9372 bitmap round trips are exact, and all 13 mutants are caught. One change is required:

• Rebase onto 342fe7ebe. It merges as text, but feat(link): decode radiotap TLV items a producer cut short (#2655) #2690's test_radiotap_short_tlv_2655_unit.py fails six U-SIG subtests on the merged tree. They expect common as an int, and test_make_refuses_a_malformed_cut now raises on the int common rather than on the record it means to test. Update those cases to the mapping form.

Optional: BitmapField given a missing subfield key raises a bare KeyError, which should be FieldValueError.

[JarryShaw]

GOOD TO GO at ddf28f9fb, rebased onto 342fe7ebe. I checked the delta myself.

• feat(link): decode radiotap TLV items a producer cut short (#2655) #2690 U-SIG tests: they now expect the common mapping, so test_make_refuses_a_malformed_cut again fails on the malformed record rather than on the int common. All of that module's tests pass.
• BitmapField: a missing subfield raises FieldValueError, with a test.

The link, const and corekit legs pass. All 7677 differential records rebuild exactly against the new base, and captures are identical.

[JarryShaw]

can actually use auto() in the generated IntFlag values?

[JarryShaw]

Needs deciding: whether the generated known-bits registries can use auto(). They can only partly, because their bits are not a contiguous run from bit 0.

• HEData1Known starts at bit 2, since bits 0–1 hold the format value subfield.
• HEData2Known jumps from bit 7 to bit 14, past the value subfields in between.

IntFlag's auto() gives the next power of two after the previous member, so it lands on the wrong bit wherever a value subfield or reserved bit sits in between. It also types as Any, which reg/apptype already works around with a cast.

1. Keep explicit 1 << n in every generated registry.
2. Use auto() for contiguous runs, with an explicit value at the first member and after each gap.
3. Use auto() throughout, which would put bits in the wrong positions.

Recommendation: 1. Each line then states its radiotap.org bit, so the file reviews against the spec line by line. A dropped crawler row fails loudly instead of shifting every later bit, and it matches the #2576 registries. The PR stays at GOOD TO GO with 1 unless you pick otherwise.

[JarryShaw]

okay take 1

[JarryShaw]

The owner chose 1, paraphrased: the generated known-bits registries keep explicit 1 << n values, with no auto(). That is how this PR already does it, so nothing changes, and it stays GOOD TO GO. needs: decision comes off.