Should I ignore it than?
You can just ignore it.
I pushed 802.11v (fast bss transition) upstream. Further I started sending beacon reports to clients (802.11k). If the package gets for your target available (you need openwrt master build), could u look if it's working?
If u type in
ubus call dawn get_network
You should see in the json output:
"OpenWrt-Test": {
"XX:XX:XX:XX:XX:XX": {
"freq": 2412,
"channel_utilization": 60,
"num_sta": 1,
"ht_support": true,
"vht_support": false,
"neighbor_report": "aodiwjdoiamdimdsmdiwmidwwdasd",
"EE:EE:EE:EE:EE:EE": {
"ht": true,
"vht": false,
"collision_count": 2,
"signal": -66
}
}
}
The most important line is the "neighbor_report" line. It would be nice if u could check the line.
Further, please check with
ubus call dawn get_hearing_map
"AA:AA:AA:AA:AA:AA": {
"XX:XX:XX:XX:XX:XX": {
"signal": -76,
"rcpi": 185,
"rsni": 0,
"freq": 2412,
"ht_capabilities": true,
"vht_capabilities": false,
"channel_utilization": 56,
"num_sta": 1,
"ht_support": true,
"vht_support": false,
"score": 0
}
}
If some rcpi or rsni is set. (802.11k)
Currently, those values are not used for load balancing, but soon they will be very important.
You can check your own neighbor report line with
ubus call hostapd.wlan0 rrm_nr_get_own
1 Like
Amazing, I'm following your work and wanna test it this weekend.
Keep your work going on. 
The example output from you looks confusing to me... What does it stand for and for which value should we check?
1 Like
An AP is presented in 802.11v by its neighbor report. That is a string in which AP information is encoded. Here is the function in the ubus call.
A Neighbor Report element consits of:
Element ID | Length | BSSID | BSSID Information | Operating Class | Class Number | PHY Type | Optional Subelements
I'm not sure if everything is correct.
With a neighbor report element the client directly knows bssid, and channel, so it does not need to scan or do other procedures.
If you now want to steer a client, you need to give the client the information to which AP it should connect. And you do that by sending this famous "bss transistion" frame (forgot the name) and include a list of neighbor reports (so a list of APs that are represented by the neighbor reports).
Currently, I'm trying to pick the best AP for a client and send it a wmn_diassoc (so I tell the client I will kick it in x-seconds, but here is some list of APs you can connect to/ or if the abridged flag is set: you must/should connect to).
Don't expect that much. Currently, I'm not testing load balancing stuff and steering (just sometimes). I'm fixing stuff and monitoring my network and look if somethings breaks or if I did somewhere a memory leak or mistake.
Sometimes it is hard to check if something is actual working. For example, if you want to know if a client did a bss transition, you have do increase the debug level of hostapd. Otherwise, it could be that just a kick happend.
So please look:
- something is wrong
- 802.11k frames are exchanged
- neighbor reports are exchanged
- ...
I need to port my load balancing score mechanism to work with 802.11k. But without probe exchange, I don't know the capabilities of my clients (can a client do vht or just ht) and all that problems...
Further, I'm sending 802.11k frames periodically to all clients to get a hearing map. Actually, this does not make sense for clients that do not support 802.11k (but that is no problem since hostapd checks that). In addition, I'm spamming the network with useless 802.11k frames, if no load balancing is required. Further, load balancing should happen if the channel utilization is high, ... It does not make sense to load balance clients of an AP with very low channel utilization...
So I have to do a lot and always test if I crashed something, because every driver implements something differently... It's annoying to work with so heterogeneous devices. xD
I'm very thankful for test reports! 
1 Like
Actually, dawn can replace the script @ParanoidZoid wrote if I would add
ubus call hostapd.wlan0 rm_nr_set [nr_reports ]
Then hostapd can answer on a request from a client, that the AP should give it possible roaming canidates, to reduce the energy and time costs of doing a scan.
I think I will do this and set a flag to disable it again. I'm afraid that if I feed the hostapd with nr-reports, it will have a negative effect on steering clients because my control logic will be ignored.
Here is the script:
I managed to get your script up and running. It's working flawlessly after a few adjustments that I'll post soon enough. The main error was that the script was failing the random ID check that you introduced. In my case, the beacon report always returns "6100" (S8 phone) or "6400" (iPhone 10) in that "duration" placeholder.
Thanks for sharing your work!
Glad it works!
Do share what changes you have made, I will add the random ID as a true / false in the configuration file.
I never had an issues with it, but I only tested / use it on one client (my S7 Edge).
So, these are the adjustments and findings that I had over the last few days implementing your script. I managed to put all of the family’s mobile phones in the system, two iPhones X and two S8s. The system is up and running with no complaints so far, and I have to say that my user base is not complacent when it comes to problems with my internet access (teens…).
Duration: As I said a few posts above, the script was failing until I found out that the ID check was the culprit. The original script does a check for the “duration” field between the beacon request value and beacon reported value. It turns out that whatever number I used in the beacon request, the beacon report would always show “6100” for the S8s and “6400” for the iPhones. I ended up using a value of “100” in the beacon request but I did not further explore the workings of this field.
RSSI/RCPI/RSNI: the field RCPI (or RSSI) shows clearly different scales for signal measurements. At first, I found that the reported values for the S8 was a RCPI scale varying from ~70-190 at different distances from the router with higher numbers meaning stronger signal (it was definitely not RSSI). I then verified the numbers for the iPhone and the scale was ~180-250 measured at the same spots as the S8. Finally, I checked the RSNI reported values and they were also different: S8 range of 24-28 and iPhone range of 64 to 72. These numbers seem to be incompatible between S8 and iPhone but there should be some formula to convert RCPI/RSNI into RSSI although I could not figure it out and neither could find anything in the internet.
So here’s what I did. First, I took several data points for "iw station get" and beacon request issued at the same time, at various distances from the router, and then calculated linear regressions for both the S8 and the iPhone (each with a different formula). The regressions came out fairly good actually, with a R2 of 0.99. Since the RSNI numbers are also different between the phones, I used an if-then statement: if RSNI > 50, use the S8 formula, else, use the iPhone formula.
Until someone figures out the whole RCPI/RSNI/RSSI conversion formula, I’ll stick to that home-made solution. If someone could also check these numbers for different devices, it could help solving the puzzle.
In case someone is interested, these are the formulas that I used (in php code):
if($rsni>50){ // case for S8s
$rssi=floor(($rcpi*-0.55)+130); // Calc RSSI
}
else{ // case for iPhones
$rssi=floor(($rcpi*-0.90)+260); // Calc RSSI
}
Client steering: I was unable to steer clients from one AP to another and neither from one frequency to another, using “hostapd_cli wlan[X] bss_tm_req”. On the other hand, “ubus call hostapd.wlan[X] wnm_disassoc_imminent” works like a charm. I couldn’t figure out why though.
Beacon request timing: it took me a while to figure out that the iPhones don’t like being asked to report beacons too often. I noticed that they sometimes remain mute for almost 2 minutes. They acknowledge the beacon request but report a blank string. I don't know if that's a security feature/restriction of the iPhone or the result of some variable in the beacon request that could be tuned to make the device more "talkative". Given that iPhone restriction (with S8 I had no such problems), I had to increase the beacon checking interval to 10 secs and increase the total time before deauth to 2 minutes. That makes things a bit slower but the system still works well.
This was my saga over the last few days, but the end result was well worth it. I would love to hear from others about their experience with 802.11k and client steering. I felt that, in addition to the (forced) roaming features of the script created by anom3, my wifi network has become more robust so I believe that packaging a 802.11k tool could be an interesting addition for an openwrt router.
A big thank you note goes to anom3 and others that helped me putting this togehter.
4 Likes
I try to collect both, RSSI and RCPI. Here you can see that a client only reported for the 5 GHz the RCPI value of 198, but I received two frames from which I got a RSSI of -43 (5 GHz) and -47 (2.4 GHz).
If I now use your formula 198*-0.55+130 I'm at 21.1? That is far away from -43?
This calculation is very important for me. 
I forgot to mention that my RSSI calculations throw out positive RSSI values, i.e., RSSI * -1 so that I can input directly into anom3 script. So just multiply 21.1 * -1 = -21.1. It's still quite off from -43.
What is the client device (Android, iPhone?) that you are using for these measurements?
If you don't mind sharing an experiment: take at least two data points (X = the RSSI showed by iw, and Y = the decimal number reported by the beacon), one right next to the router and another the farthest you can go. We can then have an idea of the signal range for high x low and then we can compare our findings.
Needless to say that the formulas work well for my case and they are certainly not the technically correct way of calculating RSSI. But since I couldn't find anything in the internet, I had to improvise.
Wow, you even received RSNI values. 
I have a Xiaomi Mi 9 with LineageOS. I will do some measurements! 
Any hints why one R7800 (AP and router) lists under View Network Overview only own networks/clients and at the same time another R7800 (AP) lists everything?
One of two R7800s is flooding log with an error message Received NULL MAC! Client is strange!
More detailed log from that AP looks like that:
May 1 08:47:40 192.168.1.2 dawn[16726]: Crafting Beacon Report
May 1 08:47:40 192.168.1.2 dawn[16726]: Adding string
May 1 08:47:40 192.168.1.2 dawn[16726]: Invoking beacon report!
May 1 08:47:40 192.168.1.2 dawn[16726]: Method new: beacon-report : {"address":"xx:xx:xx:xx:xx:xx","op-class":0,"channel":0,"start-time":0,"duration":0,"report-info":128,"rcpi":0,"rsni":0,"bssid":"00:00:00:00:00:00","antenna-id":0,"parent-tsf":0}
May 1 08:47:40 192.168.1.2 dawn[16726]: Received NULL MAC! Client is strange!
May 1 08:47:40 192.168.1.2 dawn[16726]: Method new: beacon-report : {"address":"yy:yy:yy:yy:yy:yy","op-class":0,"channel":0,"start-time":0,"duration":0,"report-info":128,"rcpi":0,"rsni":0,"bssid":"00:00:00:00:00:00","antenna-id":0,"parent-tsf":0}
May 1 08:47:40 192.168.1.2 dawn[16726]: Received NULL MAC! Client is strange!
Here is bigger chunk of combined log from both devices:
May 1 09:36:12 192.168.1.1 dawn[16337]: --------APs------
May 1 09:36:12 192.168.1.1 dawn[16337]: ssid: IoT, bssid_addr: B0:7F:B9:80:80:80, freq: 2472, ht: 1, vht: 0, chan_utilz: 2, col_d: -1, bandwidth: -1, col_count: 11 neighbor_report: b9808080ef090000510d070603000d00
May 1 09:36:12 192.168.1.1 dawn[16337]: ssid: prod, bssid_addr: B0:7F:B9:77:77:77, freq: 5580, ht: 1, vht: 1, chan_utilz: 0, col_d: -1, bandwidth: -1, col_count: 11 neighbor_report: b9777777ff1900008074090603027a00
May 1 09:36:12 192.168.1.1 dawn[16337]: ------------------
May 1 09:36:12 192.168.1.1 dawn[16337]: --------Connections------
May 1 09:36:12 192.168.1.1 dawn[16337]: Conenctin to Port: 516, Connected: True
May 1 09:36:12 192.168.1.1 dawn[16337]: ------------------
May 1 09:36:12 192.168.1.1 dawn[16337]: Ustream send: 1088
May 1 09:36:12 192.168.1.1 dawn[16337]: --------Clients------
May 1 09:36:12 192.168.1.1 dawn[16337]: Client Entry Last: 10
May 1 09:36:12 192.168.1.1 dawn[16337]: bssid_addr: B0:7F:B9:77:77:77, client_addr: 5B:5B:5B:5B:5B:5B, freq: 5580, ht_supported: 1, vht_supported: 1, ht: 1, vht: 1, kick: 0
May 1 09:36:12 192.168.1.1 dawn[16337]: bssid_addr: B0:7F:B9:80:80:80, client_addr: 1A:1A:1A:1A:1A:1A, freq: 2472, ht_supported: 1, vht_supported: 0, ht: 1, vht: 0, kick: 0
May 1 09:36:12 192.168.1.1 dawn[16337]: bssid_addr: B0:7F:B9:80:80:80, client_addr: 68:68:68:68:68:68, freq: 2472, ht_supported: 1, vht_supported: 0, ht: 1, vht: 0, kick: 0
May 1 09:36:12 192.168.1.1 dawn[16337]: bssid_addr: B0:7F:B9:80:80:80, client_addr: E6:E6:E6:E6:E6:E6, freq: 2472, ht_supported: 1, vht_supported: 0, ht: 1, vht: 0, kick: 0
May 1 09:36:12 192.168.1.1 dawn[16337]: bssid_addr: B0:7F:B9:80:80:80, client_addr: D2:D2:D2:D2:D2:D2, freq: 2472, ht_supported: 1, vht_supported: 0, ht: 1, vht: 0, kick: 0
May 1 09:36:12 192.168.1.1 dawn[16337]: bssid_addr: B0:7F:B9:80:80:80, client_addr: 83:83:83:83:83:83, freq: 2472, ht_supported: 1, vht_supported: 0, ht: 1, vht: 0, kick: 0
May 1 09:36:12 192.168.1.1 dawn[16337]: bssid_addr: B0:7F:B9:80:80:80, client_addr: 50:50:50:50:50:50, freq: 2472, ht_supported: 1, vht_supported: 0, ht: 1, vht: 0, kick: 0
May 1 09:36:12 192.168.1.1 dawn[16337]: bssid_addr: B0:7F:B9:80:80:80, client_addr: A4:A4:A4:A4:A4:A4, freq: 2472, ht_supported: 1, vht_supported: 0, ht: 1, vht: 0, kick: 0
May 1 09:36:12 192.168.1.1 dawn[16337]: bssid_addr: B0:7F:B9:80:80:80, client_addr: 6E:6E:6E:6E:6E:6E, freq: 2472, ht_supported: 1, vht_supported: 0, ht: 1, vht: 0, kick: 0
May 1 09:36:12 192.168.1.1 dawn[16337]: bssid_addr: B0:7F:B9:80:80:80, client_addr: 90:90:90:90:90:90, freq: 2472, ht_supported: 1, vht_supported: 0, ht: 1, vht: 0, kick: 0
May 1 09:36:12 192.168.1.1 dawn[16337]: bssid_addr: B0:7F:B9:80:80:80, client_addr: 75:75:75:75:75:75, freq: 2472, ht_supported: 1, vht_supported: 0, ht: 1, vht: 0, kick: 0
May 1 09:36:12 192.168.1.1 dawn[16337]: ------------------
May 1 09:36:12 192.168.1.1 dawn[16337]: --------APs------
May 1 09:36:12 192.168.1.1 dawn[16337]: ssid: IoT, bssid_addr: B0:7F:B9:80:80:80, freq: 2472, ht: 1, vht: 0, chan_utilz: 2, col_d: -1, bandwidth: -1, col_count: 11 neighbor_report: b9808080ef090000510d070603000d00
May 1 09:36:12 192.168.1.1 dawn[16337]: ssid: prod, bssid_addr: B0:7F:B9:77:77:77, freq: 5580, ht: 1, vht: 1, chan_utilz: 0, col_d: -1, bandwidth: -1, col_count: 11 neighbor_report: b9777777ff1900008074090603027a00
May 1 09:36:12 192.168.1.1 dawn[16337]: ------------------
May 1 09:36:12 192.168.1.1 dawn[16337]: Hostname: R7800ap
May 1 09:36:12 192.168.1.1 dawn[16337]: IPV4: 192.168.1.2
May 1 09:36:12 192.168.1.1 dawn[16337]: Port: 1026
May 1 09:36:13 192.168.1.2 dawn[17366]: [Thread] : Removing old client entries!
May 1 09:36:13 192.168.1.2 dawn[17366]: --------Connections------
May 1 09:36:13 192.168.1.2 dawn[17366]: Conenctin to Port: 516, Connected: True
May 1 09:36:13 192.168.1.2 dawn[17366]: ------------------
May 1 09:36:13 192.168.1.2 dawn[17366]: Ustream send: 5400
May 1 09:36:13 192.168.1.2 dawn[17366]: --------Clients------
May 1 09:36:13 192.168.1.2 dawn[17366]: Client Entry Last: 7
May 1 09:36:13 192.168.1.2 dawn[17366]: bssid_addr: 8C:3B:AD:F4:F4:F4, client_addr: F7:F7:F7:F7:F7:F7, freq: 5200, ht_supported: 1, vht_supported: 1, ht: 1, vht: 1, kick: 0
May 1 09:36:13 192.168.1.2 dawn[17366]: bssid_addr: 8C:3B:AD:F4:F4:F4, client_addr: 7A:7A:7A:7A:7A:7A, freq: 5200, ht_supported: 1, vht_supported: 1, ht: 1, vht: 0, kick: 0
May 1 09:36:13 192.168.1.2 dawn[17366]: bssid_addr: 8C:3B:AD:F4:F4:F4, client_addr: 41:41:41:41:41:41, freq: 5200, ht_supported: 1, vht_supported: 1, ht: 1, vht: 0, kick: 0
May 1 09:36:13 192.168.1.2 dawn[17366]: bssid_addr: 8C:3B:AD:F4:F4:F4, client_addr: 3B:3B:3B:3B:3B:3B, freq: 5200, ht_supported: 1, vht_supported: 1, ht: 1, vht: 1, kick: 0
May 1 09:36:13 192.168.1.2 dawn[17366]: bssid_addr: 8C:3B:AD:F4:F4:F4, client_addr: 2F:2F:2F:2F:2F:2F, freq: 5200, ht_supported: 1, vht_supported: 1, ht: 1, vht: 1, kick: 0
May 1 09:36:13 192.168.1.2 dawn[17366]: bssid_addr: 8C:3B:AD:F4:F4:F4, client_addr: 61:61:61:61:61:61, freq: 5200, ht_supported: 1, vht_supported: 1, ht: 1, vht: 1, kick: 0
May 1 09:36:13 192.168.1.2 dawn[17366]: bssid_addr: 8C:3B:AD:F4:F4:F4, client_addr: B13:13:13:13:13:13, freq: 5200, ht_supported: 1, vht_supported: 1, ht: 1, vht: 1, kick: 0
May 1 09:36:13 192.168.1.2 dawn[17366]: bssid_addr: B0:7F:B9:77:77:77, client_addr: 5B:5B:5B:5B:5B:5B, freq: 5580, ht_supported: 1, vht_supported: 1, ht: 1, vht: 1, kick: 0
May 1 09:36:13 192.168.1.2 dawn[17366]: ------------------
May 1 09:36:13 192.168.1.2 dawn[17366]: --------APs------
May 1 09:36:13 192.168.1.2 dawn[17366]: ssid: prod, bssid_addr: 8C:3B:AD:F4:F4:F4, freq: 5200, ht: 1, vht: 1, chan_utilz: 221529894, col_d: -1, bandwidth: -1, col_count: 8 neighbor_report: adf4f4f4ef1900008028090603022a00
May 1 09:36:13 192.168.1.2 dawn[17366]: ssid: prod, bssid_addr: B0:7F:B9:77:77:77, freq: 5580, ht: 1, vht: 1, chan_utilz: 0, col_d: -1, bandwidth: -1, col_count: 8 neighbor_report: b9777777ff1900008074090603027a00
May 1 09:36:13 192.168.1.2 dawn[17366]: ------------------
May 1 09:36:13 192.168.1.2 dawn[17366]: Sending beacon report!
May 1 09:36:13 192.168.1.2 dawn[17366]: Sending beacon report Sub!
May 1 09:36:13 192.168.1.2 dawn[17366]: Crafting Beacon Report
May 1 09:36:13 192.168.1.2 dawn[17366]: Adding string
May 1 09:36:13 192.168.1.2 dawn[17366]: Invoking beacon report!
May 1 09:36:13 192.168.1.2 dawn[17366]: Crafting Beacon Report
May 1 09:36:13 192.168.1.2 dawn[17366]: Adding string
May 1 09:36:13 192.168.1.2 dawn[17366]: Invoking beacon report!
May 1 09:36:13 192.168.1.2 dawn[17366]: Crafting Beacon Report
May 1 09:36:13 192.168.1.2 dawn[17366]: Adding string
May 1 09:36:13 192.168.1.2 dawn[17366]: Invoking beacon report!
May 1 09:36:13 192.168.1.2 dawn[17366]: Crafting Beacon Report
May 1 09:36:13 192.168.1.2 dawn[17366]: Adding string
May 1 09:36:13 192.168.1.2 dawn[17366]: Invoking beacon report!
May 1 09:36:13 192.168.1.2 dawn[17366]: Crafting Beacon Report
May 1 09:36:13 192.168.1.2 dawn[17366]: Adding string
May 1 09:36:13 192.168.1.2 dawn[17366]: Invoking beacon report!
May 1 09:36:13 192.168.1.2 dawn[17366]: Crafting Beacon Report
May 1 09:36:13 192.168.1.2 dawn[17366]: Adding string
May 1 09:36:13 192.168.1.2 dawn[17366]: Invoking beacon report!
May 1 09:36:13 192.168.1.2 dawn[17366]: Crafting Beacon Report
May 1 09:36:13 192.168.1.2 dawn[17366]: Adding string
May 1 09:36:13 192.168.1.2 dawn[17366]: Invoking beacon report!
May 1 09:36:13 192.168.1.2 dawn[17366]: Hostname: R7800rtr
May 1 09:36:13 192.168.1.2 dawn[17366]: IPV4: 192.168.1.1
May 1 09:36:13 192.168.1.2 dawn[17366]: Port: 1026
May 1 09:36:13 192.168.1.2 dawn[17366]: Method new: beacon-report : {"address":"61:61:61:61:61:61","op-class":0,"channel":0,"start-time":0,"duration":0,"report-info":128,"rcpi":0,"rsni":0,"bssid":"00:00:00:00:00:00","antenna-id":0,"parent-tsf":0}
May 1 09:36:13 192.168.1.2 dawn[17366]: Received NULL MAC! Client is strange!
May 1 09:36:13 192.168.1.2 dawn[17366]: Method new: beacon-report : {"address":"41:41:41:41:41:41","op-class":0,"channel":0,"start-time":0,"duration":0,"report-info":128,"rcpi":0,"rsni":0,"bssid":"00:00:00:00:00:00","antenna-id":0,"parent-tsf":0}
May 1 09:36:13 192.168.1.2 dawn[17366]: Received NULL MAC! Client is strange!
May 1 09:36:17 192.168.1.1 dawn[16337]: Method new: probe : {"address":"b13:13:13:13:13:13","target":"ff:ff:ff:ff:ff:ff","signal":-68,"freq":2472,"ht_capabilities":{"ht_capabilities_info":6639,"supported_mcs_set":{"a_mpdu_params":23,"ht_extended_capabilities":0,"tx_bf_capability_info":0,"asel_capabilities":0,"supported_mcs_set":[255,255,0,0,0,0,0,0,0,0,44,1,1,0,0,0]}}}
May 1 09:36:17 192.168.1.1 dawn[16337]: --------Connections------
May 1 09:36:17 192.168.1.1 dawn[16337]: Conenctin to Port: 516, Connected: True
May 1 09:36:17 192.168.1.2 dawn[17366]: Network Method new: probe : {"method":"probe","data":"{\"bssid\":\"B0:7F:B9:80:80:80\",\"address\":\"B13:13:13:13:13:13\",\"target\":\"FF:FF:FF:FF:FF:FF\",\"signal\":-68,\"freq\":2472,\"rcpi\":-1,\"rsni\":-1}"}
May 1 09:36:17 192.168.1.1 dawn[16337]: ------------------
May 1 09:36:17 192.168.1.1 dawn[16337]: Ustream send: 256
May 1 09:36:18 192.168.1.1 dawn[16337]: Method new: probe : {"address":"b13:13:13:13:13:13","target":"ff:ff:ff:ff:ff:ff","signal":-78,"freq":5580,"ht_capabilities":{"ht_capabilities_info":6639,"supported_mcs_set":{"a_mpdu_params":23,"ht_extended_capabilities":0,"tx_bf_capability_info":0,"asel_capabilities":0,"supported_mcs_set":[255,255,0,0,0,0,0,0,0,0,44,1,1,0,0,0]}},"vht_capabilities":{"vht_capabilities_info":59798006,"vht_supported_mcs_set":{"rx_map":-6,"rx_highest":0,"tx_map":-6,"tx_highest":8192}}}
May 1 09:36:18 192.168.1.1 dawn[16337]: --------Connections------
May 1 09:36:18 192.168.1.2 dawn[17366]: Network Method new: probe : {"method":"probe","data":"{\"bssid\":\"B0:7F:B9:77:77:77\",\"address\":\"B13:13:13:13:13:13\",\"target\":\"FF:FF:FF:FF:FF:FF\",\"signal\":-78,\"freq\":5580,\"rcpi\":-1,\"rsni\":-1}"}
May 1 09:36:18 192.168.1.1 dawn[16337]: Conenctin to Port: 516, Connected: True
May 1 09:36:18 192.168.1.1 dawn[16337]: ------------------
May 1 09:36:18 192.168.1.1 dawn[16337]: Ustream send: 256
May 1 09:36:18 192.168.1.1 dawn[16337]: Method new: probe : {"address":"b13:13:13:13:13:13","target":"ff:ff:ff:ff:ff:ff","signal":-77,"freq":5580,"ht_capabilities":{"ht_capabilities_info":6639,"supported_mcs_set":{"a_mpdu_params":23,"ht_extended_capabilities":0,"tx_bf_capability_info":0,"asel_capabilities":0,"supported_mcs_set":[255,255,0,0,0,0,0,0,0,0,44,1,1,0,0,0]}},"vht_capabilities":{"vht_capabilities_info":59798006,"vht_supported_mcs_set":{"rx_map":-6,"rx_highest":0,"tx_map":-6,"tx_highest":8192}}}
May 1 09:36:18 192.168.1.1 dawn[16337]: --------Connections------
May 1 09:36:18 192.168.1.1 dawn[16337]: Conenctin to Port: 516, Connected: True
May 1 09:36:18 192.168.1.1 dawn[16337]: ------------------
May 1 09:36:18 192.168.1.2 dawn[17366]: Network Method new: probe : {"method":"probe","data":"{\"bssid\":\"B0:7F:B9:77:77:77\",\"address\":\"B13:13:13:13:13:13\",\"target\":\"FF:FF:FF:FF:FF:FF\",\"signal\":-77,\"freq\":5580,\"rcpi\":-1,\"rsni\":-1}"}
May 1 09:36:18 192.168.1.1 dawn[16337]: Ustream send: 256
May 1 09:36:18 192.168.1.2 dawn[17366]: Method new: probe : {"address":"b13:13:13:13:13:13","target":"ff:ff:ff:ff:ff:ff","signal":-52,"freq":5200,"ht_capabilities":{"ht_capabilities_info":6639,"supported_mcs_set":{"a_mpdu_params":23,"ht_extended_capabilities":0,"tx_bf_capability_info":0,"asel_capabilities":0,"supported_mcs_set":[255,255,0,0,0,0,0,0,0,0,44,1,1,0,0,0]}},"vht_capabilities":{"vht_capabilities_info":59798006,"vht_supported_mcs_set":{"rx_map":-6,"rx_highest":0,"tx_map":-6,"tx_highest":8192}}}
May 1 09:36:18 192.168.1.2 dawn[17366]: --------Connections------
May 1 09:36:18 192.168.1.2 dawn[17366]: Conenctin to Port: 516, Connected: True
May 1 09:36:18 192.168.1.2 dawn[17366]: ------------------
May 1 09:36:18 192.168.1.2 dawn[17366]: Ustream send: 256
May 1 09:36:18 192.168.1.1 dawn[16337]: Network Method new: probe : {"method":"probe","data":"{\"bssid\":\"8C:3B:AD:F4:F4:F4\",\"address\":\"B13:13:13:13:13:13\",\"target\":\"FF:FF:FF:FF:FF:FF\",\"signal\":-52,\"freq\":5200,\"rcpi\":-1,\"rsni\":-1}"}
May 1 09:36:18 192.168.1.2 dawn[17366]: Method new: probe : {"address":"b13:13:13:13:13:13","target":"ff:ff:ff:ff:ff:ff","signal":-52,"freq":5200,"ht_capabilities":{"ht_capabilities_info":6639,"supported_mcs_set":{"a_mpdu_params":23,"ht_extended_capabilities":0,"tx_bf_capability_info":0,"asel_capabilities":0,"supported_mcs_set":[255,255,0,0,0,0,0,0,0,0,44,1,1,0,0,0]}},"vht_capabilities":{"vht_capabilities_info":59798006,"vht_supported_mcs_set":{"rx_map":-6,"rx_highest":0,"tx_map":-6,"tx_highest":8192}}}
May 1 09:36:18 192.168.1.2 dawn[17366]: --------Connections------
May 1 09:36:18 192.168.1.2 dawn[17366]: Conenctin to Port: 516, Connected: True
May 1 09:36:18 192.168.1.2 dawn[17366]: ------------------
May 1 09:36:18 192.168.1.2 dawn[17366]: Ustream send: 256
May 1 09:36:18 192.168.1.1 dawn[16337]: Network Method new: probe : {"method":"probe","data":"{\"bssid\":\"8C:3B:AD:F4:F4:F4\",\"address\":\"B13:13:13:13:13:13\",\"target\":\"FF:FF:FF:FF:FF:FF\",\"signal\":-52,\"freq\":5200,\"rcpi\":-1,\"rsni\":-1}"}
May 1 09:36:22 192.168.1.1 dawn[16337]: [Thread] : Removing old client entries!
May 1 09:36:22 192.168.1.1 dawn[16337]: --------Connections------
May 1 09:36:22 192.168.1.1 dawn[16337]: Conenctin to Port: 516, Connected: True
May 1 09:36:22 192.168.1.1 dawn[16337]: ------------------
May 1 09:36:22 192.168.1.1 dawn[16337]: Ustream send: 4248
May 1 09:36:22 192.168.1.2 dawn[17366]: Network Method new: clients : {"method":"clients","data":"{\"freq\":5580,\"clients\":{\"5B:5B:5B:5B:5B:5B\":{\"auth\":true,\"assoc\":true,\"authorized\":true,\"preauth\":false,\"wds\":false,\"wmm\":true,\"ht\":true,\"vht\":true,\"wps\":false,\"mfp\":false,\"rrm\":[0,0,0,0,0],\"aid\":1,\"signature\":\"wifi4|probe:0,1,45,191,221(0050f2,8),htcap:09ef,htagg:17,htmcs:0000ffff,vhtcap:038171b1,vhtrxmcs:0000fffa,vhttxmcs:0000fffa|assoc:0,1,33,36,45,48,127,127,191,221(0050f2,2),htcap:09e7,htagg:17,htmcs:0000ffff,vhtcap:038011b1,vhtrxmcs:0000fffa,vhttxmcs:0000fffa,txpow:0c00,extcap:0000000000000040\"}},\"collision_domain\":-1,\"bandwidth\":-1,\"bssid\":\"B0:7F:B9:77:77:77\",\"ssid\":\"prod\",\"ht_supported\":true,\"vht_supported\":true,\"ap_weight\":0,\"channel_utilization\":0,\"neighbor_report\":\"b9777777ff1900008074090603027a00\"}"}
I have interesting behavior too on my network overview. Network setup:
-one r7800 router with wireless turned off
-two hardwired r7800s as APs (DHCP turned off, both hardwired directly to the router)
-5ghz and 2.4ghz are separate SSIDs
-Smart home devices on 2.4ghz only
-Roaming devices (phones, tablets) on 5ghz only.
-5ghz has all roaming features turned on, only difference in config between APs is that they are on different channels:
root@OpenWrt:~# cat /etc/config/wireless
config wifi-device 'radio0'
option type 'mac80211'
option hwmode '11a'
option path 'soc/1b500000.pci/pci0000:00/0000:00:00.0/0000:01:00.0'
option htmode 'VHT80'
option channel '161'
option txpower '22'
option legacy_rates '0'
option country 'US'
option beacon_int '101'
config wifi-iface 'default_radio0'
option device 'radio0'
option network 'lan'
option mode 'ap'
option ft_over_ds '1'
option ssid 'fastandshort'
option ft_psk_generate_local '1'
option key '*********'
option ieee80211r '1'
option encryption 'psk2+ccmp'
option ieee80211k '1'
option bss_transition '1'
option ieee80211v '1'
config wifi-device 'radio1'
option type 'mac80211'
option channel '11'
option hwmode '11g'
option path 'soc/1b700000.pci/pci0001:00/0001:00:00.0/0001:01:00.0'
option htmode 'HT20'
option txpower '27'
option rts '980'
option legacy_rates '0'
option beacon_int '191'
config wifi-iface 'default_radio1'
option device 'radio1'
option network 'lan'
option mode 'ap'
option key '*********'
option ssid 'Slowandlong'
option encryption 'psk2+ccmp'
My two APs only report seeing only their own devices (half of the below picture). My router reports seeing all devices:
@PolynomialDivision roaming appears to be working great. I have all newer iOS devices and I’m using the DAWN default config. Is this normal behavior for the network overview or is there something in the configuration that I missed and all devices should be able to report the entire network?
You mean you have 3 routers and on only 1 you see the whole network? Seems like umdns is not working correctly. You should see everything on every router that is running DAWN. 
Please try
ubus call umdns browse
and
ubus call umdns hosts
On each AP you should see the other APs announcing DAWN, if u use the TCP mode of DAWN.
Sometimes you have to edit /etc/config/umdns and add wan interface
config umdns
option jail 1
list network lan
list network wan
1 Like
Ran this on each AP:
uci add_list umdns.@umdns[0].network='wan'; uci commit umdns
With the WAN added to the list ...
root@OpenWrt:~# cat /etc/config/umdns
config umdns
option jail '1'
list network 'lan'
list network 'wan'
Everything is working great and all APs see each other. Will continue testing. 
In my case through ubus call umdns browse router and AP both see each other yet list on the router was incomplete. After adding wan to umdns config just on access point everything is listed on both for some time only to return to the previous state regardless of wan added on both devices.
I did some testing walking around - it was very sensitive to devices going to sleep and the report will drop sleeping devices (ex: woke up this morning and one of my APs was “missing”, walked the device toward that AP and the AP with an active client reappeared). Every device responds back at different intervals and go to sleep at different intervals. Makes the reports interesting to watch.
Have the wan added to the APs, not the main router (wifi is turned off on the main router).
Don’t have any hard data or concerns about this behavior. Roaming is smooth with no jitter on iOS devices. 