Log in to ask questions, share your expertise, or stay connected to content you value. Don’t have a login? Learn how to become a member.
We're deploying Mist AP45s across part of our district, and we've noticed an odd issue, specific to Chromebooks.
We have 3 APs which Chromebooks refuse to stay connected to a specific WLAN - these Chromebooks will connect on that WLAN on other APs at the site which have been deployed with the same settings from switch to WLAN, and will also connect to a different WLAN on the same AP. All these APs were from the same purchase order, and presumably part of the same batch, and all the affected Chromebooks are the same model.
Presentation of the issue is typically: Device is authorized and associated, DHCP success, Gateway ARP success, DNS Success, Client deauthentication - Reason code 3 "Deauthenticated because sending STA is leaving (or has left) IBSS or ESS"
This error code makes it seem as though the sending station is roaming away from the AP, but several tests have verified that the device can be stationary, have the same RSSI from start to finish, and still disconnect with that reason code within a minute or two of connecting.
The disassociation reason code is based in what is been seen on the air as the leaving station sends a disassociation packet to the AP telling it's leaving, so that is true.
You need to re-focus your troubleshooting into why those devices are leaving?
Check if they are receiving a valid IP address once conneccted and before dis-associating, if not, maybe missing the mapped VLAN on that AP.
Can you check if the SSID is been broadcasted from that AP and you are not connecting to another AP which could be far from there and maybe with very low signal/snr?
I have verified that the devices are able to receive an IP address in the brief minute or so that they are willing to stay connected. I have also verified that the SSID is broadcast from these APs, and the SSID as working from these APs with other devices that are not this specific model of Chromebook. The devices that are dropping are showing good signal strength at time of association, and around the same signal strength at the time of disassociation - average RSSI of around -40dBm.
Interesting issue! Would you be willing to move one or all of the "problematic" APs? It may be that the Chomebooks are having issues with something in the area those APs are located in, or it would show that the problem follows the AP.
Have you had Marvis troubleshoot the Chromebooks? In Insights, you can follow the roaming of a client and see which AP it roams to. If they actively disassociate, no new AP will show of course.
Are you sure there are no rouge APs with the same SSID in that area?
We swapped out the problematic APs with some spares we were able to scrounge up, and this fixed the issue, so that rules out rogue APs (the location of this site also made rogue APs unlikely as it is very remote, and no rogue APs were showing in the security panel). Prior to the swap, I had checked Marvis, but all it was showing was that the devices were seen leaving the station, same as if the device was physically moved away, with no further attempts to connect to other nearby APs.
I'm planning to RMA these APs now that we've been able to swap them out, there's clearly some bad juju going on with these specific APs.
As a follow-up to the follow-up, after swapping out the APs, the problem came back after a while. This time, however, a honeypot SSID was detected. Sure enough, when our vendor replaced the old APs, one was missed in the corner of a small office. It was unplugged from our switches, but still powered on with a PoE injector. Once this AP was removed, the problems stopped. Seems like Ubiquiti has this nice feature where it'll keep broadcasting its SSIDs even when not connected to data, which is a lovely way to give us a headache.
I'm so glad the problem was identified! I am a bit surprised that Mist didn't pick the honeypot AP up. I'll just might have to do a small test to see if it will in my lab. I asked for a rogue AP, but meant another AP with the same SSID, which is called a Honeypot AP in Mist.
As a matter of fact, the function to disable the radios if no connection is established was only added to Mist in May this year (2023): https://ideas.mist.com/forums/912934-product-features/suggestions/39107065-stop-radio-when-ap-has-no-network
We are a school district that we put up AP-32s and we are experiencing the same issues but seems to not be limited to a subset of APs but all the APs.
Two quick thoughts:
I have seen a number of issues lately with Cromebooks and some HP printers, where the security settings have been changed on the AP, but the client refuses to update to the new settings. If that's the case, try creating a new SSID to test or on the Cromebook forget the previous SSID/Network so that when it connects it will only have the new settings.
Are you using WPA3 or WPA3 with WPA2 Transition? I have seen some clients not work in that scenario, until additional client updates were applied. What security are you using?
Lastly, see if an updated version helps Firmware - Mist or you can always open a support ticket in Mist, I personally have had nothing but great results with support.
Hope that helps
Hi Did you ever find a solution to this?We have deployed a number of AP34's in a location and are seeing what sounds like the same issue.We are running WPA2 - switched from WPA3 with Transition because we thought it might be something related to that. The issue persists.
Running suggested firmware version.
We see a lot of client deauthentications in the log both on the guest and internal wifi