I have this problem om my macbook M3 Pro where it drops the wifi connection about every hour 60-70 minutes. the drops is about 10-15 seconds. and after that its perferct for 1 hour. this is my ping when it happens.
The rest of the time its perfect. so in about 1 hour it happens again. i timed it today between 2 drops and its about 70 minutes.
this is my settings on the wifi/ssid.
Anyone else having same problems with AP6/AP6-Pro and macbooks?
No issues for me. I also switched to WPA3 and enabled PMF this morning. Before that both were set to off. Pinging an external IP address isn’t a fair way to see if the issue is internal or external. I’d do a constant ping to an internal address and see if it drops out.
I did enable PFM and WPA3, stil the same issue.
this time i ping the AP6 internal IP.
ping from wired computer at the exact same time.
so there must be some bug with the AP6.
I run firmware 2.2h, but have had this issues before that aslo.
update:
after the WPA3 and PFM its even worse. Had to roll back
I’m not entirely sure if this is the same bug, but I believe so. In the past 2 days (since Thursday March 27) our Apple iPads (various generations) have stopped connecting to Alta AP6-Pro. The APs are running 2.2h, and I didn’t notice what version they were on before Thursday. In every case (at 3 locations, with 8 APs total) it’s fixed by disabling WPA3. It was not “mandatory”, just on. We didn’t have PMF turned on before, that may have been an issue initially, so it’s been off the whole time.
Our Android and Windows devices had no trouble when WPA3 was enabled, even on 2.2h. Not 100% sure whether they were using WPA3 or falling back to WPA2.
Some ideas, for what it’s worth:
Anything related to the following?
Seems like different bugs though?! @3rikhansen had problems (repeated packet losses / connection drop-out) before 2.2h and @On-QPro’s issues (unable to connect) appeared at the very time of rollout of 2.2h.
So WPA2/3 mode, to truly be transition mode, depends on PMF being set as optional. If PMF is disabled, then you have a glorified WPA2-only network.
Before we exposed PMF provisioning we automatically set PMF to optional for transition mode even if the toggle was off, but that’s where the problem happened. Because the PMF toggle was disabled it actually disabled PMF at time of upgrade, which is why (profile sensitive) devices had problems reconnecting automatically.
Disabling transition mode obviously is one option, or switching PMF to optional should’ve also fixed the issue. Another way would’ve been deleting and rebuilding the profile on each client device, but then you also would’ve had a glorified WPA2-only network.
Have you checked the signal on the Mac at time of issue? If you hold option and click on the Wi-Fi icon up by the clock it should show you connection information. I realize this is receive and pings are transmit, but it’s a start. It would be great to see it at the Control side, too, but timing that may be challenging.
Not enough here to tell what is or isn’t happening yet. The cyclical part is a little odd, but too little information to make that useful yet.
I can’t say I’ve noticed this while working and making phone calls wireless using my MBP, but it’s got an M2 Max, so previous gen. But I don’t use it all day every day, so maybe I just happen to use it at the right times, or am not on latency sensitive applications when it happens.
Are other client devices usable/okay when this one is having issues? Checking AP logs shortly after time of next issue may be helpful too, like if there was an interface state change being detected (whether real or a false positive), or something obvious like that then that could also explain it.
The AP logs are in /var/log/messages, and may rotate into messages.0 and possibly even messages.1, but generally the messages file should have the most recent content. You can transfer it directly via scp if an SSH key is installed, or you can copy the content when viewing from shell (whether true shell, or web terminal). Web terminal can be accessed by holding shift and clicking on the AP name on the Network tab. And cat /var/log/messages should be suffice. The logs are in UTC time zone, so they won’t be local, so that helps when looking at it.
I am happy to help review a the log output if you want to share them. If so, please send via direct message, or I can send you my email if you’d prefer. I would also need to know the last known time of occurrence if you’re sharing logs for review.
I have been looking into this a little bit more.
Here is my recent drop and from my mac pining the AP Im connected to.
Its the same time. just different time zones on the devices.
This is my mac signal strenght.
and the last part is the log on mye AP when the drop happens
Mar 30 18:59:24 OpenWrt daemon.alert rc: bad name: 0x5d7
Mar 30 18:59:27 OpenWrt daemon.alert rc: bad name: 0x5d7
Mar 30 18:59:30 OpenWrt daemon.alert rc: bad name: 0x5d7
Mar 30 18:59:33 OpenWrt daemon.alert rc: bad name: 0x5d7
Mar 30 18:59:34 OpenWrt user.notice root: scanning...
Mar 30 18:59:36 OpenWrt daemon.alert rc: bad name: 0x5d7
Mar 30 18:59:39 OpenWrt daemon.alert rc: bad name: 0x5d7
Mar 30 18:59:42 OpenWrt daemon.alert rc: bad name: 0x5d7
Mar 30 18:59:45 OpenWrt daemon.notice hostapd: FT(RRB): src_addr=b6:11:9d:7d:f8:03 type=1
Mar 30 18:59:45 OpenWrt daemon.notice hostapd: FT(RRB): src_addr=b6:11:9d:7d:f8:03 type=1
Mar 30 18:59:45 OpenWrt daemon.notice hostapd: FT: Received PMK-R1 pull for STA de:8f:c8:58:5d:f2
Mar 30 18:59:45 OpenWrt daemon.notice hostapd: FT: RRB-OUI type 2 send to bc:b9:23:00:71:88 (len=266, iface=br-lan)
Mar 30 18:59:45 OpenWrt daemon.notice hostapd: FT(RRB): src_addr=b6:11:9d:7d:f8:03 type=1
Mar 30 18:59:45 OpenWrt daemon.notice hostapd: FT(RRB): src_addr=b6:11:9d:7d:f8:03 type=1
Mar 30 18:59:45 OpenWrt daemon.alert rc: bad name: 0x5d7
Mar 30 18:59:45 OpenWrt daemon.warn hostapd: b6:fa:07:8d:f8:03: L2UF RXed from eth0/b6:11:9d:7d:f8:03: Dropping de:8f:c8:58:5d:f2 sjsz 58
Mar 30 18:59:45 OpenWrt daemon.info hostapd: 5l4Ql_AeFP: STA de:8f:c8:58:5d:f2 IEEE 802.11: disassociated
Mar 30 18:59:45 OpenWrt daemon.notice hostapd: 5l4Ql_AeFP: AP-STA-DISCONNECTED de:8f:c8:58:5d:f2
Mar 30 18:59:45 OpenWrt daemon.notice hostapd: wpa_driver_nl80211_set_key: ifindex=20 (5l4Ql_AeFP) alg=0 addr=0xb32cb8 key_idx=0 set_tx=1 seq_len=0 key_len=0 key_flag=0x20
Mar 30 18:59:45 OpenWrt daemon.notice hostapd: wpa_driver_nl80211_set_key: ifindex=20 (5l4Ql_AeFP) alg=0 addr=0xb32cb8 key_idx=0 set_tx=1 seq_len=0 key_len=0 key_flag=0x20
Mar 30 18:59:48 OpenWrt daemon.alert rc: bad name: 0x5d7
Mar 30 18:59:48 OpenWrt daemon.info hostapd: 5l4Ql_AeFP: STA de:8f:c8:58:5d:f2 IEEE 802.11: disassociated
Mar 30 18:59:48 OpenWrt daemon.notice rc: [2025/03/30 20:59:48:6089] N: JSON: {"reqStats":{"start":1743361127,"stop":1743361188,"period":"seconds","clientId":"moEQoNdm0WXhES2A4ZKE"}}
Mar 30 18:59:49 OpenWrt kern.warn kernel: [77373.792484] 5l4Ql_AeFP: STA de:8f:c8:58:5d:f2, VLAN1, Type 0
Mar 30 18:59:49 OpenWrt daemon.notice hostapd: wpa_driver_nl80211_set_key: ifindex=20 (5l4Ql_AeFP) alg=3 addr=0xb39c48 key_idx=0 set_tx=1 seq_len=0 key_len=16 key_flag=0x2c
Mar 30 18:59:49 OpenWrt daemon.info hostapd: 5l4Ql_AeFP: STA de:8f:c8:58:5d:f2 IEEE 802.11: associated (aid 5)
Mar 30 18:59:49 OpenWrt daemon.notice hostapd: 5l4Ql_AeFP: AP-STA-CONNECTED de:8f:c8:58:5d:f2
Mar 30 18:59:49 OpenWrt daemon.notice hostapd: wpa_driver_nl80211_set_key: ifindex=20 (5l4Ql_AeFP) alg=3 addr=0xb39c48 key_idx=0 set_tx=1 seq_len=0 key_len=16 key_flag=0x2c
Mar 30 18:59:50 OpenWrt daemon.alert acsd: Caught SIGUSR2. Processing new scan data
Mar 30 18:59:51 OpenWrt daemon.alert rc: bad name: 0x5d7
Mar 30 18:59:54 OpenWrt daemon.alert rc: bad name: 0x5d7
Mar 30 18:59:57 OpenWrt daemon.alert rc: bad name: 0x5d7
Mar 30 19:00:00 OpenWrt daemon.alert rc: bad name: 0x5d7
Mar 30 19:00:03 OpenWrt daemon.alert rc: bad name: 0x5d7
Mar 30 19:00:06 OpenWrt daemon.alert rc: bad name: 0x5d7
Mar 30 19:00:09 OpenWrt daemon.alert rc: bad name: 0x5d7
Mar 30 19:00:12 OpenWrt daemon.alert rc: bad name: 0x5d7
Mar 30 19:00:15 OpenWrt daemon.alert rc: bad name: 0x5d7
Mar 30 19:00:18 OpenWrt daemon.alert rc: bad name: 0x5d7
Mar 30 19:00:21 OpenWrt daemon.alert rc: bad name: 0x5d7
I have been looking into this long forum posts talking about the same errors i see in the log.
And the last thing, i hade a ping drop when i added ssh key to the controller to access the ap. i saw that the cpu on the ap got over 60%, can high cpu load be an issue?
i have about 20 devices always conencted to this AP.
I am experiencing repeated dropping with iPhones, iPads, and MacBooks now. I have not had my Alta equipment hooked up for a while, but I set it all back up in preparation for a new home. Immediately upon setting it all back up, all of my Apple products are disconnecting and reconnecting steadily. I had to pull the gear back out again until something is figured out. I am going to setup a little test bench with a brand new SSID and password and see if that helps. Perhaps we are going to have to create a new SSID and re-attach everything.
EDIT: I can already confirm that simply making a completely new SSID does NOT solve the problem. Here are the setting that are still causing my Apple devices to constantly disconnect and reconnect. They are basic as can be.
I’m also seeing connectivity issues with our Apple products. High latency and packet loss and connecting to APs on the other side of the building. Fast roaming is off and WPA3 is off.
What networy type under WiFi security are you selecting? I’m using standard and I’m not seeing any issues.
Im doing the Standard on the SSID i have problems with.
I’m using standard, too. Not sure why you’re having issues.
Standard for me as well. I have sent log files to the team for further investigation.
So based on the logs that you’re sharing, during the time of issue your device is in the middle of roaming, to the AP it’s connected to, and then roaming back. That was something I was wondering about—if your device was flapping between APs, and it looks like that’s more likely than not. Eventually after flapping back and forth for a while latency will be visible, so that could be what you’re seeing here (emphasis on could).
I think a good next step for you specifically is disabling Fast Roaming temporarily to see if the behaviour changes, or not. This isn’t a fix, this just basic a/b testing as if it is flapping it should help mitigate that or at least greatly lessen that.
I see this too, and it’s still working. There are reports going for years on OpenWRT/hostapd, after a quick search on GitHub. This seems like a benign upstream issue, but I can’t say I’ve extensively tested/verified this myself.
Some provisioning changes may cause a brief loss of connectivity. I’m not sure expectations with an SSH key, but I’ll check and follow up about this.
I have 1 access point connected. Even disabling fast roaming has not stopped the disconnects. Although it has slowed them down some.
The problem here is that my mac is not in the AP log. Other devices is “flapping when roaming” , but my mac address on my macbook is not in the log.
So when other devices is flapping, it looks like the “driver” is crashing/freezing? impacting other devices also?
Unfortunately I couldn’t tell that because the MAC of Wi-Fi interface on the MBP was trimmed from the screenshot. So I did make an assumption based on timing and what I saw. If it’s not logging anything on the AP, then the logs provided are not useful, simple as that.
If it’s not triggering logs on the AP, then we’ll need to lean on Wireless Diagnostics on the Mac so we can see what’s wrong from its perspective. There is a guide HERE on how to initiate that. Basically start it next time the issue is observed, and the we can look at the contents of the container that it generates.
This shouldn’t be the case. If I try hard enough I 100% can make devices flap while using multicast services from other devices streaming over Wi-Fi without so much as a second interruption in an audio stream… so I would have to say that while it’s not impossible, it’s highly unlikely.
Is Fast Roaming disabled yet? That’s still my next step.
EDIT: I’m going to DM you my email, make it easier for log exchanges, etc. I’m curious and would like to help to get to the bottom of this. I just don’t see a smoking gun yet. While FT is still a suspect, it definitely is not clear it’s the cause of the issue either, but I still see value in temporarily disabling it, as a clear a/b test .
Fast Roaming doesn’t give any benefit when it’s a single AP in the cell. I saw a log snippet yesterday, but it did not contain anything useful, it showed 1 device trying to reassociate but the AP didn’t recognize the old session, then another client and that client both associated.. So whatever was or wasn’t happening wasn’t visible in the log file that I saw.
I don’t mean to duplicate efforts and am not aware of further progress on your case. Happy to help if I can.
