Higher Education

Is anyone out there seeing issues with Chromebooks on 802.1x SSIDs?  I have seen 2 Chromebooks already with extremely poor performance on 802.1x SSIDs, and just fine on open SSIDs.  Symptom is basically frequent disconnects/re-connects often enought is unusable on 802.1x SSIDs.  Tested both TTLS and PEAP, same results.

---

@mlew2433 wrote:

Is anyone out there seeing issues with Chromebooks on 802.1x SSIDs?  I have seen 2 Chromebooks already with extremely poor performance on 802.1x SSIDs, and just fine on open SSIDs.  Symptom is basically frequent disconnects/re-connects often enought is unusable on 802.1x SSIDs.  Tested both TTLS and PEAP, same results.

---

Please make sure that both are up to date.  Another user had problems, as well, and updated them and their problems went away.  It would be great to hear what other users experience on chromebooks, as well.  There could be issues with Chrome:  https://code.google.com/p/chromium/issues/detail?id=297607

 

Yup, first thing I did was updating them to the latest patch, released September 13th.  Still the same issue.

We are having the same issues as well here at DPS.  Are your SSIDs broadcast?  Ours are not.  We are trying to decide if that would help at all.  What we are hearing from Google is they have a problem wtih 2.4 and 5.  Their suggestion to us was to setup and SSID that is on 5 only.

We are having the same issue at Murray State.  I haven't had a chance to troubleshoot it yet.  We are running Clearpass 6.2 Patch 2, with Cisco 5508 Wireless Controllers 7.4 MR1.  Our SSID's are broadcasting.

And, we now also see the same behavior on Windows Surface Tablets running 8.1.  On our 802.1x SSID, connects, but then it drops and reconnects constantly.  Open SSID and pre-share key is fine.  I will do some troubleshooting tomorrow, but any suggestions if you went through this already are highly appreciated..  :smileyhappy:

Just to add to the list - we are seeing the same thing here with Surface tablets.

Just got our hands on our first unit for testing and cannot connect to 802.1X via Clearpass - to be fair - have done no troubleshooting beyond checking Clearpass logs to see that the Surface device (and user) is being profiled correctly and alloacted the correct role   - but response from the Surface tablet is that Wreless conenction is limited and we get a 169.X.X.X self assigned address. Not sure if DHCP  or Aruba related  - but interesting timing seeing similar issues with other users and Surface.

Wally

I observed a surface issue wherein it did not like non-40MHz 11n channels. It would disconnect intermittently. Enabling 40MHz resolved the issue. . . fwiw.

I isolated the issue on both Chromebook and MS Surface RT.  They don't like WPA2-802.1x or PSK on NATed addresses.  Confirmed this several times through different tests.  At this point I'm having users connect to our guest open SSID.

Please share your tests. We?re going to be rolling out NAT for our student mobile devices, so I?d like to get in front of this issue if possible. What ArubaOS are you running? Is this a verified issue at Aruba? What about NAT breaks things for these two device types?

- Ryan -

Aruba 6.2.1.3.

Aruba AP-135/125

NAC by Impulse

NAT by Cisco ASR and ASA

Tested on both NATed and non NATed subnets.  NACed and Non-NACed.  Open, PSK, and 802.1x. 

Behaviour is:  Device can connect, but network connectivity breaks in about a minute or so.  Still have an IP, still connected as far as the controller is concerned, no strange behaviour on packet captures.  But cannot get pass the gateway.  Can ping the gateway, but nothing passed that.  And this is only on 802.1x or PSK. 

This might be particluar to our enviroment, not sure, but hopefully this gives you an idea.

Does the client post-event have an arp entry for their gateway? Does the router have an arp entry for the client? Does the controller have an entry for the client IP in "show datapath user table", "show datapath route table", and "show datapath route-cache table"?

---

@mlew2433 wrote:

Aruba 6.2.1.3.

Aruba AP-135/125

NAC by Impulse

NAT by Cisco ASR and ASA

Tested on both NATed and non NATed subnets.  NACed and Non-NACed.  Open, PSK, and 802.1x. 

Behaviour is:  Device can connect, but network connectivity breaks in about a minute or so.  Still have an IP, still connected as far as the controller is concerned, no strange behaviour on packet captures.  But cannot get pass the gateway.  Can ping the gateway, but nothing passed that.  And this is only on 802.1x or PSK. 

This might be particluar to our enviroment, not sure, but hopefully this gives you an idea.

---

mlew2433,

 

Is there any way that you could turn off NAC on the VLAN that you are testing those devices on to see if you still have the same issue?

 

Ryan, checked and all looks good.

CJoseph, first thing I did is get NAC out of the mix, same results.

 

When I get a breather this week I'll open a TAC case see if I can dive in a bit deeper.

 

Thanks for the suggestions.

Had same issue here with Surface RT tablets on Bridgewater Ma campus, used this link and now all are working, campus environment cisco 5508's etc.. Cisco APs, Good luck, should work for you:

 

 

• First of all, go to Start Screen by pressing the Windows button your Surface tablet. In Start Screen go to Search Charm by swiping from right and selecting ‘Search‘.
• Type in ‘cmd’ in the ‘Search’ box. ‘Command Prompt‘ would be showed in results.
• Swipe down on the Command Prompt tile and the app bar will open. Select ‘Run as administrator’ from the app bar.
• Command Prompt will open on the desktop. Type or copy and paste the following in the command prompt

netsh int tcp set heuristics disabled

• Press ‘Enter’. You would see ‘Ok’ as answer. Now, type the following:

netsh int tcp set global autotuninglevel=disabled

• Press ‘Enter’. You would see ‘Ok’ again. Type the following now:

netsh int tcp set global rss=enabled

• Press ‘Eneter’ and you would see ‘Ok’.

REBOOT YOUR UNIT.

I did do this, but didn't make a difference.  However, I don't remember if the last setting was set to enabled or disabled.  I'll have to try it again when I get my hands on one.

Yes double check, because i had same issue here and three units worked.

oh also there is a show command at the end you can do:

 

netsh int tcp show global

• This time you will see a couple of settings and all should be disabled except one or two. If, all are disabled except one you are good to go.

  I dont have the specific items to look at handy right now.

• And to be clear I am referring to the Surface RT tablets, not the chromebooks, haven't played with those yet.

Thanks Robert.  I have a Chromebook on my test bench, no Surface RT yet, was working with a user's one.  I'll have to order one soon.

Cool, Yea our network setup is very similiar to yours based on what you wrote in the chain, If I see anything on the chrome will post. Funny I do see a ticket out there for issue "not being able to get on campus wireless with chromebook " LOL, Good luck. Let me know as well thanks.

I have a first gen Surface Pro.  I saw similar issues for the first few months I had it.  When i connected to .1x networks, it would work fine for an indefinite period of time and then drop into a limited connectivity mode that was difficult to correct.  If you do some web searches, there have been a ton of posts about it. It happens across a host of different AP types.  There are debates about exactly how/why/when you see the issue with a lot of peopel saying it has to do with 40 mhz channels.  It was so bad i carried around a USB wifi stick to make it work

 

That problem has been completely resolved for me for the past month or two.  There was a driver update that fixed it.  But that driver update, didn't properly install through windows update.  Windows update didn't get some of the registry settings updated that needed to be updated.  To get the fix to properly apply, I had to uninstall the driver, but not delete it. 

 

When you uninstall it, you have the option to delete it or not.  If you don't delete it, the driver will reinstall automatically on reboot.  At that point, everything should be healthy and good.

 

-Peter

Both Chormebooks and Surface Tablets work fine for me on public IPs and 802.1x.  Is only on private IP space NATed subnets I am having the issue, which is basically all our nets right now since we moved to private/NAT space a few months back.

---

@mlew2433 wrote:

Both Chormebooks and Surface Tablets work fine for me on public IPs and 802.1x.  Is only on private IP space NATed subnets I am having the issue, which is basically all our nets right now since we moved to private/NAT space a few months back.

---

mlew2433,

 

There has to be something in addition to private subnetting is creating the issue.  Did you do any user debugs on those devices to see what is happening while this occurs on the controller?

 

No two networks are the same, so while it works with private natted networks elsewhere (almost 100% of K-12s have this setup), we have to find out what specifically it is about your private network that the Chromebooks do not like.

Packet capture does not show any strange behavior.  TAC thinks is an issue with the Chromebooks since all looks good from the controller side.  Want to mention again that NATed open network are fine, is just 802.1x networks.  Moreover, not all Surface RTs or Chromebooks are affected, seems to be a particular year or chipset but can't find the common denominator yet.  

We have recently discovered that our Chromebooks now support wifi single sign on correctly and manage vlan switching from a guest / provisioning wifi ssid to a user ssid using 802.1x correctly!

 

This is great as so far this is one of the only devices where I have seen this process handled cery gracefully with no input from the end user.

 

Background:  We utilize Google Apps Directory sync to keep our users/ou's in sync with Google Apps from our AD structure, we also handle password sync between AD and Google Apps, and also have 802.1x user based authentication (PEAP MSchapV2) in place.  We have set the device to pre-autehnticate to our guest/provisionsing network using a common username/password, and then set our chromebook user settings to use the username variable for the 802.1x authentication.

 

The result:  A user powers on the chromebook and the device has limited network access, and can login a user to their Google Account.  As soon as the login process completes the device disconnects from the guest network and automatically connects to the student SSID utilizing the username/password used to login to the chromebook.  

 

In the aruba logs I must say this is the most gracefull SSID / re-auth I have ever seen, and the device never seems to get stuck on the old VLAN (like I have seen on so many windows machines...)

 

 

Update.  Chromebooks work fine if I disable MPDU Aggregation under High-throughput SSID profile, however, this reduces performance significantly for other 802.11n clients.

Marcelo,

 

Have you made any progess on the Chromebook/802.1X issue? We have discovered the newer Chromebook models suffer with connectivity issues unless MPDU is turned off.

 

Ted Moskalenko

Lead for Mobile Technologies

University of Pennsylvania

 

Ted-

 

I had a TAC case with Aruba on this issue.  The issue is a bug that was fixed in 6.3.1.3.  If you updated to 6.3.1.5 last week you should not hve to disable MPDU agg and BA MSDU.  Here is my other post:

 

http://community.arubanetworks.com/t5/Unified-Wired-Wireless-Access/Acer-c720-Chromebook-woes/td-p/150846

 

mbonadie

Excellent! Thank you for sharing!

Ted-

 

No problem.  And thanks for the kudos!  

 

Matt

For sanity check, which bug number is this listed under in the release notes? I don't see anything listed for the bug number that is on the other post refernced in the release notes.

The bug that is said to fix the Chromebook and the Surface issue is fairly generic and does not mention Chromebooks or Surface tablets.  It is the same bug in the thread here:  http://community.arubanetworks.com/t5/Education/Surface-2-RT-Pro-Pre-N-AP-802-1x-WMM-Fail/gpm-p/152184#M705

 

Let me ask to see if we can get something more specific put out.

I wondered if it was the same bug affecting those 2 clients as well, because that was the same trick Aruba suggested some time ago for us with Surface Pro's.  The bug ID I got was an internal one.  #96746

 

mbonadie