Product and Software: This article applies to Aruba M3/3000 series controllers running ArubaOS 3.2 or later.
When a new M3/3000 series controller is turned on as a local controller, wireless users might be able to connect but not be able to get an IP address nor pass any traffic even though dot1x authentication is successful and key exchange passed.
This sample output shows that everything is ok, but the user was not able to pass traffic.
Sep 2 14:24:15 eap-req <- de:ad:be:ef:ca:fe 00:0b:86:00:11:22 15 1031
Sep 2 14:24:15 eap-resp -> de:ad:be:ef:ca:fe 00:0b:86:00:11:22 15 200
Sep 2 14:24:15 rad-req -> de:ad:be:ef:ca:fe 00:0b:86:00:11:22/test 76 379
Sep 2 14:24:15 rad-resp <- de:ad:be:ef:ca:fe 00:0b:86:00:11:22/test 76 124
Sep 2 14:24:15 eap-req <- de:ad:be:ef:ca:fe 00:0b:86:00:11:22 16 53
Sep 2 14:24:15 eap-resp -> de:ad:be:ef:ca:fe 00:0b:86:00:11:22 16 6
Sep 2 14:24:15 rad-req -> de:ad:be:ef:ca:fe 00:0b:86:00:11:22/test 77 185
Sep 2 14:24:15 rad-resp <- de:ad:be:ef:ca:fe 00:0b:86:00:11:22/test 77 99
Sep 2 14:24:15 eap-req <- de:ad:be:ef:ca:fe 00:0b:86:00:11:22 17 28
Sep 2 14:24:15 eap-resp -> de:ad:be:ef:ca:fe 00:0b:86:00:11:22 17 47
Sep 2 14:24:15 rad-req -> de:ad:be:ef:ca:fe 00:0b:86:00:11:22/test 78 226
Sep 2 14:24:15 rad-resp <- de:ad:be:ef:ca:fe 00:0b:86:00:11:22/test 78 124
Sep 2 14:24:15 eap-req <- de:ad:be:ef:ca:fe 00:0b:86:00:11:22 18 53
Sep 2 14:24:15 eap-resp -> de:ad:be:ef:ca:fe 00:0b:86:00:11:22 18 101
Sep 2 14:24:15 rad-req -> de:ad:be:ef:ca:fe 00:0b:86:00:11:22/test 79 280
Sep 2 14:24:15 rad-resp <- de:ad:be:ef:ca:fe 00:0b:86:00:11:22/test 79 145
Sep 2 14:24:15 eap-req <- de:ad:be:ef:ca:fe 00:0b:86:00:11:22 19 74
Sep 2 14:24:15 eap-resp -> de:ad:be:ef:ca:fe 00:0b:86:00:11:22 19 29
Sep 2 14:24:15 rad-req -> de:ad:be:ef:ca:fe 00:0b:86:00:11:22/test 80 208
Sep 2 14:24:15 rad-resp <- de:ad:be:ef:ca:fe 00:0b:86:00:11:22/test 80 109
Sep 2 14:24:15 eap-req <- de:ad:be:ef:ca:fe 00:0b:86:00:11:22 20 38
Sep 2 14:24:15 eap-resp -> de:ad:be:ef:ca:fe 00:0b:86:00:11:22 20 38
Sep 2 14:24:15 rad-req -> de:ad:be:ef:ca:fe 00:0b:86:00:11:22/test 81 217
Sep 2 14:24:15 rad-accept <- de:ad:be:ef:ca:fe 00:0b:86:00:11:22/test 81 263
Sep 2 14:24:15 eap-success <- de:ad:be:ef:ca:fe 00:0b:86:00:11:22 21 4
Sep 2 14:24:15 station-data-ready * de:ad:be:ef:ca:fe 00:00:00:00:00:00 50 -
Sep 2 14:24:15 wpa2-key1 <- de:ad:be:ef:ca:fe 00:0b:86:00:11:22 - 117
Sep 2 14:24:15 wpa2-key2 -> de:ad:be:ef:ca:fe 00:0b:86:00:11:22 - 119
Sep 2 14:24:15 wpa2-key3 <- de:ad:be:ef:ca:fe 00:0b:86:00:11:22 - 167
Sep 2 14:24:15 wpa2-key4 -> de:ad:be:ef:ca:fe 00:0b:86:00:11:22 - 95
The 'show datapath crypto' command reveals a large number of decryption failures (AES or TKIP, depends on the configuration):
ArubaM3K1) #show datapath crypto counters
Datapath Crypto Statistics
--------------------------
Crypto Accelerator Present
Crypto Cores In Use 4
Crypto Cores Total 4
Crypto Requests Total 143949
Crypto Requests Queued 0
Crypto Requests Failed 0
Crypto Timeouts 0
IPSec Encryption Failures 0
IPSec Decryption Failures 0
IPSec Decryption Loops 0
IPSec Decryption BufFail 0
IPSec Decr SPI(client) ERR 0
IPSec Decrypt SA Not Ready 0
PPTP Encryption Failures 0
PPTP Decryption Failures 0
WEP Encryption Failures 0
WEP Decryption Failures 0
WEP No Key (not serious) 0
TKIP Encryption Failures 32
TKIP Decryption Failures 0
TKIP Decrypt Bad Counter 0
TKIP P1Key Not Ready 32
TKIP Serialized 24
TKIP Drops 0
AESCCM Encryption Failures 2
AESCCM Decryption Failures 1667 <<<<<<<<<<<<<<<<
AESCCM Serialized 2
AESCCM Drops 0
AESCCM Decrypt Bad Counter 0
WEP CRC Entries Used 0
WEP CRC Alloc Failures 0
WEP CRC Sending 0
WEP CRC Sent 0
WEP CRC Bad Send 0
WEP CRC Unknown 0
Max Crypto HW Queues 0
Crypto HW Queues Used 0
Crypto HW Queue Alloc Fail 0
XSEC Encryption Failures 0
XSEC Decryption Failures 0
DOT1X Term Buffers 2048
DOT1X Term Buffers Free 2048
DOT1X Term Failures 0
DOT1X Term NAKs 0
DOT1X Term Resends 0
DOT1X Term Succeeded 0
The 'show datapath station' command also shows a large number of decryption failures:
(ArubaM3K1) # show datapath station
Datapath Station Table Statistics
---------------------------------
Current Entries 1
Pending Deletes 0
High Water Mark 2
Maximum Entries 16383
Total Entries 83
Allocation Failures 0
Max link length 1
Datapath Station Table Entries
------------------------------
Flags: W - WEP, T - TKIP, A - AESCCM, M - WMM
P- Powersave, S - AMSDU
MAC BSSID VLAN Bad Decrypts Cpu Qsz Flags
----------------- ----------------- ---- ------------ --- ----------- -----
DE:AD:BE:EF:CA:FE 00:0B:86:11:22:33 50 207 16 16161616 A
The problem remains even when the IP address is statically configured and static ARP entry is set up on the wireless client.
However, if you change the SSID to opensystem, then the wireless client is able to pass traffic.
If this happens, verify the following conditions:
- The local controller is an M3 or 3000 series controller.
- The AP is locally connected to the master controller and the master controller is the default gateway of the AP.
- The LMS of the AP is the switch IP of the local controller and it is not on the same IP subnet of the AP.
If these three conditions are true, then these things might have happened:
- The AP is connecting to LMS. The LMS is not on the same subnet, so the AP sends a packet to its default gateway, which is the master controller.
- The master controller could only reach the LMS by using IPsec tunnel due to the master-local topology.
- The master controller sends the AP packet into the tunnel. If the traffic is controller traffic (for example, heartbeat or config push), there is no problem. However if the traffic is user-encrypted traffic, then the packet cannot be decrypted when it reaches the local controller.
This behavior is expected. To correct this problem, change the LMS IP to an IP address other than the switchip of the local controller (for example, a physically interface IP or a VRRP IP).