Page MenuHomeFreeBSD

net80211: fix VHT80/VHT160 transmit width checks
ClosedPublic

Authored by adrian on May 1 2025, 4:14 AM.
Referenced Files
Unknown Object (File)
Tue, Jul 8, 2:35 AM
Unknown Object (File)
Sun, Jul 6, 5:08 PM
Unknown Object (File)
Sun, Jul 6, 4:53 AM
Unknown Object (File)
Sat, Jul 5, 10:25 AM
Unknown Object (File)
Sat, Jul 5, 7:33 AM
Unknown Object (File)
Thu, Jul 3, 1:46 AM
Unknown Object (File)
Tue, Jul 1, 7:14 PM
Unknown Object (File)
Tue, Jul 1, 3:24 PM

Details

Summary

I didn't double check to see if ni_chw had been updated to actually
implement values other than 20/40. It's just implementing the
HT channel width stuff during both association and upon receiving
a HT TX channel width action frame.

This meant the VHT80/VHT160 transmit width checks were never
going to be true, as ni_chw is never set to VHT80 / VHT160.

After checking the HT action frame and looking for VHT changes,
I'm pretty sure there's nothing explicit about VHT width, as it's
normally done via CCA (clear channel access) and/or RTS/CTS exchanges -
each 20MHz subchannel is RTS/CTS'ed / will be checked and if they're
busy, a narrower frame will be transmitted.

So, change the VHT80 / VHT160 checks to only check if ni_chw is 20MHz.
If it's 20MHz then a HT action frame has come out saying to TX at 20MHz,
and we should obey it. Otherwise, do 80/160MHz as available.

Diff Detail

Repository
rG FreeBSD src repository
Lint
Lint Not Applicable
Unit
Tests Not Applicable

Event Timeline

adrian requested review of this revision.May 1 2025, 4:14 AM
bz added a subscriber: bz.

Too many (cached) values in net80211 representing something rather than a simple accessor function doing the thing right in one place.
I'll back out the IEEE80211_STA_RX_BW_* change as you are back to 20/40 only now to not be confusing once this is landed.

This revision is now accepted and ready to land.May 1 2025, 7:59 PM
In D50096#1143047, @bz wrote:

Too many (cached) values in net80211 representing something rather than a simple accessor function doing the thing right in one place.
I'll back out the IEEE80211_STA_RX_BW_* change as you are back to 20/40 only now to not be confusing once this is landed.

Let's hold off on that; I can add "create an accessor function" first and go update all the consumers of this thing. Then we can nuke it?

In D50096#1143047, @bz wrote:

Too many (cached) values in net80211 representing something rather than a simple accessor function doing the thing right in one place.
I'll back out the IEEE80211_STA_RX_BW_* change as you are back to 20/40 only now to not be confusing once this is landed.

Let's hold off on that; I can add "create an accessor function" first and go update all the consumers of this thing. Then we can nuke it?

No, because if it ships in 14.3-R it's baked into that branch. The accessor function won't make a difference here if you keep treating ni_chw pure HT.