[WIP] net80211: use uint16_t for rssi
AcceptedPublic
Actions

Authored by bz on Jun 19 2025, 1:19 AM.

Details

Reviewers

Summary

net80211 keeps the rssi value in 0.5bm relative to the noise floor
internally (see comment in ieee80211_node.h). While in many places
there was an 'int' as function argument to pass the internal rssi
value, in other places including structs we used int8_t.

The problem with int8_t is:
assume a noise floor "nf" of -127, assume a signal level of -21,
and then do the net80211 internal maths:

int8_t rssi8 = -21; => nf -127 rssi -21
rssi8 -= -127; => nf -127 rssi 106
rssi8 *= 2; => nf -127 rssi -44

Now doing the reverse (rssi / 2) + nf: (-44 / 2) + -127
will depending on how you print it give 107 or -149 and neither
is -21. The problem is that we have a double wrap-around.

Use int16_t instead for the entire storage which will do the
right thing avoiding any double-wrap-arounds:
nf -127 rssi -21
nf -127 rssi 106
nf -127 rssi 212, which results in S:N -21:-127
as 212 / 2 = 106 + -127 = -21.

I have separate patches for iwx(4) and linuxkpi_wlan(4) as those
triggered me looking into this while looking at scan results.
And for the first time ifconfig would give me meaningful values.

TODO: given this breaks the user space reporting need to resort
the struct layouts as well as they are no longer dword packed.
TODO: should we have an internal type defined for rssi05?

Sponsored by: The FreeBSD Foundation
MFC after: 3 days
Fixes: ??? (was not correct for user space in ages/ever?)

Test Plan

See when to finish the TODOs and get it in before 15.0.
Someone see if my maths are to simple and I got it wrong?

Diff Detail

Repository

rG FreeBSD src repository

Lint

Lint Passed

Unit

No Test Coverage

Build Status

Buildable 64970
Build 61853: arc lint + arc unit

Event Timeline

bz created this revision.Jun 19 2025, 1:19 AM

Herald added subscribers: glebius, melifaro, imp. · View Herald TranscriptJun 19 2025, 1:19 AM

bz requested review of this revision.Jun 19 2025, 1:19 AM

Harbormaster completed remote builds in B64970: Diff 157292.Jun 19 2025, 1:20 AM

bz added a child revision: D50929: iwx: correct rssi calculations and reporting.Jun 19 2025, 1:21 AM

bz mentioned this in D50929: iwx: correct rssi calculations and reporting.

bz mentioned this in D50930: bsnmp: wlan: use correct value for rssi.Jul 28 2025, 9:14 PM

emaste added a subscriber: emaste.Jul 30 2025, 10:55 PM

emaste added inline comments.

sys/net80211/_ieee80211.h
428	Do we want to adjust this one now, rather than introducing a struct hole?

bz added inline comments.Jul 31 2025, 1:17 AM

sys/net80211/_ieee80211.h
428	By "now" you mean re-sort or before 15?

I think it's ok to migrate it to int16_t. I'd migrate it to something like an net80211_rssi_t or something that we can handle opaquely, especially if we wanted to change its definition later.
(There's a lot of crazy places where it's just misused, as you've seen!)

adrian accepted this revision.Jul 31 2025, 5:08 AM

This revision is now accepted and ready to land.Jul 31 2025, 5:08 AM

emaste added inline comments.Aug 28 2025, 1:53 AM

sys/net80211/_ieee80211.h
428	As part of this change I mean

bz added inline comments.Aug 28 2025, 8:11 AM

sys/net80211/_ieee80211.h
428	I am still contemplating (a) if we can do this change without breakage or at least with outlook for the future; (b) allmost the other structs have gaps as well and a similar fate which I'd love to close if I get (a) sorted.

If you're worried about the ioctl change then let's do everything except the ioctl changes to begin with, and go fix all the divers and churn net80211's stuff a whole bunch first.

When doing some stuff with iwx last night I actually started thinking about whether we want to have some net80211 helper functions to set rssi and noise floor in the rx status and scan results paths, stuff like:

net80211_nf_set_default(&rxs) - set a default noise floor value based on the channel width and frequency (which would need to be set in rxs first)
net80211_nf_set_nf_rssi(&rxs, rssi, nf, flags) - set an RSSI and nf based on units in flags (ie, the flags define whether we're passing in 1dB, 1/2dB, etc RSSI and NF units)
net80211_nf_set_signal_rssi(&rxs, sig, nf, flags) - set a signal strength and nf based on units in flags (ie, the flags define as above)

.. and then the math is done in those routines for the conversions between things.

That way then we can do a huge big pass through all the drivers to explicitly set the above, and then we can put warnings on the input side if a driver hasn't called at least one set of the correct functions above to set the nf/rssi/signal parameters appropriately.

In D50928#1228077, @adrian wrote:

If you're worried about the ioctl change then let's do everything except the ioctl changes to begin with, and go fix all the divers and churn net80211's stuff a whole bunch first.

Yes happily if we can sort out questions of type etc.; and we really need to be able to track up-to 16 singal values in paralllel now already; I wouldn't be surprised if it'll double again the next years....

Before thinking about KPIs...

Q: for which chipsets/drivers do we actually know a NF value (which is not made up)?

Q: do we for ANY driver have receive sensitivity thresholds depending on data rate?

Q: for what does net80211 actually need the NF (apart from possibly reporting it) rather than just proper signal values?

Q: do we have an overview of all the (older) drivers as to what they report? Can someone write up a table somewhere (ASCII, Wiki, ..)?