Wireless Access

Hi,

I’m experiencing weird issues with 802.1x/EAP-TLS authentication and AP205 running AOS 6.4.2.3 (620 and 7010 controllers) on newer set of machines with W8.1. This only occurs when on the 5 Ghz band, 2.4 Ghz works just fine on all devices. Other tested units such as older machines on 802.11a, Android devices on 4.2.2 and 4.4.3 and iPhone works just fine with AP205. It seems like the TLS handshake doesn’t properly finish according to the FreeRADIUS logs, and debugging Aruba controller gives me a reponse of 6, which would mean there’s something about the (lacking) challenge response. The strange thing is that it works just fine with all the other tested Campus AP’s (105, 125) and RAP’s (RAP3, RAP109) with the same set of configuration (AP Group). I have tried terminating the AP’s on both master and local controller with the same behavior.
As a result of the failure in connecting the client’s wlan NIC seems to crash and it stops listing available SSIDs. Disabling/enabling or rebooting gets the NIC operational, but crashes everytime client attempts to reconnect to the AP-205 in question.

Briefly described;
• Same issues when running AOS 6.4.2.2 and 6.4.2.3
• Older machine with EAP-TLS and Android/iOS with EAP-TLS/EAP-PEAP works fine with all APs/RAPs
• New machine with EAP-TLS/EAP-PEAP does not work on AP-205 on 5 Ghz band, though working fine on 2.4 Ghz and both bands on other tested CAP/RAPs.
• Connecting to PSK based SSIDs works just fine regardless of device, OS or frequency band.
• auth-tracebuf gives me dot1x-timeout and controller output value 6.
• client trail-info gives me "APAE Disconnect"

Excerpt from FreeRADIUS;

[eap] EAP/tls
[eap] processing type tls
[tls] Authenticate
[tls] processing EAP-TLS
[tls] eaptls_verify returned 7
[tls] Done initial handshake
[tls] (other): before/accept initialization
[tls] TLS_accept: before/accept initialization
[tls] <<< TLS 1.0 Handshake [length 00c1], ClientHello
[tls] TLS_accept: SSLv3 read client hello A
[tls] >>> TLS 1.0 Handshake [length 0031], ServerHello
[tls] TLS_accept: SSLv3 write server hello A
[tls] >>> TLS 1.0 Handshake [length 0953], Certificate
[tls] TLS_accept: SSLv3 write certificate A
[tls] >>> TLS 1.0 Handshake [length 030d], ServerKeyExchange
[tls] TLS_accept: SSLv3 write key exchange A
[tls] >>> TLS 1.0 Handshake [length 0095], CertificateRequest
[tls] TLS_accept: SSLv3 write certificate request A
[tls] TLS_accept: SSLv3 flush data
[tls] TLS_accept: Need to read more data&colon; SSLv3 read client certificate A
..
Sending Access-Challenge of id 162 to 192.168.5.9 port 32860
Aruba-User-Role = "authenticated"
EAP-Message = 0x010200060d20
Message-Authenticator = 0x00000000000000000000000000000000
State = 0x6bbc95f76bbe987fdf1d2f664c8f5cc2
..
WARNING: !! EAP session for state 0x5d2bf7975d29fa8d did not finish!

.. This would indicate the lack of response from the client.

auth-tracebuf Aruba controller;

Jan 2 20:22:59 eap-req <- 7c:7a:91:c4:b4:27 ac:a3:1e:c2:d4:70 5 1024
Jan 2 20:23:04 eap-req <- 7c:7a:91:c4:b4:27 ac:a3:1e:c2:d4:70 5 1024
Jan 2 20:23:09 eap-req <- 7c:7a:91:c4:b4:27 ac:a3:1e:c2:d4:70 5 1024
Jan 2 20:23:14 eap-req <- 7c:7a:91:c4:b4:27 ac:a3:1e:c2:d4:70 5 1024
Jan 2 20:23:19 dot1x-timeout * 7c:7a:91:c4:b4:27 ac:a3:1e:c2:d4:70 5 3 server timeout
Jan 2 20:23:19 dot1x-timeout * 7c:7a:91:c4:b4:27 ac:a3:1e:c2:d4:70 6 2 station timeout
Jan 2 20:23:19 eap-id-req <- 7c:7a:91:c4:b4:27 ac:a3:1e:c2:d4:70 6 5
Jan 2 20:23:24 rad-acct-stop -> 7c:7a:91:c4:b4:27 ac:a3:1e:c2:d4:70 - -
Jan 2 20:23:24 dot1x-timeout * 7c:7a:91:c4:b4:27 ac:a3:1e:c2:d4:70 6 1 station timeout

I have a TAC open on this issue, but I thought there might've been others out there with the same problems.

Any ideas?

Not enough information.

Are you running 80mhz channels?  Uncheck 80mhz channels and see if it improves.

Thank you for replying.

Is there any other information you want me to provide?

Unchecking 80 Mhz channel has no effect on the behaviour.

Best regards,

Daniel

"As a result of the failure in connecting the client’s wlan NIC seems to crash and it stops listing available SSIDs. Disabling/enabling or rebooting gets the NIC operational, but crashes everytime client attempts to reconnect to the AP-205 in question."

You did not say what wireless NIC the Windows 8.1 device has and what driver date.  If the NIC crashes, you might want to contact the manufacturer of the PC.

I've tested with several (5-6 different brands with different NICs) machines with the exact same behaviour, so I didn't see a mentionable link there. 

Two of the machines I've tried;

Lenovo T440s with Intel Dual Band Wireless-AC 7260 NIC with Intel 16.5.3.6 driver

Dell E6420 with Intel Centrino Advanced-N 6205 with Intel 15.10.3.2 driver

MS drivers gives the same result.

The intel 7260s have later drivers  (17.0.3)  https://downloadcenter.intel.com/Detail_Desc.aspx?DwnldID=23942&lang=eng&ProdId=3714

The Intel Advanced-N 6205s have later drivers (17.13.11)  https://downloadcenter.intel.com/Detail_Desc.aspx?DwnldID=24576&lang=eng&ProdId=3316

I would consider try those two driver-only versions on Intel's website.  I would also consider contacting Lenovo and/or Dell to get their perspective on your issue.

Upgrading drivers unfortunately didn't do it. I'll post a case with the vendors.

Thanks.

itwt,

APAE Disconnect is when the 802.1x supplicant (client) reaches the maximum amount for identity requests.  Why it is not responding is an issue that needs to be understood.

I would:

- Make sure the 802.11k profile under the Virtual AP profile has "Advertise 802.11k Capability" unchecked.

- I would also make sure there is no 802.11r profile enabled under the SSID profile (make it N/A).

UPDATE 6/2018 -  The updated RF and Roaming Optimization Validated Reference Design Guide (VRD) has been published and has updated recommendations about enabling 802.11v, k and r in user networks.  The VRD can be found here: http://community.arubanetworks.com/t5/Validated-Reference-Design/RF-and-Roaming-Optimization-for-Aruba-802-11ac-Networks/ta-p/432994

These changes would be to "Normalize" the WLAN based on the defaults.

Nice. choosing default (off) on 802.11k advertisement seems to do the trick, I did a quick read on Intel forums and it seems a lot of their NICs are not 802.11k supported, and could cause some connectivity issues.

I'll do some further testing to see how reliable it is.

Thanks!

Best regards,

Daniel

You can enable 802.11k with the Intel 7260, but make sure you have "Advertise Quiet IE" disabled in the related rrm-ie-profile.

Quiet IE will cause the 7260 to not connect on 5GHz anymore.

Hi, Arjan.

Yes, I already did that yesterday, and I'm not experiencing issues or interruptions on any NICs I've tried so far.

Thank you for reporting back anyway, though.

Best regards,

Daniel