Wireless

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.

Any thoughts?

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?

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.

Any thoughts?

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.

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?

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.

Any thoughts?

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?

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.

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?

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.

Any thoughts?

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. 

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?

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.

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?

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.

Any thoughts?

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.

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. 

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?

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.

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?

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.

Any thoughts?

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.

Any thoughts?

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.  

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.

Any thoughts?

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.  

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.

Any thoughts?