Cisco Cisco 2504 Wireless Controller Guía Para Resolver Problemas
21:48:50.589: 00:40:96:b7:ab:5cPMK: Sending cache add *Dot1x_NW_MsgTask_4: Jun 21 21:48:50.590:
00:40:96:b7:ab:5c Sending EAPOL-Key Message to mobile 00:40:96:b7:ab:5c state PTKINITNEGOTIATING
(message 3), replay counter 00.00.00.00.00.00.00.01 *Dot1x_NW_MsgTask_4: Jun 21 21:48:50.610:
00:40:96:b7:ab:5c Received EAPOL-Key from mobile 00:40:96:b7:ab:5c *Dot1x_NW_MsgTask_4: Jun 21
21:48:50.610: 00:40:96:b7:ab:5c Received EAPOL-key in PTKINITNEGOTIATING state (message 4) from
mobile 00:40:96:b7:ab:5c
As shown at the beginning of the debugs, the PMKID must be computed after the Reassociation
Request from the client is received. This is needed in order to validate the PMKID and confirm that
the cached PMK is used with the WPA2 4-Way handshake to derive the encryption keys and finish
the fast-secure roaming. Do not confuse the CCKM entries on the debugs; this is not used in order
to perform CCKM, but PKC/OKC, as previously explained. CCKM here is simply a name used by
the WLC for those outputs, such as the name of a function that handles the values in order to
compute the PMKID.
Request from the client is received. This is needed in order to validate the PMKID and confirm that
the cached PMK is used with the WPA2 4-Way handshake to derive the encryption keys and finish
the fast-secure roaming. Do not confuse the CCKM entries on the debugs; this is not used in order
to perform CCKM, but PKC/OKC, as previously explained. CCKM here is simply a name used by
the WLC for those outputs, such as the name of a function that handles the values in order to
compute the PMKID.
Scenario 23: Verifying Fast-Secure-Roaming (FSR) with
802.11r
802.11r
Debug run
debug client <mac addr>
*apfMsConnTask_2: Jun 21 21:48:50.562: 00:40:96:b7:ab:5c Reassociation received from mobile on
BSSID 84:78:ac:f0:2a:92
This is the Reassociation Request from the client.
*apfMsConnTask_2: Jun 21 21:48:50.563:
00:40:96:b7:ab:5c Processing RSN IE type 48, length 38 for mobile 00:40:96:b7:ab:5c
The WLC/AP
finds and Information Element that claims PMKID Caching support on the Association request that
is sent from the client.
*apfMsConnTask_2: Jun 21 21:48:50.563: 00:40:96:b7:ab:5c Received RSN
IE with 1 PMKIDs from mobile 00:40:96:b7:ab:5c
The Reassociation Request from the client comes
with one PMKID.
*apfMsConnTask_2: Jun 21 21:48:50.563:Received PMKID: (16) *apfMsConnTask_2: Jun
21 21:48:50.563: [0000] 91 65 c3 fb fc 44 75 48 67 90 d5 da df aa 71 e9 *apfMsConnTask_2: Jun 21
21:48:50.563: 00:40:96:b7:ab:5c Searching for PMKID in MSCB PMKID cache for mobile
00:40:96:b7:ab:5c *apfMsConnTask_2: Jun 21 21:48:50.563: 00:40:96:b7:ab:5c No valid PMKID found
in the MSCB PMKID cache for mobile 00:40:96:b7:ab:5
As the client has never authenticated with
this new AP, the WLC cannot find a valid PMKID to match the one provided by the client.
However, since the client performs PKC/OKC and not SKC (as per the following messages), the WLC
computes a new PMKID based on the information gathered (the cached PMK,the client MAC address,
and the new AP MAC address).
*apfMsConnTask_2: Jun 21 21:48:50.563: 00:40:96:b7:ab:5c Trying to
compute a PMKID from MSCB PMK cache for mobile 00:40:96:b7:ab:5c *apfMsConnTask_2: Jun 21
21:48:50.563: CCKM: Find PMK in cache: BSSID = (6) *apfMsConnTask_2: Jun 21 21:48:50.563: [0000]
84 78 ac f0 2a 90 *apfMsConnTask_2: Jun 21 21:48:50.563: CCKM: Find PMK in cache: realAA = (6)
*apfMsConnTask_2: Jun 21 21:48:50.563: [0000] 84 78 ac f0 2a 92 *apfMsConnTask_2: Jun 21
21:48:50.563: CCKM: Find PMK in cache: PMKID = (16) *apfMsConnTask_2: Jun 21 21:48:50.563:
[0000] 91 65 c3 fb fc 44 75 48 67 90 d5 da df aa 71 e9 *apfMsConnTask_2: Jun 21 21:48:50.563:
CCKM: AA (6) *apfMsConnTask_2: Jun 21 21:48:50.563: [0000] 84 78 ac f0 2a 92 *apfMsConnTask_2:
Jun 21 21:48:50.563: CCKM: SPA (6) *apfMsConnTask_2: Jun 21 21:48:50.563: [0000] 00 40 96 b7 ab
5c *apfMsConnTask_2: Jun 21 21:48:50.563: 00:40:96:b7:ab:5c Adding BSSID 84:78:ac:f0:2a:92 to
PMKID cache at index 0 for station 00:40:96:b7:ab:5c *apfMsConnTask_2: Jun 21 21:48:50.563: New
PMKID: (16) *apfMsConnTask_2: Jun 21 21:48:50.563:[0000] 91 65 c3 fb fc 44 75 48 67 90 d5 da df
aa 71 e9 *apfMsConnTask_2: Jun 21 21:48:50.563: 00:40:96:b7:ab:5c Computed a valid PMKID from
MSCB PMK cache for mobile 00:40:96:b7:ab:5c
The new PMKID is computed and validated to match the
one provided by the client, which is also computed with the same information. Hence, the fast-
secure roam is possible.
*apfMsConnTask_2: Jun 21 21:48:50.563: 00:40:96:b7:ab:5c Setting active
key cache index 0 ---> 0 *apfMsConnTask_2: Jun 21 21:48:50.564: 00:40:96:b7:ab:5c Sending Assoc
Response to station on BSSID 84:78:ac:f0:2a:92 (status 0) ApVapId 3 Slot
The Reassociation
response is sent to the client, which validates the fast-roam with PKC/OKC.
*dot1xMsgTask: Jun
21 21:48:50.570: 00:40:96:b7:ab:5c Initiating RSN with existing PMK to mobile 00:40:96:b7:ab:5c
WLC initiates a Robust Secure Network association with this client-and AP pair with the cached
PMK found. Hence, EAP is avoided, as per the the next message.
*dot1xMsgTask: Jun 21
21:48:50.570: 00:40:96:b7:ab:5c Skipping EAP-Success to mobile 00:40:96:b7:ab:5c *dot1xMsgTask: