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.
3 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 ?
After upgrade to 23.05.0 I now see:
root@OpenWrt-1:~# ubus call hostapd.wlan0 rrm_nr_get_own
Command failed: Not found
And I now see that it is because all the names have changed, e.g. to wl0-ap0.
1 Like
Hi there, i read the whole thread and i tried to make fast roaming work but as soon i change the file /etc/config/wireless my wifi ap is disabled and wont enable, i found out that removing
option bss_transition '1' option wnm_sleep_mode '1'
my wifi is working again.
I tried this on both my ap that are using OpenWrt 23.05.0 (TP-Link TL-WR841N v13) and on 22.03.5 (ASUS RT-AX53U)
Can anyone please help
EDIT: Wpad full was not installed, after installing Wifi ap is working as it should
After so many trials and errors i forgot to install them on this devices 
Hi all,
Do I need this if I'm using 802.11s to create a mesh network between my main router/gateway and my 2 dumb APs?
Yes. The 802.11s network is a backbone between the router and the APs. You will create a separate SSID for the client devices (laptops, phones) to connect to. On that SSID, you need proper 802.11k and 802.11v configuration for the client devices to roam smoothly.
1 Like
Thanks @patrakov. What is 802.11r then because that's what I enabled on the SSIDs "802.11r Fast Transition". I see other options like 802.11k RRM and the subsequent options with info mentioning 802.11v but I have no idea what these actually do.
I watched the video created by OneMarcFifty about setting up Mesh 802.11s and another one for enabling fast roaming but he did not mention 802.11k and 802.11v
802.11r itself (alone) makes fast transitions possible.
802.11k/v only provide the clients with more information about the AP (e.g. how 'full' it is) and the environment (there's another good AP nearby) to make better roaming decisions.
5 Likes