cancel
Showing results for 
Search instead for 
Did you mean: 

Chromebooks not connecting and/or losing connection

erin_miller_708
New Contributor II
We have had our Ruckus network set up for almost two years without any problems. Over the last six months I am getting increasing complaints about Chromebooks not being able to connect or losing connectivity randomly.

Tech support keeps telling me the clients are switching between 2.4ghz & 5ghz quickly which is causing the problem. They are saying the issue is "Reason 3" meaning the client is moving between APs or too far from an AP.

These clients are sitting at their desks where they have always had reliable connectivity. They will be working without a problem and suddenly drop connectivity for hours at a time. Then, for no apparent reason, connectivity will return. When they lose connectivity, their computer will still show 2 or 3 bars (with a 40% or higher signal strength.)

I am getting nowhere with tech support. The problem is beginning to affect more of my users. It happens with more than one AP.

We are in the middle to transitioning the majority of our staff to Chromebooks so I need this fix.

I have upgraded to the most recent firmware.

Anyone have any ideas!?!
19 REPLIES 19

jamie_walmsley
New Contributor III
Are these disconnections happening after a channel fly channel change event? Im seeing a similiar problem myself since upgrading to 9.13 on R700s (except its with Mac devices) and its the channel change event triggered by channel fly thats causing it. Check logs for a channel change and see if the disconnections happen just after that. it could be that the client devices arent supporting 802.11h CSA's properly and/or something has changed in 9.13. Im still working with Ruckus carrier support to get to the bottom of our issues. Ive been working with a network of ~30K Ruckus AP's for a good few years now and in my experience channel fly and the subsequent channel changes are the cause of *alot* of random disconnections I have investigated.

id try disabling channelfly as a test if your operating in a relatively "clean" RF environment - which it sounds like you may be are given that its a school.

First of all - thank you for the confirmation of a problem that many of us have been struggling with.

I'm curious as to whether you've observed this disconnection problem across a variety of client devices?

Hi Bill,

In my personal experience its been a variety of different client devices - we have pretty much every type of consumer device spread across our network (We're a student ISP) so arent tied down to any specific vendors. When you have such a mixed variety of different client devices with different wireless chipsets/ drivers/firmwares etc then unfortunately you are always going to get some that dont behave as they should.

For us, running channelfly definitely has its benefits - our AP's are quite often sat in environments where you have users running their own AP's, contributing massively to co-channel interference. Personally, my opinion is that if your operating in a clean environment i.e you dont have alot of neighbouring AP's to deal with I would ditch channel fly and statically set channels + power levels as I believe leaving it on would cause more harm than good.

Hope that helps

david_henderson
Contributor II
I have read many articles online about how to setup channelization on wifi networks
I have also talked to several people who for a living design and setup wifi networks

The consensus seems to be around fixed power/fixed channel designs. Every manufacturer whether Ruckus, Aruba, Cisco, etc. have technology built into their systems to automatically select the proper power level and channel and adjust these on the fly. Again, the consensus seems to be that these systems do not work well and going to a fixed power/fixed channel design while more work, in the end yields a more stable and responsive setup.

Your thoughts?

hyosang_choi
Valued Contributor
Hi guys.

I recommend checking dhcp server status such as latency for dhcp response.

I had experienced similary symptom, and found problem related highly late responde from dhcp server.

If your dhcp server have problem, he send very lately respone against dhcp request.

In my case, after replacing dhcp server, it disappeared issue.

Regards.