“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
It's a good suggestion, but I want to persevere with my RT3200's for now.
I might try mesh again. Haven't tried that in over a year. I used it for a while and then with various patches it became unstable. Maybe it's stable again now.
Do you or anyone know whether the 802.11k and 802.11v settings as described in this thread apply also apply to 802.11s? If a mesh is used should these features be enabled and is it necessary to set the neighbor-reports or are these handled automatically? @bluewavenet I think you might have an idea here?
802.11k, v (and r) are addons for a wireless interface running in AP mode.
An AP is designed to communicate only with other wireless devices in STA (station) mode.
802.11s is a standard that defines a completely different mode for a wireless interface, ie MESH mode.
A mesh mode interface (aka a meshnode or node) is designed to talk only to other meshnode peers. The 802.11s standard defines numerous methods for multiple meshnodes to autonomously build a network wide layer 2 "mac-routing" routing table (bares no relation to layer 3 IP routing).
So the 802.11k, v and r settings have no meaning to a wireless interface running in mesh mode.
The mac-routing of an 802.11s mesh depends upon a protocol (HWMP) that propagates the mac addresses and hop-routes of all meshnodes.
Setting of parameters to enable HWMP cannot be done before the wireless interface is up. This leaves a severe problem with OpenWrt, as UCI wireless configs are implemented in the process of starting the interface.
The mesh11sd package was developed to mitigate this problem by running a daemon that checks wireless interface state and dynamically sets mesh parameters as required.
1 Like
As an alternative opinion, I have found that roaming is best with using a separate SSID for each frequency. I optimize the positioning of my APs based solely off 5ghz to get that light overlap at about -65dBm between the APs to encourage a good handover both via router assistance and via client preference. I’ve found it is important to pay attention to both the physics / hardware side of things and to use assistive technologies from the software side.
2.4ghz and 5ghz have different range and overlap differently - so roaming depending on both can be a big mess. It introduces the possibility of multiple jumps (both between bands and between APs). I’d rather jump once (AP => AP) instead of introducing the possibility of multiple jumps including to slower / more congested 2.4ghz band (worst case: AP1 5ghz => AP1 2.4ghz => AP2 2.4ghz => AP2 5ghz). Each AP utilizes a non-overlapping channel for both 2.4ghz and 5ghz.
Ultimately the client will always choose when to roam. I have all apple devices and they are exclusively on the 5ghz band (IoT devices are exclusively on 2.4ghz). I’ve gone so far as to name the SSIDs “Fastwifi” (5ghz) and “slowwifi” (2.4ghz, lol no family member / guest has asked for the slowwifi password). Everything that can be hardwired, is hardwired. I’ve had really good roaming and happy family members with this simple split SSID approach.
2 Likes
@account4538 I've been using your cron-based solution and it's excellent. One question: how can we suppress all the cron.err noise that pops up in logread?
Is the solution to reduce the cron log level from its default 5 in /etc/config/system?
Hi,
Good question... I would have thought > /dev/null 2>&1 would do it but I tried and it didn't.
You can change the loglevel for cron but it will do it for all cronjobs:
2 Likes
There is also this project that is pretty slick:
If you decide to try it, you'll want to note this post in the interim while we await some upstream changes for umDNS to trickle down into snapshot/stable:
Thanks. Curiously the log levels are reversed for busybox crond, with '0' being the most rather than the least verbose. Got caught out by that. Setting to '9' seems to work in terms of suppressing the start messages.
Interestingly looking project @_FailSafe. I think I favour @account4538's approach given its simplicity in my three AP environment.
It'd be nice if in OpenWrt were to implement an official and LuCi-backed solution for automatically and/or manually specifying neighbors given that it's an integral part of setting up 802.11k and 802.11v.
Understood. Everyone should just be aware that updating properties of a wireless device (wifi-device) and/or wireless interface (wifi-iface) can result in changed information for the Neighbor Report Information Element. For those unaware, that is the long string of hex characters returned as the third element in the output from ubus call hostapd.<entry> rrm_nr_get_own.
That long string of hex characters carries a lot of important information and is only "static" so long as nothing in your /etc/config/wireless file is changed.
Here is what makes up that neighbor report information element:
Neighbor Report Information Element (IE) details
| byte | function | value | description |
|---|---|---|---|
| 1 | Element ID | fixed | identifies Neighbor Report IE |
| 2 | length | variable | depends on the number and length of optional subelements, minimum = 13 (decimal) if no optional subelements are present |
| 3-8 | BSSID | variable | MAC address of AP client is being advised to associate to |
| 9-12 | BSSID Information | variable | includes reachability of AP, security, capabilities of AP, mobility domain of the AP indicated by this BSSID |
| 13 | Operating Class | variable | Operating Class indicates the channel set of the AP indicated by this BSSID.Country, Operating Class, and Channel Number together specify the channel frequency and spacing for the AP indicated by this BSSID. |
| 14 | Channel Number | variable | Channel Number indicates the last known operating channel of the AP indicated by this BSSID. |
| 15 | PHY Type | variable | The PHY Type field indicates the PHY type of the AP indicated by this BSSID. |
| 16- | Optional Subelements | variable |
Table courtesy of: https://blogs.cisco.com/networking/why-the-802-11k-and-neighbor-report-are-important
2 Likes
Good point; that's indeed a pain for @account4538's approach - requiring a tedious change across all the APs if WiFi properties are altered. And it's interesting to see the breakdown of the information contained in these.
@Lynx and @account4538 I have 2 and soon 3 dummy RT3200 APs sharing the same SSID in 2.4, 5 GHz and configured in different channels and there is a wired back-haul that connects all the APs.
Since it is a big thread with very useful information and suggestions is it possible to sum up how to properly
configure 802-11k-and-802-11v on RT3200 ?