Thanks. Couple more questions.
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?
Why not? What's your thinking behind this?
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:
ubus call hostapd.wlan1 rrm_nr_set '{"list": [["e3:44:52:13:c4:96","ssid_name","e3445213c496ef097000110d070603000f00"]]}'
In startup at least for my AP I need a sleep 4 first so hostapd is setup and radios are on.
As for cron, all you need is:
*/5 * * * * [[ "`ubus call hostapd.wlan1 rrm_nr_list`" == *","* ]] ||
before the command above.
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.
1 Like
@_FailSafe how about in this fine thread instead?
Quick update around the bug report I submitted to Apple. It is still unacknowledged in their system. Not surprising, but I will keep checking on it as time goes by.
At least it hasnât been closed automatically yet. 
Could you be convinced to share tips on using static-neighbor-reports?
Just following this since having looked into static-neighbor-reports I likewise prefer your manual approach. For anyone also implementing this, to add multiple AP's, just use the format:
ubus call hostapd.wlan1 rrm_nr_set '{"list": [["e3:44:52:13:c4:96","ssid_name","e3445213c496ef097000110d070603000f00"],["e3:44:52:13:c4:96","ssid_name","e3445213c496ef097000110d070603000f00"]]}'
Thank you, I forgot to mention that.
Also, I found out some AP config changes such as changing the channels changes that identifying string.
1 Like
I've just put together a service file for this purpose:
#!/bin/sh /etc/rc.common
exec &> /var/log/neighbor-reports.log
START=60
STOP=4
start()
{
ubus call hostapd.wlan0 rrm_nr_set
ubus call hostapd.wlan0-1 rrm_nr_set
ubus call hostapd.wlan1 rrm_nr_set
}
stop()
{
:
}
Perhaps hotplug event should be added? I'm not sure what it should trigger on though.
I'm not sure how with hotplug but a cronjob just simply checking for the existence of the neighbor list has been working flawlessly:
[[ "`ubus call hostapd.wlan1 rrm_nr_list`" == *","* ]]
1 Like
Ah yes, I see. Nice idea.
Also, is there any way to reasonably easily test that it's working in terms of what clients see?
âReasonableâ is quite subjective. If Wireshark doesnât scare you away, what youâre seeking can be found in this post from above:
Just remember, with Apple devices youâre treading in territory for which I have the open bug report with Apple.
1 Like
I tried Wireshark in Windows and WSL without success.
Is there a way we can work with a spare RT3200 to show the packets of interest? I appreciate a challenge is that we need something like Wireshark to interpret the packets like in the graphics you provide above.
I have same SSID shared across the 3x AP's (connected via WDS) on both 2.4GHz and 5GHz.
I think thanks to this thread I now have 802.11r, 802.11k and 802.11v properly enabled. I checked logs and devices seem to be fast transitioning. I haven't been able to test whether the neighbor reports functionality is working properly, but I've done all I can to set that up it seems - rrm_nr_list reports correct values for each station.
I went outside in our garden with my wife today (5GHz is circa -80dBm and 2.4GHz is circa -70dBm) and noticed that whereas my Pixel 3a happily switches over to 2.4Ghz on the same SSID, my wife's iPhone seems reluctant to do so and the WiFi just drops out completely.
It's as if the iPhone favours 4G over 2.4GHz or is super confused by the existence of 2.4GHz on the same SSID? I wonder what's up with that.
Anyone have any suggestions as to how to improve robustness of my WiFi for Apple devices? I'm using plan old psk2 - should I be using something different? WPA3? Mesh rather than WDS?
Can you âhearâ only one of your APs at the location you described? Or are you suggesting there is another of your APs that your wifeâs iPhone could have roamed to instead?
I have posted this multiple times in multiple threads, so I may be wearing it out. But here is Appleâs more in-depth info on how their iOS/iPadOS devices roam:
The document I posted seems to corroborate your situation. At -80dbm your 5Ghz band is not even considered. But at -70dbm your 2.4Ghz band is causing her phone to hit the trigger to roam anyway. So her phone is already desiring to jump ship and if there is no neighboring BSSID with >-70dbm RSSI for 2.4Ghz (or >-65dbm for 5Ghz) then it will jump off wireless and fall back to cellular.
If there is no other BSSID with >-70dbm @2.4Ghz or >-65dbm @5Ghz that her phone can âhearâ at any given location, youâre simply at the mercy of the vendorâs device-level roaming decisions. No software on your AP is going to affect that ultimate client roaming decision if it simply reaches the âjumping offâ point. You can increase your AP TX power, but that can have other negative side-effects. You can increase the antenna size on your client device (but not in reality for a mobile phone). Or you can reposition existing APs, or add more in the trouble areas.
I'm wondering if it is simple as this. It could be. But does it not seem surprising and unreasonable that a device will just give up at <-70dBm? Would it do the same in a single AP scenario? My Pixel 3A remains happily connected throughout the whole garden in the -70dBm to -75dBm range.
Are Apple devices OK with having same SSID on 2.4GHz and 5Ghz I wonder? Perhaps that is an issue.
The connectivity of the iPhone in the house with >-60dBm is also problematic, with it being a frequent occurrence to have to turn WiFi off and back on when the device has been unused, moved to another location in the house, and used again in the new location. It seems difficult to troubleshoot this and I am not alone in complaining about Apple WiFi. Perhaps a power saving issue or similar. This may or may not be related to the garden scenario above.
My experience with Windows/Android has been much better on the WiFi front so far, but my wife insists on using an iPhone so we are stuck with this. But there are so many variables.
I'm assuming you put the AP's on different channels?
Good point. Actually they are all on the same channel owing to my using WDS between the AP's - believe this forces that, but I may be mistaken? Is there a way to use 3x devices connected via WDS in which the AP's provide AP's with different channels? Perhaps for that I'd need to have 5GHz used as the backhaul connection between the 3x devices and then offer 2.4GHz on different channels, but I imagine the performance of this won't be as good as using 5GHz backhual and offering 5Ghz on the same channel? I'm open minded for any suggestions (save for using wires, which isn't desirable in our property). I see circa 700Mbit/s between the RT3200 devices using iperf3.
Yes, absolutely okayânot an issue. Have been doing this for years.
1 Like
I canât speak for Apple, nor am I attempting to defend all their decisions (remember, Iâm the angry guy with a ticket open with them for broken 802.11k support). But you have to consider that any device manufacturer worth a hoot is going to shape and form their function (read: algorithms) around experience. This is echoed by the fact your wife prefers an iPhone. She wants the iPhone experience, whether the next guy loves or hates the same.
So with that in mind, put yourself in Appleâs shoes for a moment. If they make a user experience choice to allow someone to remain sticky to an AP until it reaches -72dBm, -75dBm, -80dBm, -83dBm, etc., then what kind of experience will the user have? Well, it will be approaching âcrappyâ at that point. And when Apple users have a crappy experience, what happens? Well, the list is endless, but includes things like:
- loudmouth critics doing hateful vlogs on YouTube
- critics writing ill-favored blogs and reviews about âhow Apple sucksâ
- iPhone owners contacting Apple support to complain that their expensive device is working worse than their ____ Android device
- visits to Apple stores for poor Wi-Fi performance that Apple canât replicate in-store (resulting in frustrating situations for both Apple tech and consumer)
Again, not simply taking the defensive position for Apple here. But at the end of the day the story is similar for any manufacturer who cares about image. If they can make their devices look and FEEL good, itâs in their favor.
As a trial for comparison purposes, have you considered buying and testing a true mesh wireless solution (Eero, Orbi, AiMesh, etc) with a truly dedicated high bandwidth backhaul band to see what experience it offers you? That could be eye-opening and either show if your current setup is ideal or if youâre perhaps hardware bound by the RT3200s.
AP's on different channels is known to help a device roam and switch vs getting stuck on an AP or disconnecting altogether.
I'm on a wired backhaul though and you mentioned not having that option. I'm not familiar with WDS so I don't know what changes you can make there.
1 Like