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...</wild speculation> 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:08 1 +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:08 1 +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.
