Windows 7 not sending the correct PMKID
We are running a WPA2-Enterprise network, with a Cisco 4402 Wireless LAN controller, and Cisco 1142n APs. Our users started complaining that when walking around the building, their Citrix or RDP sessions would sometimes get disconnected. I filed a case with
Cisco, and after some troubleshooting, they said the logs indicated that the Windows 7 clients are using Sticky PMK caching vs opportunistic. This causes the clients to reauthenticate to the RADIUS server every time they roam APs. This causes latency issues.
According to Microsoft's documentation, they only support opportunistic, but my cisco logs disagree.
Is there anyway to get Windows 7 to use opportunistic pmk caching?
I have already disabled Fast Reconnect.
July 25th, 2011 6:00pm
Hi,
Thanks for posting!
Since this is relatively complex issue, I would transfer it to a senior engineer. And hope the problem could be solved soon.
Thanks for understanding
Please remember to click Mark as Answer on the post that helps you, and to click Unmark as Answer if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread.
Free Windows Admin Tool Kit Click here and download it now
July 29th, 2011 2:15am
Windows 7 only supports opportunistic PMK caching, so it is unlikely that Cisco's analysis is accurate. With OPC, your APs, have to be connected to the same controller, so if you are roaming between APs that are on different controllers, OPC will not
work. We would need further information that indicates that OPC is not working.
YOu can enable Windows logging with the following command:
netsh trace start scenario=wlan capture=yes
Once you have captured the data, you can use Netmon 3.4 (http://www.microsoft.com/download/en/details.aspx?displaylang=en&id=4865) to view the data (you will need to set the full Windows parsers by going to Tools->Options->Parser
Profiles)
Further Win7 has a default cache list of 16 entries, but it can be adjusted. The following keys are from KB article 869657
Registry values that control preauthentication and PMK caching
The following registry entries in the HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\EAPOL\Parameters\General\Global subkey control the behavior of preauthentication and PMK caching for the WPA2/WPS IE Update:• PMKCacheMode
• PMKCacheTTL
• PMKCacheSize
• PreAuthMode
• PreAuthThrottle
PMKCacheMode
Value type: REG_DWORD - Boolean
Valid range: 0 (disabled), 1 (enabled)
Default value: 1
Present by default: No
Description: Specifies whether a Windows XP-based wireless client will perform PMK caching. By default, PMKCacheMode is enabled.
PMKCacheTTL
Value type: REG_DWORD
Valid range: 5-1440
Default value: 720
Present by default: No
Description: Specifies the number of minutes that an entry in the PMK cache can exist before being removed. The maximum value is 1440 (24 hours). The default value is 720 (12 hours).
PMKCacheSize
Value type: REG_DWORD
Valid range: 1-255
Default value: 100
Present by default: No
Description: Specifies the maximum number of entries that can be stored in the PMK cache. By default, the PMK cache has 16 entries.
PreAuthMode
Value type: REG_DWORD - Boolean
Valid range: 0 (disabled), 1 (enabled)
Default value: 0
Present by default: No
Description: Specifies whether a Windows XP-based wireless client will try preauthentication. By default, PreAuthMode is disabled.
PreAuthThrottle
Value type: REG_DWORD
Valid range: 1-16
Default value: 3
Present by default: No
Description: Specifies the number of top candidate wireless access points with which the Windows XP-based computer will try preauthentication. The value is based on the ordered list of the most favored wireless access points, as reported by the wireless network
adaptor driver. By default, PreAuthThrottle has a value of 3.
Note Changes to any one or more of these registry entry values do not take effect until the next time that you restart the wireless service or the next time that you restart the computer.Clay Seymour - MSFT
August 2nd, 2011 9:45am
I created the file capture and am currently combing through it to see what I can make of it. So far, I don't see anything either way. We only have one controller, so that's not an issue.
Currently, the PMK Cache is enabled on the laptops, with 16 cache entries. PreAuth is disabled.
According to Cisco, and their interpretation of the logs, here's what's happening:
My laptop wants to roam but the PMK has timed out, so the controller sends a new one:
*apfMsConnTask_0: Aug 02 14:20:14.340: New PMKID: (16)
*apfMsConnTask_0: Aug 02 14:20:14.340: [0000] a6 50 51 98 bc 10 74 ef 63 91 e0 8a 29 7b 7d 43
*dot1xMsgTask: Aug 02 14:20:14.348: Including PMKID in M1 (16)
*dot1xMsgTask: Aug 02 14:20:14.348: [0000] a6 50 51 98 bc 10 74 ef 63 91 e0 8a 29 7b 7d 43
My computer sits in one location for a while, but then tries to roam again, and sends a PMKID, but it's the wrong one:
*apfMsConnTask_0: Aug 02 14:20:39.353: 00:16:ea:6e:29:b0 Received RSN IE with 1 PMKIDs from mobile 00:16:ea:6e:29:b0
*apfMsConnTask_0: Aug 02 14:20:39.353: Received PMKID: (16)
*apfMsConnTask_0: Aug 02 14:20:39.353: [0000] 96 c1 c5 7a 50 a3 ed 54 4e 4e 87 f9 05 6c 90 cc
*apfMsConnTask_0: Aug 02 14:20:39.353: 00:16:ea:6e:29:b0 No valid PMKID found in the cache for mobile 00:16:ea:6e:29:b0
Those are examples from a Cisco debug I just took from the controller, and it is sequential. Oddly if you continue to look at the log, the controller appears to be sending the PMKID that Windows replied with before, but then somewhere, Windows is getting
a different ID that it responds back in the next roam.
If you want to see the full debug from the controller or the packet capture I took at the same time, let me know.
Free Windows Admin Tool Kit Click here and download it now
August 2nd, 2011 12:36pm
Hi,
We need parallel debug logging from client/app. I'd suggest you go through a phone support case.Ketan Thakkar | Microsoft Online Community Support
August 19th, 2011 1:27am
Did you ever find a solution to this that allows PKC/OKC to work correctly with Cisco WLC's? It does not look like it works on any of our Win7 clients even though it appears to be configured.
Free Windows Admin Tool Kit Click here and download it now
September 6th, 2011 6:23pm
Sadly, no. I don't have any support contracts with Microsoft, so that's out. Cisco is pointing the finger at Microsoft, and at the moment, I agree.
Fortunately, the problem is small enough that it doesn't affect too many people at our facility.
September 6th, 2011 6:50pm