Would that require me to configure three SSIDs on each device that would roam in my household? Including new/future devices (eg., guests that visit my house)?
Issue is still happening after your last suggested change, FYI.
Remove the OpenBSD router and try to install or use a router with OpenWrt with the latest recommended version.
Maybe you have this same bug with the OpenBSD router, which has already been fixed in OpenWrt 23 onwards:
Bug (Click to read)
1 Like
This would be really interesting. With all the optimizations we've made to the OpenWrt APs, we hadn't considered if it might be an issue upstream. This is totally worth trying, especially because I don't see anything on the OpenWrt side that would be responsible for the reported issues.
1 Like
Itâs merely a suggestion to find a workaround. For practical purposes the Apple devices support sharing the AP client configs. Also the APâs support multiple SSID, so you could add temporarily one for testing.
â update, as per pshermans comment below â-
workaround is not the right term to use. What is meant is that if this works - the issue lies with the roaming mechanism, to elucidate the finding in post Debugging wifi drops on Apple devices - #77 by neezer
No, this is not worth it. Why? Because it isn't actually roaming anymore. Roaming occurs when the client device has the ability to choose between two or more APs that are broadcasting the same SSID. If the SSIDs are different, the client will avoid changing to a different SSID until the signal effectively drops out entirely. In contrast, when the APs are broadcasting the same SSID, the client should be periodically evaluating the relative signal quality from each of the APs in range and then it will make a choice to switch as needed (based on the logic in the OS/wireless stack of the client) to optimize performance.
The reason that the client will not 'willingly' roam to another SSID is simple -- usually that is indicative of a different network (whereas it is assumed that the same SSID means the same network). A different network means that any active connections will likely break and need to be entirely re-established. For example, let's just say you are on a facetime call outside your home and you walk a few feet towards your neighbor's home (who's wifi credentials are already known to your iPhone)... if the iPhone switches to your neighbor's wifi and thus their internet connection, the facetime call will drop entirely and will have to be re-initiated. This would be true of any ongoing connection -- be it streaming, downloads, etc.
Likely not as a permanent solution, however for troubleshooting this would rule out dtim settings and alikeâŚ
@neezer just curious: did you test usteer or dawn if maybe that would help?
Example settings for usteer you can find here
It helps me with some clients, to switch faster from one ap to other
No,this wonât help with troubleshooting. As long as there is some signal available, the clientâs connection to a given ssid will remain sticky. This is the opposite of roaming.
Using different ssids would be a waste of time and would not bring the op any closer to resolution.
It does, as it is still unclear what is causing this behaviour : Debugging wifi drops on Apple devices - #77 by neezer
Itâs important to arrive to a reproducible situation for this behaviour. Otherwise itâs just opinions.
Just a quick side note and a bit OT not related to the OPâs current issue:
Appleâs iOS apps like FaceTime, Siri, Apple Music etc, use MPTCP (Multipath TCP) to maintain connections through all available transports allowing them to roam independently of each other.
I'm less convinced this would help, as I've never had this issue with any of my wired clients.
For what it's worth, I have updated all our APs at home from stock firmware to v23.05.4 a couple of weeks ago. So far(!) I havenât noticed any issues other than tweaking channels and signal strength in each room to ensure smooth handoffs between the APs.
It's a mix of an old D-Link DAP-2660, a more modern DAP and three pieces of first editions Asus Lyra MAP-AC2200 from 2018 with Tri-Band och MU-MIMO, total of two APs on the upper floor and three on the main floor.
We're a typical Apple family with both old and new iPads, iPhones, and MacBooks. The oldest iOS devices we use are a couple of iPad v3 minis from 2014 with iOS 12 while the newer iPads and iPhones are running the latest iOS 17. Both kids are using older MacBook Retinas from 2015 with macOS 11 (Big Sur) and our own Macbooks are running the latest macOS 14 (Sonoma).
The main router is a Mikrotik RB3011UiAS with RoS v7.15.3 and all the APs are configured with 802.11r (FT).
1 Like
I saw those, and no, I haven't tried either. From what I can tell, though, both of those would be an improvement? As in, not having either should be causing issues, correct?
Happy to hear you're not having issues! Maybe the issue is somehow more to do with the Zytel NWA50AX units?
Wish someone else was running that hardware with OpenWRT using Apple devices for comparison...
1 Like
You can always try using AC mode instead of AX, but rather than going through a bunch of pointless trial and error, Iâd suggest looking for the actual root cause by checking the WiFi logs on the iOS devices that are having issues. It's pretty easy to access the logs and then you wonât have to guess anymore whatâs causing the issue and just fix the real problem.
Wi-Fi logging for iOS/iPadOS:
How iOS, iPadOS, and macOS decide which wireless network to auto-join
2 Likes
Ahh, didn't realize I could get logs out of my iOS devices. Thanks! This should be really helpful... I'll try to get to this later today.
On a related note, I got kinda lucky last night, as my wife received a new work laptop (brand new Macbook) that experienced the issue, giving me an opportunity to dig around with the CLI tools I'm used to.
I'm thinking the issueâor one of themâmight be DNS related. This failure matched the case described in my original issue where the device is associated with the AP but has no internet, and toggling WiFi on/off doesn't work... had to temporarily join the neighbors WiFi then back to mine.
I noticed that the System Preferences showed the correct, advertised DNS server when inspecting details about my network, but scutil --dns did not list the same server as any of the resolver entries, and thus all DNS queries were failing.
I could ping6 the DNS server address, so I know the machine had an active route back to the server.
Is there a packet/frame/whatever that is sent out by OpenWRT on a "handshake" operation (forgive my loose terms, I don't know the actual ones) that contains the DNS server info that is maybe being sent incorrectly? Or is arriving incomplete?
Yeah, DNS could definitely be the issue since your Wi-Fi stays connected while everything else seems stops working. DHCPv6 provides DNS but you can set it manually when troubleshooting or when it happens again. For example, you can use Cloudflare's 2606:4700:4700::1111 or 2606:4700:4700::1001.
Do you hand out your ISP's DNS directly to the clients, use a forwarder on the router, or have an in-house 'real' DNS server on the BSD router?
EDIT:
Come to think of it, I actually had an issue where the DNS was acting weird and then stopped working completely. It turned out it was because I had manually set up a forward to our ISP on the default gateway, and they installed two new DNS servers with new addresses and later shut down the old ones. Lesson learned: always let the router dynamically update the forwarder from the ISP or use a big provider like Cloudflare.
I run my own DNS server on my OpenBSD router (unbound) that uses Quad9 as the upstream.
1 Like