dcwhitworth Posted February 3, 2015 Posted February 3, 2015 We're having real problems getting some new Chromebooks to connect reliably and I wondered if anyone had any thoughts on what might be the issue ? We're pretty new to CBs and Google Apps so don't have much knowledge and experience to fall back on. Currently we are getting - Chromebooks failing to pick up the wireless even though it's specified in the Chrome policy in GA In that circumstance sometimes when the correct SSID is selected it then prompts for a wireless passcode which it should be remembering. IPs are delivered by DHCP reservations and several of these entries have been replaced with BAD_ADDRESS entries saying there's a duplicate IP (which there isn't) Our set up is - Meru Wireless Smoothwall filtering DHCP delivered by Windows 2008R2 DC In order to deliver filtering smoothly we want the Smoothwall to identify and let through the CBs on basic student level filtering. To do this we are allocating fixed IPs by using DHCP reservations so the Smoothwall will be able to recognise them. The wireless settings are delivered by Chrome policy from GA To set up the CBs, we connect to a setup SSID we have created (only available in our office), enrol them and move them to an organisational unit in GA which has the wireless settings we want. They are then tested and delivered to the users. The SSID they (should) auto connect to is hidden. I'd be very grateful for any thoughts on 1. Whether our set up is a sound one and if not what we should be considering doing and 2. What might be going wrong. Thanks
pcstru Posted February 3, 2015 Posted February 3, 2015 Check the chromebooks are on the latest firmware release. Check the Meru AP's are on the latest firmware. Doing both resolved similar issues for us.
jonnykewell1 Posted February 3, 2015 Posted February 3, 2015 Just found this online might be worth a try "Hi, According to current information, I think it related to name squatting. For windows clients we can protect DNS records via permission, only the computer who register the record has the permission to update it. But this mechanism doesn’t work for non-windows clients. You can enable DHCP name protection: Open DHCP console tree>Right click Scope>Properties>DNS>Configure>Check option Enable name protection. The root cause is that you have name conflict among these clients" could be worth a shot?
Kenny_G Posted February 3, 2015 Posted February 3, 2015 What make of Chromebooks are you using? We had a problem with Dell Chromebooks connecting to our WiFi.
dcwhitworth Posted February 3, 2015 Author Posted February 3, 2015 What make of Chromebooks are you using? We had a problem with Dell Chromebooks connecting to our WiFi. They're mostly Samsung, but we have some Dells too which have had some issues.
fiza Posted February 3, 2015 Posted February 3, 2015 I made sure all the Chromebooks had picked up the latest updates by browsing to Chrome://Chrome
tj2419 Posted May 18, 2018 Posted May 18, 2018 Did the suggested fix here resolve this issue or have you found another solution? Having the same problem here. Cheers
dcwhitworth Posted May 18, 2018 Author Posted May 18, 2018 Did the suggested fix here resolve this issue or have you found another solution? Having the same problem here. Cheers Broadly speaking the issues seem to have declined, possibly due to improved firmware. There is one issue which is ongoing in that Chromebooks seem to corrupt DHCP entries changing them to BAD_ADDRESS, never found a solution for this other than cleaning the DHCP data base periodically.
Recommended Posts
Create an account or sign in to comment
You need to be a member in order to leave a comment
Create an account
Sign up for a new account in our community. It's easy!
Register a new accountSign in
Already have an account? Sign in here.
Sign In Now