Wireless Access

Good afternoon,

   We have been having issues lately with new Chromebook clients at several locations.  Here is our environment and backstory:

ArubaOS (MODEL: Aruba7210-US), Version 6.4.2.12 controllers with 2 of these acting as master controller (active and standby) and AP205 and AP225 AP mixed around several campuses.  The Chromebooks are Lenovo Yoga with Intel® 7260 2 x 2 AC + Bluetooth® 4.0 combo cards.  We have several thousand Chromebooks spread around but only seem to see this issue with these devices.

The clients randomly disconnect and will not connect for anywhere between 10 minutes and 3 hours.  I would guess about an hour is the typical time we see them  offline is about an hour.  Once they do get back online, we may never see that laptop again at all.  Later in the day, we might get another laptop with the same problem and they are very sporatic (and about 1-4 per day, out of hundreds at a site).

We have two different networks with settings pushed down to the clients from the Google Admin Console and this is one policy at the top of our domain.  So we know all of the Chromebooks are getting the same policies and user names and passwords for these networks.

SSID 1. WPA2-AES PEAP

SSID 2. WPA-PSK-AES

When the problem occurs, the client is unable to connect to either network and it keeps popping up asking to enter credentials even though they have been pushed down (as mentioned).  Typing in the credentials again does nothing and the problem continues to occur.  I have been logging (logging level debug user-debug <client mac> and looking at auth-tracebuf messages (show auth-tracebuf mac <client mac>) and haven't come up with much.  On the auth-tracebuf for the PSK PEAP-radius network, here is what I get (Clearpass is handling radius):

Jan 6 10:27:06 station-up * 10:4a:7d:c1:30:f4 94:b4:0f:88:d0:f0 - - wpa2 aes
Jan 6 10:27:06 eap-id-req <- 10:4a:7d:c1:30:f4 94:b4:0f:88:d0:f0 1 5
Jan 6 10:27:06 eap-id-resp -> 10:4a:7d:c1:30:f4 94:b4:0f:88:d0:f0 1 15 testuser
Jan 6 10:27:06 rad-req -> 10:4a:7d:c1:30:f4 94:b4:0f:88:d0:f0 60 201
Jan 6 10:27:06 rad-resp <- 10:4a:7d:c1:30:f4 94:b4:0f:88:d0:f0/clearpass1 60 76
Jan 6 10:27:06 eap-req <- 10:4a:7d:c1:30:f4 94:b4:0f:88:d0:f0 2 6
Jan 6 10:27:06 eap-resp -> 10:4a:7d:c1:30:f4 94:b4:0f:88:d0:f0 2 206
Jan 6 10:27:06 rad-req -> 10:4a:7d:c1:30:f4 94:b4:0f:88:d0:f0/clearpass1 108 422
Jan 6 10:27:06 rad-resp <- 10:4a:7d:c1:30:f4 94:b4:0f:88:d0:f0/clearpass1 108 1112
Jan 6 10:27:06 eap-req <- 10:4a:7d:c1:30:f4 94:b4:0f:88:d0:f0 3 1034
Jan 6 10:27:06 eap-resp -> 10:4a:7d:c1:30:f4 94:b4:0f:88:d0:f0 3 6
Jan 6 10:27:06 rad-req -> 10:4a:7d:c1:30:f4 94:b4:0f:88:d0:f0/clearpass1 113 222
Jan 6 10:27:06 rad-resp <- 10:4a:7d:c1:30:f4 94:b4:0f:88:d0:f0/clearpass1 113 1108
Jan 6 10:27:06 eap-req <- 10:4a:7d:c1:30:f4 94:b4:0f:88:d0:f0 4 1030
Jan 6 10:27:06 eap-resp -> 10:4a:7d:c1:30:f4 94:b4:0f:88:d0:f0 4 6
Jan 6 10:27:06 rad-req -> 10:4a:7d:c1:30:f4 94:b4:0f:88:d0:f0/clearpass1 66 222
Jan 6 10:27:06 rad-resp <- 10:4a:7d:c1:30:f4 94:b4:0f:88:d0:f0/clearpass1 66 1108
Jan 6 10:27:06 eap-req <- 10:4a:7d:c1:30:f4 94:b4:0f:88:d0:f0 5 1030
Jan 6 10:27:06 eap-resp -> 10:4a:7d:c1:30:f4 94:b4:0f:88:d0:f0 5 6
Jan 6 10:27:06 rad-req -> 10:4a:7d:c1:30:f4 94:b4:0f:88:d0:f0/clearpass1 106 222
Jan 6 10:27:06 rad-resp <- 10:4a:7d:c1:30:f4 94:b4:0f:88:d0:f0/clearpass1 106 1108
Jan 6 10:27:06 eap-req <- 10:4a:7d:c1:30:f4 94:b4:0f:88:d0:f0 6 1030
Jan 6 10:27:06 eap-resp -> 10:4a:7d:c1:30:f4 94:b4:0f:88:d0:f0 6 6
Jan 6 10:27:06 rad-req -> 10:4a:7d:c1:30:f4 94:b4:0f:88:d0:f0/clearpass1 98 222
Jan 6 10:27:06 rad-resp <- 10:4a:7d:c1:30:f4 94:b4:0f:88:d0:f0/clearpass1 98 973
Jan 6 10:27:06 eap-req <- 10:4a:7d:c1:30:f4 94:b4:0f:88:d0:f0 7 897
Jan 6 10:27:06 eap-resp -> 10:4a:7d:c1:30:f4 94:b4:0f:88:d0:f0 7 140
Jan 6 10:27:06 rad-req -> 10:4a:7d:c1:30:f4 94:b4:0f:88:d0:f0/clearpass1 67 356
Jan 6 10:27:06 rad-resp <- 10:4a:7d:c1:30:f4 94:b4:0f:88:d0:f0/clearpass1 67 139
Jan 6 10:27:06 eap-req <- 10:4a:7d:c1:30:f4 94:b4:0f:88:d0:f0 8 69
Jan 6 10:27:06 eap-resp -> 10:4a:7d:c1:30:f4 94:b4:0f:88:d0:f0 8 6
Jan 6 10:27:06 rad-req -> 10:4a:7d:c1:30:f4 94:b4:0f:88:d0:f0/clearpass1 107 222
Jan 6 10:27:06 rad-resp <- 10:4a:7d:c1:30:f4 94:b4:0f:88:d0:f0/clearpass1 107 113
Jan 6 10:27:06 eap-req <- 10:4a:7d:c1:30:f4 94:b4:0f:88:d0:f0 9 43
Jan 6 10:27:06 eap-resp -> 10:4a:7d:c1:30:f4 94:b4:0f:88:d0:f0 9 96
Jan 6 10:27:06 rad-req -> 10:4a:7d:c1:30:f4 94:b4:0f:88:d0:f0/clearpass1 103 312
Jan 6 10:27:07 rad-resp <- 10:4a:7d:c1:30:f4 94:b4:0f:88:d0:f0/clearpass1 103 145
Jan 6 10:27:07 eap-req <- 10:4a:7d:c1:30:f4 94:b4:0f:88:d0:f0 10 75
Jan 6 10:27:07 eap-resp -> 10:4a:7d:c1:30:f4 94:b4:0f:88:d0:f0 10 144
Jan 6 10:27:07 rad-req -> 10:4a:7d:c1:30:f4 94:b4:0f:88:d0:f0/clearpass1 83 360
Jan 6 10:27:07 rad-resp <- 10:4a:7d:c1:30:f4 94:b4:0f:88:d0:f0/clearpass1 83 161
Jan 6 10:27:07 eap-req <- 10:4a:7d:c1:30:f4 94:b4:0f:88:d0:f0 11 91
Jan 6 10:27:07 eap-resp -> 10:4a:7d:c1:30:f4 94:b4:0f:88:d0:f0 11 80
Jan 6 10:27:07 rad-req -> 10:4a:7d:c1:30:f4 94:b4:0f:88:d0:f0/clearpass1 78 296
Jan 6 10:27:07 rad-resp <- 10:4a:7d:c1:30:f4 94:b4:0f:88:d0:f0/clearpass1 78 113
Jan 6 10:27:07 eap-req <- 10:4a:7d:c1:30:f4 94:b4:0f:88:d0:f0 12 43
Jan 6 10:27:07 eap-resp -> 10:4a:7d:c1:30:f4 94:b4:0f:88:d0:f0 12 80
Jan 6 10:27:07 rad-req -> 10:4a:7d:c1:30:f4 94:b4:0f:88:d0:f0/clearpass1 86 296
Jan 6 10:27:08 rad-reject <- 10:4a:7d:c1:30:f4 94:b4:0f:88:d0:f0 86 44
Jan 6 10:27:08 eap-failure <- 10:4a:7d:c1:30:f4 94:b4:0f:88:d0:f0 12 4 server rejected
Jan 6 10:27:08 station-down * 10:4a:7d:c1:30:f4 94:b4:0f:88:d0:f0 - -
Jan 6 10:27:08 station-up * 10:4a:7d:c1:30:f4 94:b4:0f:88:d0:f2 - - wpa2 psk aes
Jan 6 10:27:08 wpa2-key1 <- 10:4a:7d:c1:30:f4 94:b4:0f:88:d0:f2 - 117
Jan 6 10:27:08 station-down * 10:4a:7d:c1:30:f4 94:b4:0f:88:d0:f2 - -

Here is a pastebin of my debug log at the same time: http://pastebin.com/raw/fx3s8zS0

Any help is greatly appreciated,

Mcfly

Find out what message the radius server is saying that is tied to that radius reject at the end.  That should give you a direction.

Thanks for the reply.

Unfortunately that is not helping.  For one, the radius reject message is error 206 "Authentication failure."  Here is the Clearpass log information for one of the messages: http://pastebin.com/raw/1CDmrMTh

The only line highlighted in that log file is the line:

The reason I say it doesn't help is because the client is constantly trying to connect to both our PEAP and PSK network and neither work when the problem happens.  When one of the networks start working randomly, the other starts to work, as well.  Since PSK does not rely on Clearpass at all (as far as I understand), I doubt that is related.  I believe somewhere else in the chain, information is being left out or corrupted because neither network will work when the problem occurs.  Sometimes the user clicks between both networks while the problem happens and it will continually pop up with a message saying something like "auth failure" or "bad password"  and again, these passwords are being pushed to the client from a policy, so we know the passwords are correct.  It's like the PSK password AND the PEAP password (on their respective SSIDs) are corrupt or somehow being passed incorrectly.  Then when the problem is fixed, no more popups on the client asking for the password on either the PEAP or PSK network.  Both just start to work.

Thanks for any additional help on this one,

McFly

Hey, Victor,

   Yes, we tried updating to the latest a greatest and we also are running all sort of versions of the driver (and ChromeOS) and there is no rhyme or reason.  Sometimes an older version will have the problem.  The next day, it's the newest version that is not working.

Thanks for your relpy!

---

@mcflyatl wrote:

Thanks for the reply.

  

Unfortunately that is not helping.  For one, the radius reject message is error 206 "Authentication failure."  Here is the Clearpass log information for one of the messages: http://pastebin.com/raw/1CDmrMTh

The only line highlighted in that log file is the line:

2016-01-06 10:19:58,414

[RequestHandler-1-0x7fde793c9700 h=69894928 c=R003296d6-02-568d309e] WARN REC.EvaluatorCtx - Prerequisites set is empty, not populating the Request Map

The reason I say it doesn't help is because the client is constantly trying to connect to both our PEAP and PSK network and neither work when the problem happens.  When one of the networks start working randomly, the other starts to work, as well.  Since PSK does not rely on Clearpass at all (as far as I understand), I doubt that is related.  I believe somewhere else in the chain, information is being left out or corrupted because neither network will work when the problem occurs.  Sometimes the user clicks between both networks while the problem happens and it will continually pop up with a message saying something like "auth failure" or "bad password"  and again, these passwords are being pushed to the client from a policy, so we know the passwords are correct.  It's like the PSK password AND the PEAP password (on their respective SSIDs) are corrupt or somehow being passed incorrectly.  Then when the problem is fixed, no more popups on the client asking for the password on either the PEAP or PSK network.  Both just start to work.

 

Thanks for any additional help on this one,

McFly

---

Not the detailed message, the access tracker message for the Deny (which is less verbose).

Please open a TAC case in parallel, because there is plenty of information you are not sharing that would help.  We are just guessing here with the limited information you give us.