Wireless Access

Okay, just polling the message boards to see if anyone is see the same problems.  I am pretty sure that my issue is lousy roaming & supplicant drivers, but I can't seem to find any other posts about Chromebooks with any resolutions.  Here is the layout of the wireless network:

1. University network which is pretty much BYOD
2. dual redundant master/local 7200's
3. MAC registration
4. ap-135's
5. 802.1X
6. PEAP
7. MSCHAPv2
8. we push the cert to the end user

The complaint is that the users are loosing connectivity, lots of ping loss, and many dropped connections with high frequency on our secure network.  I've looked at the usual stats at the controller level, made sure there wasn't any weird firewall issues, and have even tried disabling MPDU Aggregation (http://community.arubanetworks.com/t5/Education/Chromebooks-on-802-1x-SSIDs-issues/gpm-p/112769/page/3) but with no change.  I did notice that during a 4-way handshake that the controller seems to be sending WPA2-key1 twice.  Here is the auth-tracebuf log:

Chromebook:

Mar 21 13:03:31  station-down           *  20:16:d8:0a:ea:51  6c:f3:7f:ed:e3:c0                            -      -     
Mar 21 13:03:31  station-up             *  20:16:d8:0a:ea:51  6c:f3:7f:ed:e3:c0                            -      -     wpa2 aes
Mar 21 13:03:31  assg-vlan-req          *  20:16:d8:0a:ea:51  6c:f3:7f:ed:e3:c0                            2242   2240  new vlan: dot1x for wireless
Mar 21 13:03:31  assg-vlan-resp         *  20:16:d8:0a:ea:51  6c:f3:7f:ed:e3:c0                            -      2240  
Mar 21 13:03:31  wpa2-key1             <-  20:16:d8:0a:ea:51  6c:f3:7f:ed:e3:c0                            -      117   
Mar 21 13:03:32  wpa2-key1             <-  20:16:d8:0a:ea:51  6c:f3:7f:ed:e3:c0                            -      117   
Mar 21 13:03:32  wpa2-key2             ->  20:16:d8:0a:ea:51  6c:f3:7f:ed:e3:c0                            -      135   
Mar 21 13:03:32  wpa2-key3             <-  20:16:d8:0a:ea:51  6c:f3:7f:ed:e3:c0                            -      151   
Mar 21 13:03:32  wpa2-key4             ->  20:16:d8:0a:ea:51  6c:f3:7f:ed:e3:c0                            -      95    
Mar 21 13:04:38  station-down           *  20:16:d8:0a:ea:51  6c:f3:7f:ed:e3:c0                            -      -     
Mar 21 13:04:39  station-up             *  20:16:d8:0a:ea:51  6c:f3:7f:ed:e3:c0                            -      -     wpa2 aes
Mar 21 13:04:39  assg-vlan-req          *  20:16:d8:0a:ea:51  6c:f3:7f:ed:e3:c0                            2242   2240  new vlan: dot1x for wireless
Mar 21 13:04:39  assg-vlan-resp         *  20:16:d8:0a:ea:51  6c:f3:7f:ed:e3:c0                            -      2240  
Mar 21 13:04:39  wpa2-key1             <-  20:16:d8:0a:ea:51  6c:f3:7f:ed:e3:c0                            -      117   
Mar 21 13:04:40  wpa2-key1             <-  20:16:d8:0a:ea:51  6c:f3:7f:ed:e3:c0                            -      117   
Mar 21 13:04:40  wpa2-key2             ->  20:16:d8:0a:ea:51  6c:f3:7f:ed:e3:c0                            -      135   
Mar 21 13:04:40  wpa2-key3             <-  20:16:d8:0a:ea:51  6c:f3:7f:ed:e3:c0                            -      151   
Mar 21 13:04:40  wpa2-key4             ->  20:16:d8:0a:ea:51  6c:f3:7f:ed:e3:c0                            -      95    
Mar 21 13:05:45  station-down           *  20:16:d8:0a:ea:51  6c:f3:7f:ed:e3:c0                            -      -     
Mar 21 13:05:46  station-up             *  20:16:d8:0a:ea:51  6c:f3:7f:ed:e3:c0                            -      -     wpa2 aes
Mar 21 13:05:46  assg-vlan-req          *  20:16:d8:0a:ea:51  6c:f3:7f:ed:e3:c0                            2242   2240  new vlan: dot1x for wireless
Mar 21 13:05:46  assg-vlan-resp         *  20:16:d8:0a:ea:51  6c:f3:7f:ed:e3:c0                            -      2240  
Mar 21 13:05:46  wpa2-key1             <-  20:16:d8:0a:ea:51  6c:f3:7f:ed:e3:c0                            -      117   
Mar 21 13:05:47  wpa2-key1             <-  20:16:d8:0a:ea:51  6c:f3:7f:ed:e3:c0                            -      117   
Mar 21 13:05:47  wpa2-key2             ->  20:16:d8:0a:ea:51  6c:f3:7f:ed:e3:c0                            -      135   
Mar 21 13:05:47  wpa2-key3             <-  20:16:d8:0a:ea:51  6c:f3:7f:ed:e3:c0                            -      151   
Mar 21 13:05:47  wpa2-key4             ->  20:16:d8:0a:ea:51  6c:f3:7f:ed:e3:c0                            -      95    
Mar 21 13:07:04  station-down           *  20:16:d8:0a:ea:51  6c:f3:7f:ed:e3:c0                            -      -  

Here is the same log but from my Dell:

Mar 24 15:15:46  eap-success           <-  ac:7b:a1:02:bd:7c  6c:f3:7f:ed:e3:d0                            25    4    
Mar 24 15:15:46  assg-vlan-req          *  ac:7b:a1:02:bd:7c  6c:f3:7f:ed:e3:d0                            2266  2240  new vlan: dot1x for wireless
Mar 24 15:15:46  assg-vlan-resp         *  ac:7b:a1:02:bd:7c  6c:f3:7f:ed:e3:d0                            -     2240 
Mar 24 15:15:46  wpa2-key1             <-  ac:7b:a1:02:bd:7c  6c:f3:7f:ed:e3:d0                            -     117  
Mar 24 15:15:46  wpa2-key2             ->  ac:7b:a1:02:bd:7c  6c:f3:7f:ed:e3:d0                            -     119  
Mar 24 15:15:46  wpa2-key3             <-  ac:7b:a1:02:bd:7c  6c:f3:7f:ed:e3:d0                            -     151  
Mar 24 15:15:46  wpa2-key4             ->  ac:7b:a1:02:bd:7c  6c:f3:7f:ed:e3:d0

Can someone help me understand why this is happening over and over in quick succession?  Is the client missing the first handshake, or is in not replying?  Oh, and this was happening on my test network with one AP only.  Thanks,

MattB

In addition to disabling MPDU Aggregation, try disabling BA AMSDU Enable in the HT SSID Profile.

have a good look at the specs on the wireless adapter in those, particularly how many spatial streams they support and check it matches with the output of 'show ap association'.

I had a nightmare with single stream devices advertising two stream capability once before and is something I generally check when particular clients performing badly.  That is not likely to be your issue, but something to bear in mind.

---

@mbonadie wrote:

Okay, just polling the message boards to see if anyone is see the same problems.  I am pretty sure that my issue is lousy roaming & supplicant drivers, but I can't seem to find any other posts about Chromebooks with any resolutions.  Here is the layout of the wireless network:

 

1. University network which is pretty much BYOD
2. dual redundant master/local 7200's
3. MAC registration
4. ap-135's
5. 802.1X
6. PEAP
7. MSCHAPv2
8. we push the cert to the end user

The complaint is that the users are loosing connectivity, lots of ping loss, and many dropped connections with high frequency on our secure network.  I've looked at the usual stats at the controller level, made sure there wasn't any weird firewall issues, and have even tried disabling MPDU Aggregation (http://community.arubanetworks.com/t5/Education/Chromebooks-on-802-1x-SSIDs-issues/gpm-p/112769/page/3) but with no change.  I did notice that during a 4-way handshake that the controller seems to be sending WPA2-key1 twice.  

Can someone help me understand why this is happening over and over in quick succession?  Is the client missing the first handshake, or is in not replying?  Oh, and this was happening on my test network with one AP only.  Thanks,

 

MattB

 

---

Mbonadie,

If you have not already, please contact ACER in parallel.  You are not the only one with the issue:  http://community.acer.com/t5/Chromebook/C720-Chromebook-wifi-connection-drops/td-p/147129

With regards to the WPA2-Key1 being sent twice, if you notice, it took almost a whole second for the Chromebook to respond, while a successful connection takes on a second for all 4 keys back and forth.  The AP *probably* sent it again after not receiving a response in the alotted time.

All-

Thanks for the suggestions.  I'll be testing today to see if I can make any other discoveries.

MattB

Did more testing today as suggested by disabling:

1. MPDU Aggregation
2. BA AMSDU Enable

So far, same results as before with the default settings.  Same log entries as before.  Here is what is happening:

1. the Chromebook is taking a really long time to accept radius offers
2. the Chrombook seems to miss it's WPA2-Key1 handshake from the controller and then gets dropped
3. the 4-way handshake starts all over again and the Chromebook keeps missing the key1 handshake until eventually it works

I am starting to wonder if the bug has something to do with DHCP as well; normal times for refresh on wireless is 10 minutes, and clients check back in half that time to renew their previous address.  The logs show a good client performing the 4-way handshake every 5 mins or so, the Chromebook seems to be doing this handshake every minute or so.  I'll start looking at DHCP logs to see if I can pin down anything weird.

MattB

mbonadie,

You should open a case with ACER.

802.1x authentication occurs BEFORE any traffic is passed, so DHCP and any other traffic is dependent on successful and reliable 802.1x authentication at layer 2.  The performance of that 802.1x supplicant in the ACER needs to be addressed, so opening a case with ACER might get you some answers about whether that is something they are looking at.  If you had the problem with multiple devices, I would say look at the infrastructure....If it is just one device, open a case with ACER...It could not hurt...

cjoseph-

Thanks for the reply.  You are correct, DHCP happens after authentication.  Thanks for the reminder to my occasional memory lapses.  :)  I'll let our support team open a case with Acer, and hopefully Google as well.

Update to the Acer forum claims that they are informing the correct people of the wireless issues.

http://community.acer.com/t5/Chromebook/C720-Chromebook-wifi-connection-drops/m-p/147129#U147129

No offense, but they have to define the problem and replicate it before they do anything about it.  I hope they contact you or there is a formal way for you to open a ticket....

Update:

Opened a TAC case and  an internal bug (#96746) is apparently the cause for the Chromebook issues.  The official response from TAC was to disable MPDU Agg and BA AMPDU Enable, like what was previously suggested in the thread.  TAC didn't state whether or not the bug was Supplicant or AOS, but disabling this will affect all 802.11n clients globally.  So, do I slow down my entire network because of a few clients, or do I leave it alone so the 40,000 other clients can be happy?  I enabled the changes to one VAP to see if performance is better and I will post the results later.

Mbonadie,

What version of ArubaOS are you running right now?

cjoseph-

We are running 6.3.1.1.  However, my test showed that the Chromebook was fixed and it didn't miss a ping nor was dropped from our 802.1X ssid.  Still a client issue.

TAC just let me know that the fix is in 6.4 code.  So we just need to upgrade.  But, the work-around works too.

mbonadie

Edit: Just noticed the workaround in an earlier post.

A very informative blog I found, Really Appreciable. It surely does works. I found your post while I am searching solution for my Issue I have been facing for the last 3 days regarding my Acer Laptop as it didn't allow me to use AOL mail. I also tried Acer Technical Support But Issue yet not resolved.