My understanding is that it is unnecessary. I am basing it on the fact that ubus call usteer remote_info happily returns all of my APs/SSIDs. Further, for each of the results, the output includes "rrm_nr" which lists the BSSID, SSID, and Neighbor Report value.
Also, based on this, https://github.com/openwrt/usteer#functions, I am [perhaps naively] assuming "Synchronization of Neighbor Reports between multiple APs" is fulfilling the role that static-neighbor-report would otherwise play.
If anyone knows that static-neighbor-report is actually needed with Usteer, I'll be glad to be corrected on that for the sake of science.
Sure is! That's the purpose of the enabled event log types (list event_log_types ...) in my config. Running logread -f will allow you to see a lot of what Usteer is doing.
Making some more interesting discoveries on this topic. Any iPhone users who also happen to be somewhat Wireshark savvy--could you help test something with me?
When analyzing the sniffer capture in Wireshark (again, post-capture), I found two of my iPhones (an iPhone 11 and an iPhone 12 Pro Max) are not indicating support for neighbor reports in their RM capabilities when sending an association request to the AP. Supposedly these iPhones support 802.11k, but the association request says otherwise.
When the AP sends the association response back, it indicates it supports neighbor report (hooray for 802.11k), but also states AP channel report capability is disabled:
Because the iPhones state they don't have neighbor report enabled, they never send a Neighbor Report Request, thus the AP does not send a Neighbor Report Response back.
Not sure what to make of all this yet, but wanted to float the info out there to the smarter brains who might have some thoughts about it.
For anyone willing to test this with me, the following display filter in Wireshark should show the packets we're interested in here:
With this usteer configuration, I believe I fixed my roaming "issues". I see no more 4 way handshake and Viber do not disconnect while walking around my apartment. I need to test it with MS Teams. I needed just to comment the min snr -70, as when I am smoking on the terrace I got disconnected from the AP.
Thanks. Will continue testing
Glad to hear a positive report back on the config, though I'm a little confused by your mention of no more 4-way handshakes. That's not necessarily a good thing, TBH. But maybe I misunderstood what you were saying.
Would you mind elaborating on that point some more?
As far as I understood it from other topics like https://forum.openwrt.org/t/any-way-to-monitor-if-802-11r-is-working/73504/2?u=underworld with "k" roaming you should not have again 4 way handshakes, as the clients are already authenticated and you should see something like this auth_alg=ft. And in fact now I do not see 4 way mesages and roaming seems to work.
Regards
Ah, yes! So in an ideal configuration, you would be seeing much more of this in your logs:
WPA: FT authentication already completed - do not start 4-way handshake
And just for the sake of not leading anyone astray on this thread, that is a feature/function of 802.11r, not specifically 802.11k/v. Though obviously when configured properly, they all play together for a great end-user experience.
Yep but I never saw : WPA: FT authentication already completed - do not start 4-way handshake, in my 4-5 years of experiments. I am glad however that I do not see anymore 4-way handshake messages.
Continuing this discovery... I confirmed that without Usteer or Dawn, beacon frames from the AP do not have Link Measurement enabled. This screen capture is what the beacon looks like when Usteer or Dawn are enabled (I tested with each enabled independently):
However, the AP does not reply with a Neighbor Report Response.
I have a single Android device (not by choice) in my house and it properly exchanges Neighbor Report Requests and Neighbor Report Responses with my APs.
Is this an iOS issue? Does Apple not use NRRs anymore?
In relation to my previous post, I have submitted a bug report with Apple to make them aware of what I am seeing. Not going to hold my breath on getting actionable responses back, but they may surprise me.
Here is a question, mindful that both DAWN and Usteer have various snags. Perhaps @patrakov, @account4538 or @eR2022 can offer some insight.
Would you expect enabling 802.11k and 802.11v without doing anything else to cause harm? If so why? And what minimum extra step(s) should be undertaken to make things work well with having enabled 802.11k and/or 802.11v? For example, above there was mention of static-neighbor-report.
No harm in enabling any of these options by themselves.
Here is a DAWN config that works for me with WPA2 - but note that this is just a test setup, and I don't really need the second AP. The test clients are two Linux laptops with Intel AX200 and AX210 cards, and Samsung Galaxy A02 phone. I know that there are lots of options that should better be removed.
And note: this has been tested on the 2.4 GHz only, as band steering inevitably adds latency spikes while in the gray area. I could not get 802.11r to work reliably - sometimes it does roam with FT, sometimes it does a full 4-way handshake.
How do you test? I found the android phone app Ubiquiti WiFiman app helpful because it shows you transitions in real-time with continuously plotting graph of signal strength. I haven't figured out a good alternative for Apple iPhones or iPads. Or perhaps with DAWN you can look in the DAWN logs.
The motivation behind my question was just that it seems nice to be able to be able to keep things simple. I think that was perhaps @account4538's approach.
I also test using that, but also note that it produces some false reports about roaming. I.e. it draws an arrow without the word "Disconnected", while in the hostapd log on the AP there is clearly a 4-way handshake.
Screenshot falsely indicating a successful roam but also a huge latency spike:
I only use the neighbor report and 802.11r fast transition and both Apple and Android phones FT without issue and I don't have any devices that cannot connect.
I'm using WPA2-PSK, no 802.11w frame protection, KRACK countermeasures off, reassociation deadline 65535, FT over the air, generate PMK locally, and Time interval for rekeying GTK=0
Do you use static-neighbor-report to make that work? If not how do you populate the list? And might static-neighbor-report not be a good idea in your case?
How I'm doing it is I'm populating the list in startup and as a cronjob. static-neighbor-report and other scripts do the same thing for you.
After populating the list, it will remain until a reboot or change in settings where hostapd has to restart. So I just do a check every 5 mins to make sure the list is still populated which is what those scripts do, but you can do it with a one line command.
To get the info from an AP: ubus call hostapd.wlan1 rrm_nr_get_own (or wlan0, wlan1-1, etc...)
Just put this info into it's neighboring AP - example:
Just for me it's just easier for the simplicity and management vs a script or package that is just a one line command.
As for 802.11v I just don't need it as my mobile devices roam fine without issue. I have also read that it can cause issues with 802.11r fast transition which was my main focus. If you have to force disconnect a device then you loose the fast transition and the device has to scan again and then completely re-authenticate to an AP and do the 4-way handshake. This breaks your connection and ruins the experience for the user especially if it's something like wifi calling, video chat, streaming video, etc. that they are on.
