IEEE 802.11: add HT capability and PHY foundations - #1167
Merged
levy merged 6 commits intoSep 8, 2026
Conversation
![devin-ai-integration[bot]](https://avatars.githubusercontent.com/in/811515?s=60&v=4){kind=small}
There was a problem hiding this comment.
Devin Review found 1 potential issue.
1 flag not posted on this PR by your GitHub settings — view it in Devin Review. (Configure)
Comment on lines
+47
to
+50
| int primaryChannel = htOperation.primaryChannel; | ||
| localHtCapabilities = Ieee80211HtCapabilities(); | ||
| htOperation = Ieee80211HtOperation(); | ||
| htOperation.primaryChannel = primaryChannel; |
There was a problem hiding this comment.
🟡 HT operation keeps wrong channel
When an HT radio uses any channel beyond index zero, updateLocalHtCapabilities preserves zero. No channel update writes htOperation.primaryChannel, so operation state identifies the wrong channel.
Prompt for agents
Track the radio's current IEEE 802.11 channel in Ieee80211Mib::htOperation.primaryChannel. Initialize it before updateLocalHtCapabilities runs and update it whenever the radio channel changes. Keep the value as the internal channel index expected by makeHtOperationElement, and add a focused test covering a nonzero initial channel plus a later channel change.
Was this helpful? React with 👍 or 👎 to provide feedback.
mgonzalezlopezudc
force-pushed
the
pr/ht-01-foundations
branch
from
September 8, 2026 15:54
f01af19 to
cce1050
Compare
Keep the header ending consistent without mixing whitespace-only changes with the operational capability API.
Internal channel indices differ from standards channel numbers in the 2.4 GHz band. Explicit mappings allow HT operation fields to use standards channel numbers and validate HT40 pairs by center-frequency separation. Keep reusable mapping behavior in Ieee80211BandBase and synchronize the transmitter and receiver band when their channel changes. Direct band interface subclasses must implement the new contract or inherit the base.
Capability consumers need exact HT MCS, width and guard-interval support from typed mode entries, without inferring dense MCS sets or treating VHT modes as HT modes. Preserve the explicit PHY timing reference. Expose concrete transmitter and receiver width queries so callers can intersect catalog support with the packet PHY's primary-channel limit.
Rate selection can only choose modes present in the catalog. Include all modeled MCS 0..31 combinations for 20/40 MHz and long/short guard intervals in the mixed HT set while preserving mandatory-mode membership.
HT advertisements need distinct capability, operation and directional peer constraints. Represent these values and validate contradictory fields before converting them into usable peer state. Encode the modeled HT Capabilities and HT Operation fields according to IEEE 802.11 sections 9.4.2.54 and 9.4.2.55, preserving subtype-specific Basic HT-MCS presence. Print sparse MCS sets without implying dense support.
A catalog-wide advertisement can claim channel widths or spatial streams that the configured radio cannot operate. Derive local capabilities at MAC initialization from the transmitter/receiver width intersection and antenna stream limit, and retain the resulting local and directional peer state in the MIB. Validate operation parameters against this bounded capability set before management can publish it.
mgonzalezlopezudc
force-pushed
the
pr/ht-01-foundations
branch
from
September 8, 2026 17:36
f90774a to
3bc290d
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
IEEE 802.11 HT capability and PHY foundations
Mixed HT operation needs an explicit PHY timing reference, an encodable legacy rate set, and capabilities bounded by the configured radio. Establish the typed HT capability/operation model, element codec, channel mappings, complete mode catalog, and operational width/antenna limits. Small queue and serializer prerequisites remain separate commits at the start.
Stack and reading order
PR 1/4. Head:
pr/ht-01-foundations. Target:master. Prepared range:7aef79d5c0db..f01af194a8cb. Read the following commits in order:4a4c5fe3c0d2— ieee80211: normalize existing blank lines77c4134e1eb6— tests: verify management timestamps across time resolutions8a7b7061082e— queueing: mark the streaming API section public0ca43c03af02— queueing: retain compound packets during drop notificationc340206ef9c6— ieee80211: make PHY timing references explicit119a4cf77664— ieee80211: encode the legacy operational rate set correctly2f7262f82bd5— physicallayer/ieee80211: expose standards channel mappings656deae2bfe7— ieee80211: model validated HT capabilities and operation788222ea7bec— physicallayer/ieee80211: complete the mixed HT mode catalogf01af194a8cb— ieee80211: bound local HT capabilities by the operational PHYArchitectural surface
PHY timing/mode/channel contracts, HT management element representation and codec, MIB local capabilities, and generic queue ownership. No sealed packet-core paths are changed.
Baselines
C05 carries seven timing-related fingerprint transitions; C06 carries thirty rate-advertisement transitions. These touch examples.csv, showcases.csv, and tutorials.csv under tests/fingerprint. No baseline regeneration was performed during reconstruction.
Verification
Each of C01–C10 has a passing debug build and scoped opp_repl evidence. C05/C06 also passed their 7/30 fingerprint cases. The C10 initialization probe verified 20 MHz and one-stream bounds. This is per-commit evidence, not a separate full-suite run at this PR tip.
The full-stack recorded build command was
make MODE=debug -j$(nproc). The scoped unit/module/queueing runs usedopp_repl --load @opp -p inet, with exactrun_opp_testscalls in the retained.final.tests.pyexecution artifact. Fingerprints usedfingerprinttest -d -q -f tplx -f "~tNl" -f "~tND"with the retained explicit 37-row CSV. Exact commands, selectors, statuses, and source-tree mappings are in the accompanying execution report.