I'm trying to understand the intent behind the DAWN hearing map.
I've successfully installed DAWN on several routers ( 2022-01-17-7a726740-1 ) and I've been able to confirm that 802.11v neighbour reports work as expected. The "neighbour map" feature (both via luci and via ubus call dawn get_network) also seems to work as expected.
However, I don't understand the "hearing map" feature (neither via luci nor via ubus call dawn get_hearing_map). At a high-level, my impression is that this data would allow the APs to "nudge" clients over to better APs. However, when I query the data I typically see a hearing map showing just the clients and the AP they are already attached to. I don't understand how the hearing map will be able to "nudge" clients to a better AP if there is no information on how well the client can see other APs.
So for example, I might see:
{
"MySSID": {
"33:33:33:33:33:33": {
"11:11:11:11:11:5F": {
"signal": -42,
"rcpi": 224,
"rsni": 0,
"freq": 5500,
"ht_capabilities": true,
"vht_capabilities": true,
"channel_utilization": 3,
"num_sta": 2,
"ht_support": true,
"vht_support": true,
"score": 181
}
}
}
}
It does seem that many of my devices support RRM (802.11k Radio Resource Management). I do see dawn actively sending beacon requests in the system log. For example, I see:
Sat Feb 19 05:08:09 2022 daemon.notice hostapd: wlan0: BEACON-RESP-RX 33:33:33:33:33:33 212 00 ...actual beacon data elided...
The odd thing is, it seems that DAWN is requesting the beacon for the AP the client is already connected to?! I'm confused why DAWN wants the beacon for the client's current AP, as the signal strength for the current AP should already be known.
It does seem that my devices that support RRM can request the beacon for other APs. For example, if I manually run: ubus call hostapd.wlan0 rrm_beacon_req '{"addr":"33:33:33:33:33:33","mode":1,"op_class":0,"channel":11,"duration":100,"bssid":"11:11:11:11:11:60","ssid":"MySSID"}' I'll see something like the following in the system log:
Sat Feb 19 05:13:21 2022 daemon.notice hostapd: wlan0: BEACON-RESP-RX 33:33:33:33:33:33 218 00 ...actual beacon data elided...
and sure enough the hearing map will then populate for the additional AP:
{
"MySSID": {
"33:33:33:33:33:33": {
"11:11:11:11:11:5F": {
"signal": -42,
"rcpi": 223,
"rsni": 0,
"freq": 5500,
"ht_capabilities": true,
"vht_capabilities": true,
"channel_utilization": 3,
"num_sta": 2,
"ht_support": true,
"vht_support": true,
"score": 181
},
"11:11:11:11:11:60": {
"signal": -43,
"rcpi": 220,
"rsni": 0,
"freq": 2462,
"ht_capabilities": true,
"vht_capabilities": true,
"channel_utilization": 59,
"num_sta": 1,
"ht_support": true,
"vht_support": false,
"score": 154
}
}
}
}
The other odd thing I noticed is that the hearing map often contains the results of PROBE messages for devices from other households. I'll often see a dozen or more devices in the hearing map that are not mine and are not authorized to connect to MySSID. It's not clear to me if the hearing map is storing broadcast PROBE requests, or if these devices are sending directed PROBE requests to MySSID.
I looked briefly through the DAWN code to see why it queries beacons for the client's current AP. It does seem like the code is capable of querying other APs (src/utils/ubus.c:ubus_send_beacon_report() takes an AP parameter), but it seems intentional that only the current AP is queried (src/utils/ubus.c:update_beacon_reports() seems to only request the local AP radios).
I was thinking I might "hack" the DAWN code to request beacons for all APs, but thought I should ask what the intent of the code is first. I did read the recent docs at https://github.com/Ian-Clowes/DAWN (which was very helpful), but I'm still confused on the hearing map.
Some questions:
- What is the intended workflow of an "AP invoked client nudge to another AP"; how is the data in the hearing map intended to be used?
- What value is there in requesting the client to report the beacon of the AP it is currently connected to?
- Why does the hearing map store probe reports for clients that aren't actually connected to any AP (and perhaps not authorized to connect to any AP)?
Perhaps @PolynomialDivision or @IanC may have some thoughts on the above?
Thanks,
-Kevin
), and long as we can do a steer when the "old" signal is in the -65db to -75dB range all will be well. And that may be handled well enough by the new mode 2 kicking, which simply looks for the current connection crossing that -65dB line rather than worrying about which is the best other AP to steer to.
