Re: 5GHz AP RSSI measurement problem

[Paul Irofti]

On Wed, May 02, 2018 at 11:52:18AM +0200, Stefan Sperling wrote:
> On Wed, May 02, 2018 at 12:30:30PM +0300, Paul Irofti wrote:
> > On Mon, Apr 30, 2018 at 10:55:22AM +0200, Stefan Sperling wrote:
> > > + /*
> > > +  * During a scan on 5Ghz, prefer RSSI measured for probe
> > > +  * response frames. i.e. don't allow beacons to lower the
> > > +  * measured RSSI. Some 5GHz APs send beacons with much
> > > +  * less Tx power than they use for probe responses.
> > > +  */
> > > +  if (isprobe)
> > 
> > Properly indent the if clause here
> > 
> > > + ni->ni_rssi = rxi->rxi_rssi;
> > > + else if (ni->ni_rssi < rxi->rxi_rssi)
> > 
> > Can't this be an OR in the former if clause?
> 
> Yes it could.
> 
> > > + ni->ni_rssi = rxi->rxi_rssi;
> > > + } else
> > > + ni->ni_rssi = rxi->rxi_rssi;
> > 
> > And actually, can't all of this be turned into a single if clause? :)
> > Maybe I am reading this wrong, but aren't you setting everywhere
> > ni->ni_rssi to rxi->rxi_rssi?
> 
> No. I don't update ni_rssi if the frame is a beacon (isprobe == false)
> which reduces an already recorded rssi value.
> 
> > I am a bit confused why this did not work before (when you were setting
> > the value to rxi_rssi no matter what) and why this extra checking fixed
> > it.
> 
> It didn't always work before because a beacon is not a probe response.
> Both types of frames contain the same data but semantics are different:
> The AP sends beacons at a fixed interval, and a probe response only
> when it has received a probe request from us.
> Sending probe requests during a scan is also known as an "active scan"
> (client performs an active tranmission), as opposed to a "passive scan"
> which only listens for beacons (client makes no tranmission).
> 
> The issue observed is that this AP is sending beacons with a much
> lower amount of transmit power than probe responses.

Got it, thanks!

I tried to contract the if clauses,

   if (!(ic->ic_state == IEEE80211_S_SCAN &&
   IEEE80211_IS_CHAN_5GHZ(ni->ni_chan) &&
   (isprobe || ni->ni_rssi < rxi->rxi_rssi)))
ni->ni_rssi = rxi->rxi_rssi;

but I think what you have now is most readable.

OK pirofti@

Re: 5GHz AP RSSI measurement problem

[Stefan Sperling]

On Wed, May 02, 2018 at 12:30:30PM +0300, Paul Irofti wrote:
> On Mon, Apr 30, 2018 at 10:55:22AM +0200, Stefan Sperling wrote:
> > +   /*
> > +* During a scan on 5Ghz, prefer RSSI measured for probe
> > +* response frames. i.e. don't allow beacons to lower the
> > +* measured RSSI. Some 5GHz APs send beacons with much
> > +* less Tx power than they use for probe responses.
> > +*/
> > +if (isprobe)
> 
> Properly indent the if clause here
> 
> > +   ni->ni_rssi = rxi->rxi_rssi;
> > +   else if (ni->ni_rssi < rxi->rxi_rssi)
> 
> Can't this be an OR in the former if clause?

Yes it could.

> > +   ni->ni_rssi = rxi->rxi_rssi;
> > +   } else
> > +   ni->ni_rssi = rxi->rxi_rssi;
> 
> And actually, can't all of this be turned into a single if clause? :)
> Maybe I am reading this wrong, but aren't you setting everywhere
> ni->ni_rssi to rxi->rxi_rssi?

No. I don't update ni_rssi if the frame is a beacon (isprobe == false)
which reduces an already recorded rssi value.

> I am a bit confused why this did not work before (when you were setting
> the value to rxi_rssi no matter what) and why this extra checking fixed
> it.

It didn't always work before because a beacon is not a probe response.
Both types of frames contain the same data but semantics are different:
The AP sends beacons at a fixed interval, and a probe response only
when it has received a probe request from us.
Sending probe requests during a scan is also known as an "active scan"
(client performs an active tranmission), as opposed to a "passive scan"
which only listens for beacons (client makes no tranmission).

The issue observed is that this AP is sending beacons with a much
lower amount of transmit power than probe responses.

Re: 5GHz AP RSSI measurement problem

[Paul Irofti]

On Mon, Apr 30, 2018 at 10:55:22AM +0200, Stefan Sperling wrote:
> I've ran into what seems to be a fairly modern dual-band AP (issued
> by a French ISP). This AP camps on channel 112. This channel requires
> radar detection which may explain the behaviour described below.
> 
> The AP sends 5GHz beacons with a ridicously low RSSI while no client
> is connected, and OpenBSD prefers the 2GHz band...
> 
>   + b8:ee:0e:cb:b3:081   +58 54M   ess  privacy   rsn  "ESSID"
>   + b8:ee:0e:cb:b3:09  112+6 54M   ess  privacy   rsn  "ESSID"
> 
> ... unless we get lucky and the most recently measured RSSI is obtained
> from a probe response instead of a beacon:
> 
>   + b8:ee:0e:cb:b3:081   +58 54M   ess  privacy   rsn  "ESSID"
>   + b8:ee:0e:cb:b3:09  112   +61 54M   ess  privacy   rsn  "ESSID"
> 
> tcpdump confirms that beacons are received with a low RSSI of -10dBm
> as long as no other client is connected (nevermind that the positive
> dBm values shown here are bogus; that is a separate issue):
> 
> 10:18:59.773885 802.11 flags=0<>: beacon, timestamp 974393344059, interval 
> 100,
> caps=2421, ssid (ESSID), rates 6M* 
> 9M
> 12M* 18M 24M* 36M 48M 54M, ds (chan 112), tim 0x0003, country 'FR ',
> channel 36 limit 23dB, channel 40 limit 23dB, channel 44 limit 23dB, channel 
> 48
> limit 23dB, channel 52 limit 23dB, channel 56 limit 23dB, channel 60 limit
> 23dB, channel 64 limit 23dB, channel 100 limit 23dB, channel 104 limit 23dB,
> channel 108 limit 23dB, channel 112 limit 23dB, channel 116 limit 23dB, 
> channel
> 132 limit 23dB, channel 136 limit 23dB, channel 140 limit 23dB, power
> constraint 0dB,  noise -127dBm>
> 
> Whereas probe responses consistently arrive with much more promising
> RSSI values of about -60dBm:
> 
> 10:18:58.889338 802.11 flags=8: probe response, timestamp 974392459305,
> interval 100, caps=2421, ssid
> (ESSID), rates 6M* 9M 12M* 18M 24M* 36M 48M 54M, ds (chan 112), country 'FR ',
> channel 36 limit 23dB, channel 40 limit 23dB, channel 44 limit 23dB, channel 
> 48
> limit 23dB, channel 52 limit 23dB, channel 56 limit 23dB, channel 60 limit
> 23dB, channel 64 limit 23dB, channel 100 limit 23dB, channel 104 limit 23dB,
> channel 108 limit 23dB, channel 112 limit 23dB, channel 116 limit 23dB, 
> channel
> 132 limit 23dB, channel 136 limit 23dB, channel 140 limit 23dB, power
> constraint 0dB,  noise -127dBm>
> 
> I have no idea if and where the 802.11 standard describes this behaviour.
> Maybe there is a way to tell the real RSSI even from beacon frames?
> Does anyone know more about this?
> 
> Setting aside concerns about my lack of understanding of the underlying
> reason for this behaviour, the hack below is sufficient to make this AP
> show up as a strong contender in the candidate list and be preferred
> over 2GHz as it should be.
> 
> Should I commit this hack? I don't see any downsides.
> 
> Index: ieee80211_input.c
> ===
> RCS file: /cvs/src/sys/net80211/ieee80211_input.c,v
> retrieving revision 1.200
> diff -u -p -r1.200 ieee80211_input.c
> --- ieee80211_input.c 29 Apr 2018 12:11:48 -  1.200
> +++ ieee80211_input.c 30 Apr 2018 08:32:58 -
> @@ -1689,13 +1689,26 @@ ieee80211_recv_probe_resp(struct ieee802
>   memcpy(ni->ni_essid, [2], ssid[1]);
>   }
>   IEEE80211_ADDR_COPY(ni->ni_bssid, wh->i_addr3);
> - ni->ni_rssi = rxi->rxi_rssi;
> + /* XXX validate channel # */
> + ni->ni_chan = >ic_channels[chan];
> + if (ic->ic_state == IEEE80211_S_SCAN &&
> + IEEE80211_IS_CHAN_5GHZ(ni->ni_chan)) {
> + /*
> +  * During a scan on 5Ghz, prefer RSSI measured for probe
> +  * response frames. i.e. don't allow beacons to lower the
> +  * measured RSSI. Some 5GHz APs send beacons with much
> +  * less Tx power than they use for probe responses.
> +  */
> +  if (isprobe)

Properly indent the if clause here

> + ni->ni_rssi = rxi->rxi_rssi;
> + else if (ni->ni_rssi < rxi->rxi_rssi)

Can't this be an OR in the former if clause?

> + ni->ni_rssi = rxi->rxi_rssi;
> + } else
> + ni->ni_rssi = rxi->rxi_rssi;

And actually, can't all of this be turned into a single if clause? :)
Maybe I am reading this wrong, but aren't you setting everywhere
ni->ni_rssi to rxi->rxi_rssi?

I am a bit confused why this did not work before (when you were setting
the value to rxi_rssi no matter what) and why this extra checking fixed
it.

Maybe I need another cup of coffee to understand this...

>   ni->ni_rstamp = rxi->rxi_tstamp;
>   memcpy(ni->ni_tstamp, tstamp, sizeof(ni->ni_tstamp));
>   ni->ni_intval = bintval;
>   ni->ni_capinfo = capinfo;
> - /* XXX validate channel # */
> - ni->ni_chan = >ic_channels[chan];
>   ni->ni_erp = erp;

Re: 5GHz AP RSSI measurement problem

[Peter Hessler]

On 2018 Apr 30 (Mon) at 10:55:22 +0200 (+0200), Stefan Sperling wrote:
:Setting aside concerns about my lack of understanding of the underlying
:reason for this behaviour, the hack below is sufficient to make this AP
:show up as a strong contender in the candidate list and be preferred
:over 2GHz as it should be.
:
:Should I commit this hack? I don't see any downsides.
:

OK

:Index: ieee80211_input.c
:===
:RCS file: /cvs/src/sys/net80211/ieee80211_input.c,v
:retrieving revision 1.200
:diff -u -p -r1.200 ieee80211_input.c
:--- ieee80211_input.c  29 Apr 2018 12:11:48 -  1.200
:+++ ieee80211_input.c  30 Apr 2018 08:32:58 -
:@@ -1689,13 +1689,26 @@ ieee80211_recv_probe_resp(struct ieee802
:   memcpy(ni->ni_essid, [2], ssid[1]);
:   }
:   IEEE80211_ADDR_COPY(ni->ni_bssid, wh->i_addr3);
:-  ni->ni_rssi = rxi->rxi_rssi;
:+  /* XXX validate channel # */
:+  ni->ni_chan = >ic_channels[chan];
:+  if (ic->ic_state == IEEE80211_S_SCAN &&
:+  IEEE80211_IS_CHAN_5GHZ(ni->ni_chan)) {
:+  /*
:+   * During a scan on 5Ghz, prefer RSSI measured for probe
:+   * response frames. i.e. don't allow beacons to lower the
:+   * measured RSSI. Some 5GHz APs send beacons with much
:+   * less Tx power than they use for probe responses.
:+   */
:+   if (isprobe)
:+  ni->ni_rssi = rxi->rxi_rssi;
:+  else if (ni->ni_rssi < rxi->rxi_rssi)
:+  ni->ni_rssi = rxi->rxi_rssi;
:+  } else
:+  ni->ni_rssi = rxi->rxi_rssi;
:   ni->ni_rstamp = rxi->rxi_tstamp;
:   memcpy(ni->ni_tstamp, tstamp, sizeof(ni->ni_tstamp));
:   ni->ni_intval = bintval;
:   ni->ni_capinfo = capinfo;
:-  /* XXX validate channel # */
:-  ni->ni_chan = >ic_channels[chan];
:   ni->ni_erp = erp;
:   /* NB: must be after ni_chan is setup */
:   ieee80211_setup_rates(ic, ni, rates, xrates, IEEE80211_F_DOSORT);
:

-- 
I doubt, therefore I might be.

Re: 5GHz AP RSSI measurement problem

[Stefan Sperling]

On Tue, May 01, 2018 at 10:06:54PM -0500, Patrick Dohman wrote:
> I believe you are correct to correlate RSSI & probe response.
> My understanding is that 802.11 beacon is a management frame to synchronize 
> networks.
> Essentially the beacon interval determines the multiple for the DTIM & may 
> include additional capability frames.
> The beacon blinks at a configurable interval (100 MS) & establishes a 
> countdown for broadcast eligibility.
> In some implementations the reception of blinks may indicate congestion or 
> interference & perhaps infer signal strength. 
> Regards
> Patrick

Thank you for your feedback! I am also quite confident
that this is the right thing to do.
I am still waiting for an OK from another developer before
I'll commit the change.

Re: 5GHz AP RSSI measurement problem

[Patrick Dohman]

I believe you are correct to correlate RSSI & probe response.
My understanding is that 802.11 beacon is a management frame to synchronize 
networks.
Essentially the beacon interval determines the multiple for the DTIM & may 
include additional capability frames.
The beacon blinks at a configurable interval (100 MS) & establishes a countdown 
for broadcast eligibility.
In some implementations the reception of blinks may indicate congestion or 
interference & perhaps infer signal strength. 
Regards
Patrick

> On Apr 30, 2018, at 3:55 AM, Stefan Sperling  wrote:
> 
> I've ran into what seems to be a fairly modern dual-band AP (issued
> by a French ISP). This AP camps on channel 112. This channel requires
> radar detection which may explain the behaviour described below.
> 
> The AP sends 5GHz beacons with a ridicously low RSSI while no client
> is connected, and OpenBSD prefers the 2GHz band...
> 
>  + b8:ee:0e:cb:b3:081   +58 54M   ess  privacy   rsn  "ESSID"
>  + b8:ee:0e:cb:b3:09  112+6 54M   ess  privacy   rsn  "ESSID"
> 
> ... unless we get lucky and the most recently measured RSSI is obtained
> from a probe response instead of a beacon:
> 
>  + b8:ee:0e:cb:b3:081   +58 54M   ess  privacy   rsn  "ESSID"
>  + b8:ee:0e:cb:b3:09  112   +61 54M   ess  privacy   rsn  "ESSID"
> 
> tcpdump confirms that beacons are received with a low RSSI of -10dBm
> as long as no other client is connected (nevermind that the positive
> dBm values shown here are bogus; that is a separate issue):
> 
> 10:18:59.773885 802.11 flags=0<>: beacon, timestamp 974393344059, interval 
> 100,
> caps=2421, ssid (ESSID), rates 6M* 
> 9M
> 12M* 18M 24M* 36M 48M 54M, ds (chan 112), tim 0x0003, country 'FR ',
> channel 36 limit 23dB, channel 40 limit 23dB, channel 44 limit 23dB, channel 
> 48
> limit 23dB, channel 52 limit 23dB, channel 56 limit 23dB, channel 60 limit
> 23dB, channel 64 limit 23dB, channel 100 limit 23dB, channel 104 limit 23dB,
> channel 108 limit 23dB, channel 112 limit 23dB, channel 116 limit 23dB, 
> channel
> 132 limit 23dB, channel 136 limit 23dB, channel 140 limit 23dB, power
> constraint 0dB,  noise -127dBm>
> 
> Whereas probe responses consistently arrive with much more promising
> RSSI values of about -60dBm:
> 
> 10:18:58.889338 802.11 flags=8: probe response, timestamp 974392459305,
> interval 100, caps=2421, ssid
> (ESSID), rates 6M* 9M 12M* 18M 24M* 36M 48M 54M, ds (chan 112), country 'FR ',
> channel 36 limit 23dB, channel 40 limit 23dB, channel 44 limit 23dB, channel 
> 48
> limit 23dB, channel 52 limit 23dB, channel 56 limit 23dB, channel 60 limit
> 23dB, channel 64 limit 23dB, channel 100 limit 23dB, channel 104 limit 23dB,
> channel 108 limit 23dB, channel 112 limit 23dB, channel 116 limit 23dB, 
> channel
> 132 limit 23dB, channel 136 limit 23dB, channel 140 limit 23dB, power
> constraint 0dB,  noise -127dBm>
> 
> I have no idea if and where the 802.11 standard describes this behaviour.
> Maybe there is a way to tell the real RSSI even from beacon frames?
> Does anyone know more about this?
> 
> Setting aside concerns about my lack of understanding of the underlying
> reason for this behaviour, the hack below is sufficient to make this AP
> show up as a strong contender in the candidate list and be preferred
> over 2GHz as it should be.
> 
> Should I commit this hack? I don't see any downsides.
> 
> Index: ieee80211_input.c
> ===
> RCS file: /cvs/src/sys/net80211/ieee80211_input.c,v
> retrieving revision 1.200
> diff -u -p -r1.200 ieee80211_input.c
> --- ieee80211_input.c 29 Apr 2018 12:11:48 -  1.200
> +++ ieee80211_input.c 30 Apr 2018 08:32:58 -
> @@ -1689,13 +1689,26 @@ ieee80211_recv_probe_resp(struct ieee802
>   memcpy(ni->ni_essid, [2], ssid[1]);
>   }
>   IEEE80211_ADDR_COPY(ni->ni_bssid, wh->i_addr3);
> - ni->ni_rssi = rxi->rxi_rssi;
> + /* XXX validate channel # */
> + ni->ni_chan = >ic_channels[chan];
> + if (ic->ic_state == IEEE80211_S_SCAN &&
> + IEEE80211_IS_CHAN_5GHZ(ni->ni_chan)) {
> + /*
> +  * During a scan on 5Ghz, prefer RSSI measured for probe
> +  * response frames. i.e. don't allow beacons to lower the
> +  * measured RSSI. Some 5GHz APs send beacons with much
> +  * less Tx power than they use for probe responses.
> +  */
> +  if (isprobe)
> + ni->ni_rssi = rxi->rxi_rssi;
> + else if (ni->ni_rssi < rxi->rxi_rssi)
> + ni->ni_rssi = rxi->rxi_rssi;
> + } else
> + ni->ni_rssi = rxi->rxi_rssi;
>   ni->ni_rstamp = rxi->rxi_tstamp;
>   memcpy(ni->ni_tstamp, tstamp, sizeof(ni->ni_tstamp));
>   ni->ni_intval = bintval;
>   ni->ni_capinfo = capinfo;
> - /* XXX validate channel # */
> - 

Re: 5GHz AP RSSI measurement problem

[Stefan Sperling]

On Tue, May 01, 2018 at 10:22:22AM +0100, Stuart Henderson wrote:
> On 2018/05/01 10:48, Stefan Sperling wrote:
> > > On 2018/04/30 11:08, Stefan Sperling wrote:
> > > > Derp. A dBm value of -10 would of course be better than -60.
> > > > 
> > > > Whatever the numbers shown by tcpdump really mean, the probe response's
> > > > one is better!!!
> > > 
> > > Better as in "more accurate". But as the reported value is ridiculously
> > > high rather than too low, why wasn't 5GHz selected anyway?
> > 
> > What I wrote in my first mail was not very clear (I wrote it in
> > a hurry before leaving to catch a train).
> > 
> > The kernel compares the RSSI values which are shown in debug output.
> > For reference, the scan debug printfs below again show a 2GHz beacon
> > vs.  a 5GHz "low power" beacon, where measured RSSI on 2Ghz is represented
> > as "58" and on 5Ghz is represented as "6":
> > 
> >   + b8:ee:0e:cb:b3:081   +58 54M   ess  privacy   rsn  "ESSID"
> >   + b8:ee:0e:cb:b3:09  112+6 54M   ess  privacy   rsn  "ESSID"
> > 
> > The "non-reduced" Tx power frames, i.e. probe responses or beacons while
> > a client is associated, closely matched Tx power seen on 2GHz:
> > 
> >   + b8:ee:0e:cb:b3:081   +58 54M   ess  privacy   rsn  "ESSID"
> >   + b8:ee:0e:cb:b3:09  112   +61 54M   ess  privacy   rsn  "ESSID"
> 
> What do the values represent here?
>
> I've been reading them as sign-flipped dBm signal strength because
> (before the +6 outlier) the numbers all matched that (i.e. -61dBm for
> 5GHz and -58dBm for 2GHz looks right for an access point at typical
> power levels about 30m away).

I've done some quick digging:

The values come from iwm(4). Which means they are derived as dBm from
values reported by hardware and then converted into a percentage.
See iwm_calc_rssi() and its caller iwm_rx_rx_mpdu().

I've been wondering if we should make iwm(4) report values in dBm instead
of as a percentage. But a percentage may be more intuitive to users.
I'll leave this as it is -- since pirofti@ told me he might be working
on fixing the RSSI situation I'd rather leave such decisions to him.

> I didn't interpret them as % in this case because it would be unusual
> for the 5GHz signal to be stronger than the 2GHz though that is
> possible and if that's the case, your diff makes sense.

It seems % would be the correct interpretation.

I was sitting right next to the AP and I'm not surprised that
both bands show similar values at such close range.

Re: 5GHz AP RSSI measurement problem

[Stuart Henderson]

On 2018/05/01 10:48, Stefan Sperling wrote:
> > On 2018/04/30 11:08, Stefan Sperling wrote:
> > > Derp. A dBm value of -10 would of course be better than -60.
> > > 
> > > Whatever the numbers shown by tcpdump really mean, the probe response's
> > > one is better!!!
> > 
> > Better as in "more accurate". But as the reported value is ridiculously
> > high rather than too low, why wasn't 5GHz selected anyway?
> 
> What I wrote in my first mail was not very clear (I wrote it in
> a hurry before leaving to catch a train).
> 
> The kernel compares the RSSI values which are shown in debug output.
> For reference, the scan debug printfs below again show a 2GHz beacon
> vs.  a 5GHz "low power" beacon, where measured RSSI on 2Ghz is represented
> as "58" and on 5Ghz is represented as "6":
> 
>   + b8:ee:0e:cb:b3:081   +58 54M   ess  privacy   rsn  "ESSID"
>   + b8:ee:0e:cb:b3:09  112+6 54M   ess  privacy   rsn  "ESSID"
> 
> The "non-reduced" Tx power frames, i.e. probe responses or beacons while
> a client is associated, closely matched Tx power seen on 2GHz:
> 
>   + b8:ee:0e:cb:b3:081   +58 54M   ess  privacy   rsn  "ESSID"
>   + b8:ee:0e:cb:b3:09  112   +61 54M   ess  privacy   rsn  "ESSID"

What do the values represent here?

I've been reading them as sign-flipped dBm signal strength because
(before the +6 outlier) the numbers all matched that (i.e. -61dBm for
5GHz and -58dBm for 2GHz looks right for an access point at typical
power levels about 30m away).

I didn't interpret them as % in this case because it would be unusual
for the 5GHz signal to be stronger than the 2GHz though that is
possible and if that's the case, your diff makes sense.


> There is a huge amount of material in the 802.11 specs about tx power
> management and spectrum management but I haven't read any of that.

And even then more reading is needed to understand it all, the
specs just provide the framework for implementation, but the actual
requirements are in local regulations which aren't in the specs.
But fortunately for us (at least in client mode ;) this is mostly
AP-led.

Re: 5GHz AP RSSI measurement problem

[Stefan Sperling]

On Mon, Apr 30, 2018 at 01:35:59PM +0100, Stuart Henderson wrote:
> On 2018/04/30 10:55, Stefan Sperling wrote:
> > The AP sends 5GHz beacons with a ridicously low RSSI while no client
> > is connected, and OpenBSD prefers the 2GHz band...
> 
> Surely it has to be the receiver that is adding the RSSI infornation?
> The AP can't know.

Indeed. What I meant is that this AP seems to send 5Ghz beacons
with reduced Tx power for some reason.

> Seems it would either have to be the client side measuring incorrectly,
> or the AP is really sending beacons at low power. If the latter, that
> _could_ be a mechanism to reduce power consumption in idle mode...
> Let them connect at 2GHz then whack up the power and steer them towards
> 5GHz after association...

Yes, something like that seems to be happening.
It could also be related to radar since low power beacons would carry
less risk of causing interference with radar on channel 112.

There is a huge amount of material in the 802.11 specs about tx power
management and spectrum management but I haven't read any of that.

> Anyway it would be interesting to see how a spectrum analyser looks with
> this access point :)

For all intents and purposes, trusting the RSSI reported by Intel
hardware seems good enough to me :)

> On 2018/04/30 11:08, Stefan Sperling wrote:
> > Derp. A dBm value of -10 would of course be better than -60.
> > 
> > Whatever the numbers shown by tcpdump really mean, the probe response's
> > one is better!!!
> 
> Better as in "more accurate". But as the reported value is ridiculously
> high rather than too low, why wasn't 5GHz selected anyway?

What I wrote in my first mail was not very clear (I wrote it in
a hurry before leaving to catch a train).

The kernel compares the RSSI values which are shown in debug output.
For reference, the scan debug printfs below again show a 2GHz beacon
vs.  a 5GHz "low power" beacon, where measured RSSI on 2Ghz is represented
as "58" and on 5Ghz is represented as "6":

  + b8:ee:0e:cb:b3:081   +58 54M   ess  privacy   rsn  "ESSID"
  + b8:ee:0e:cb:b3:09  112+6 54M   ess  privacy   rsn  "ESSID"

The "non-reduced" Tx power frames, i.e. probe responses or beacons while
a client is associated, closely matched Tx power seen on 2GHz:

  + b8:ee:0e:cb:b3:081   +58 54M   ess  privacy   rsn  "ESSID"
  + b8:ee:0e:cb:b3:09  112   +61 54M   ess  privacy   rsn  "ESSID"

In the above cases, the RSSI value comparisons which happened in the
kernel were 6 < 58 without my diff and 61 < 58 with my diff.

We never pick the 5GHz AP in the former situation. Of course, there
is a race: We would pick the 5GHz AP if its node record was created
due to a probe response and no subsequent beacon had reset ni_rssi
to a low value before we choose an AP. This occasionally happened
in my observations but most of the time we picked the 2GHz AP.

In my first mail, values I've quoted from scan debug output and
values I've shown from tcpdump were derived from different frames.
Debug output for those frames captured by tcpdump would have been
10 and 60 rather than 6 and 61, I suppose.

Re: 5GHz AP RSSI measurement problem

[Stuart Henderson]

On 2018/04/30 10:55, Stefan Sperling wrote:
> The AP sends 5GHz beacons with a ridicously low RSSI while no client
> is connected, and OpenBSD prefers the 2GHz band...

Surely it has to be the receiver that is adding the RSSI infornation?
The AP can't know.

Seems it would either have to be the client side measuring incorrectly,
or the AP is really sending beacons at low power. If the latter, that
_could_ be a mechanism to reduce power consumption in idle mode...
Let them connect at 2GHz then whack up the power and steer them towards
5GHz after association...

Anyway it would be interesting to see how a spectrum analyser looks with
this access point :)

On 2018/04/30 11:08, Stefan Sperling wrote:
> Derp. A dBm value of -10 would of course be better than -60.
> 
> Whatever the numbers shown by tcpdump really mean, the probe response's
> one is better!!!

Better as in "more accurate". But as the reported value is ridiculously
high rather than too low, why wasn't 5GHz selected anyway?

> (We really should make processing of RSSI values consistent across the
> entire the system...)

ack.

Re: 5GHz AP RSSI measurement problem

[Stefan Sperling]

On Mon, Apr 30, 2018 at 10:55:22AM +0200, Stefan Sperling wrote:
> tcpdump confirms that beacons are received with a low RSSI of -10dBm

> Whereas probe responses consistently arrive with much more promising
> RSSI values of about -60dBm:

Derp. A dBm value of -10 would of course be better than -60.

Whatever the numbers shown by tcpdump really mean, the probe response's
one is better!!!

(We really should make processing of RSSI values consistent across the
entire the system...)

5GHz AP RSSI measurement problem

[Stefan Sperling]

I've ran into what seems to be a fairly modern dual-band AP (issued
by a French ISP). This AP camps on channel 112. This channel requires
radar detection which may explain the behaviour described below.

The AP sends 5GHz beacons with a ridicously low RSSI while no client
is connected, and OpenBSD prefers the 2GHz band...

  + b8:ee:0e:cb:b3:081   +58 54M   ess  privacy   rsn  "ESSID"
  + b8:ee:0e:cb:b3:09  112+6 54M   ess  privacy   rsn  "ESSID"

... unless we get lucky and the most recently measured RSSI is obtained
from a probe response instead of a beacon:

  + b8:ee:0e:cb:b3:081   +58 54M   ess  privacy   rsn  "ESSID"
  + b8:ee:0e:cb:b3:09  112   +61 54M   ess  privacy   rsn  "ESSID"

tcpdump confirms that beacons are received with a low RSSI of -10dBm
as long as no other client is connected (nevermind that the positive
dBm values shown here are bogus; that is a separate issue):

10:18:59.773885 802.11 flags=0<>: beacon, timestamp 974393344059, interval 100,
caps=2421, ssid (ESSID), rates 6M* 9M
12M* 18M 24M* 36M 48M 54M, ds (chan 112), tim 0x0003, country 'FR ',
channel 36 limit 23dB, channel 40 limit 23dB, channel 44 limit 23dB, channel 48
limit 23dB, channel 52 limit 23dB, channel 56 limit 23dB, channel 60 limit
23dB, channel 64 limit 23dB, channel 100 limit 23dB, channel 104 limit 23dB,
channel 108 limit 23dB, channel 112 limit 23dB, channel 116 limit 23dB, channel
132 limit 23dB, channel 136 limit 23dB, channel 140 limit 23dB, power
constraint 0dB, 

Whereas probe responses consistently arrive with much more promising
RSSI values of about -60dBm:

10:18:58.889338 802.11 flags=8: probe response, timestamp 974392459305,
interval 100, caps=2421, ssid
(ESSID), rates 6M* 9M 12M* 18M 24M* 36M 48M 54M, ds (chan 112), country 'FR ',
channel 36 limit 23dB, channel 40 limit 23dB, channel 44 limit 23dB, channel 48
limit 23dB, channel 52 limit 23dB, channel 56 limit 23dB, channel 60 limit
23dB, channel 64 limit 23dB, channel 100 limit 23dB, channel 104 limit 23dB,
channel 108 limit 23dB, channel 112 limit 23dB, channel 116 limit 23dB, channel
132 limit 23dB, channel 136 limit 23dB, channel 140 limit 23dB, power
constraint 0dB, 

I have no idea if and where the 802.11 standard describes this behaviour.
Maybe there is a way to tell the real RSSI even from beacon frames?
Does anyone know more about this?

Setting aside concerns about my lack of understanding of the underlying
reason for this behaviour, the hack below is sufficient to make this AP
show up as a strong contender in the candidate list and be preferred
over 2GHz as it should be.

Should I commit this hack? I don't see any downsides.

Index: ieee80211_input.c
===
RCS file: /cvs/src/sys/net80211/ieee80211_input.c,v
retrieving revision 1.200
diff -u -p -r1.200 ieee80211_input.c
--- ieee80211_input.c   29 Apr 2018 12:11:48 -  1.200
+++ ieee80211_input.c   30 Apr 2018 08:32:58 -
@@ -1689,13 +1689,26 @@ ieee80211_recv_probe_resp(struct ieee802
memcpy(ni->ni_essid, [2], ssid[1]);
}
IEEE80211_ADDR_COPY(ni->ni_bssid, wh->i_addr3);
-   ni->ni_rssi = rxi->rxi_rssi;
+   /* XXX validate channel # */
+   ni->ni_chan = >ic_channels[chan];
+   if (ic->ic_state == IEEE80211_S_SCAN &&
+   IEEE80211_IS_CHAN_5GHZ(ni->ni_chan)) {
+   /*
+* During a scan on 5Ghz, prefer RSSI measured for probe
+* response frames. i.e. don't allow beacons to lower the
+* measured RSSI. Some 5GHz APs send beacons with much
+* less Tx power than they use for probe responses.
+*/
+if (isprobe)
+   ni->ni_rssi = rxi->rxi_rssi;
+   else if (ni->ni_rssi < rxi->rxi_rssi)
+   ni->ni_rssi = rxi->rxi_rssi;
+   } else
+   ni->ni_rssi = rxi->rxi_rssi;
ni->ni_rstamp = rxi->rxi_tstamp;
memcpy(ni->ni_tstamp, tstamp, sizeof(ni->ni_tstamp));
ni->ni_intval = bintval;
ni->ni_capinfo = capinfo;
-   /* XXX validate channel # */
-   ni->ni_chan = >ic_channels[chan];
ni->ni_erp = erp;
/* NB: must be after ni_chan is setup */
ieee80211_setup_rates(ic, ni, rates, xrates, IEEE80211_F_DOSORT);