From: Stefan Sperling <stsp@stsp.name>
Subject: Re: sys/qwx,sys/qwz: report RSSI as percentage
To: marcus@nazgul.ch, tech@openbsd.org
Date: Thu, 21 May 2026 23:05:40 +0200

On Thu, May 21, 2026 at 10:35:13PM +0200, Kirill A. Korinsky wrote:
> On Thu, 21 May 2026 22:31:03 +0200,
> Stefan Sperling <stsp@stsp.name> wrote:
> > 
> > On Thu, May 21, 2026 at 10:19:49PM +0200, Marcus Glocker wrote:
> > > On Wed, May 20, 2026 at 01:02:13AM +0200, Kirill A. Korinsky wrote:
> > > 
> > > > tech@,
> > > > 
> > > > I think that Report RSSI as percentage, it is more user friendly than dBm.
> > > > 
> > > > So, here I've used the same conversion logic as iwx for both qwz and qwx.
> > > > 
> > > > Ok?
> > > 
> > > I prefer the % display as well, and the diff works fine with my qwz.
> > > So basically ok mglocker@, but maybe it would be good to have stsp@'s
> > > feedback as well before we go ahead committing it.
> > 
> > What is most important here is that the values reported to the stack
> > make sense relative to the background scan / roaming thresholds:
> > 
> > #define IEEE80211_RSSI_THRES_2GHZ		(-60)	/* in dBm */
> > #define IEEE80211_RSSI_THRES_5GHZ		(-70)	/* in dBm */
> > #define IEEE80211_RSSI_THRES_RATIO_2GHZ		60	/* in percent */
> > #define IEEE80211_RSSI_THRES_RATIO_5GHZ		50	/* in percent */
> > 
> > Do you have multiple APs that share an SSID to test roaming with?
> >
> 
> Yes, I do, that you would like to test?

My main point is that this change isn't just cosmetic. The change
could have a real impact on roaming behavior and some attention
to that fact is warranted. At least confirming that roaming still
works as expected would be good.

> > > >  /* Antenna noise floor */
> > > >  #define ATH11K_DEFAULT_NOISE_FLOOR -95
> > > > +#define QWX_MIN_DBM	-100
> > > > +#define QWX_MAX_DBM	-33	/* realistic guess */
> > 
> > Is this really just a guess? Or did you get this number from somewhere?
> >
> > I don't think this number is unreasonable (the theoretical max was -20dBm
> > if I recall correctly?) But we should be sure that the range makes sense
> > for this device, which may behave differently to the Intel ones since
> > RSSI is a vendor-specific heuristic. If we now end up always reporting
> > 50% or less then we would constantly be trying to roam. And if we never
> > fall below 50% anymore then we will never try to roam. If we're somewhere
> > between those two extremes that's ok and we can keep tweaking it if needed.
> 
> This numbers came from iwx with exact comment :-)

So -33 maximum should be correct for what Intel devices are reporting.
I believe we unfortunately cannot rely on RSSI reported by other
vendor's devices to use the same range.

If no documented range can be found for these devices, one way might be
to print the values while doing range tests against several APs (since
AP TX power will also affect this, trying multiple APs would be good).
Then pick a maximum based on observed values.

Or just pick a number, and pay some attention to how it works out
with roaming in practice. Roaming cannot be implemented perfectly
for everyone at all times anyway because real conditions vary.