cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
7244
Views
0
Helpful
22
Replies

Problems with 802.1x and Atheros cards

lynne.meeks
Level 1
Level 1

We have just discovered a problem with 802.1x authentication and Atheros cards.

We have seen this on both MAC OS X 10.6.0 systems and an XP System

This appears to be a DHCP problem in that clients don't get an IP address unless they reboot- which usually fixes it. Sometimes the controller will think the client is connected with a valid IP but the client doesn't actually get the address (never sends an ACK to the offer)

Then it will work until they try to reconnect again after a suspend or roaming to a new AP

Anybody seen this? It's making our network look bad since we have a lot of MACs with Atheros cards...

thanks,

Lynne

22 Replies 22

dennischolmes
Level 7
Level 7

Try disabling dhcp by proxy. That tends to slow down the dhcp process significantly and disabling it allows you to track dhcp requests and lease times easier. In the WLC gui go to controller, advanced, dhcp, and then take the check mark out of the box. This will stop the dhcp relay mechanism where all dhcp requests appear to the dhcp server to come from the virtual interface of the controller.

sin
Level 1
Level 1

I have seen this problem a couple of time. Try setting session-timeout under Wlan->Advanced to 65535. This could very well solve it. If you try pleas post feedback here. I'm trying to gather info on this bug.

kirbus_inc
Level 1
Level 1

We also are having simliar issues. Did you find a resolution?

I would also like to know the answer to this.  I ran into this same problem a few days ago with a Mac, but I'll need to verify if it's an Atheros card.  I'll try the suggested fixes if so.  Does your debug look something like this by any chance?

..........

*Mar 26 13:52:43.439: 00:21:e9:e2:e0:04 0.0.0.0 L2AUTHCOMPLETE (4) Change state to DHCP_REQD (7) last state DHCP_REQD (7)
*Mar 26 13:52:43.439: 00:21:e9:e2:e0:04 0.0.0.0 DHCP_REQD (7) pemAdvanceState2 4473, Adding TMP rule
*Mar 26 13:52:43.439: 00:21:e9:e2:e0:04 0.0.0.0 DHCP_REQD (7) Adding Fast Path rule
  type = Airespace AP - Learn IP address
  on AP 00:0f:34:89:42:30, slot 0, interface = 29, QOS = 0
  ACL Id = 255, Jumbo F
*Mar 26 13:52:43.439: 00:21:e9:e2:e0:04 0.0.0.0 DHCP_REQD (7) Successfully plumbed mobile rule (ACL ID 255)
*Mar 26 13:52:43.439: 00:21:e9:e2:e0:04 Stopping retransmission timer for mobile 00:21:e9:e2:e0:04
*Mar 26 13:52:43.445: 00:21:e9:e2:e0:04 0.0.0.0 Added NPU entry of type 9, dtlFlags 0x0
*Mar 26 13:52:43.445: 00:21:e9:e2:e0:04 Sent an XID frame
*Mar 26 13:52:45.423: 00:21:e9:e2:e0:04 0.0.0.0 DHCP_REQD (7) State Update from Mobility-Incomplete to Mobility-Complete, mobility role=Local, client state=APF_MS_STATE_ASSOCIATED
*Mar 26 13:52:45.423: 00:21:e9:e2:e0:04 0.0.0.0 DHCP_REQD (7) pemAdvanceState2 4154, Adding TMP rule
*Mar 26 13:52:45.423: 00:21:e9:e2:e0:04 0.0.0.0 DHCP_REQD (7) Replacing Fast Path rule
  type = Airespace AP - Learn IP address
  on AP 00:0f:34:89:42:30, slot 0, interface = 29, QOS = 0
  ACL Id = 255, Jumb
*Mar 26 13:52:45.423: 00:21:e9:e2:e0:04 0.0.0.0 DHCP_REQD (7) Successfully plumbed mobile rule (ACL ID 255)
*Mar 26 13:52:45.429: 00:21:e9:e2:e0:04 0.0.0.0 Added NPU entry of type 9, dtlFlags 0x0
*Mar 26 13:52:45.429: 00:21:e9:e2:e0:04 Sent an XID frame
*Mar 26 13:53:07.105: CCKM: Send CCKM cache entry
*Mar 26 13:53:13.499: CCKM: Send CCKM cache entry
*Mar 26 13:53:15.076: CCKM: Send CCKM cache entry
*Mar 26 13:53:45.877: CCKM: Send CCKM cache entry
*Mar 26 13:53:46.676: CCKM: Send CCKM cache entry
*Mar 26 13:53:57.197: CCKM: Send CCKM cache entry
*Mar 26 13:54:02.345: CCKM: Send CCKM cache entry
*Mar 26 13:54:35.889: CCKM: Send CCKM cache entry
*Mar 26 13:54:43.312: CCKM: Send CCKM cache entry
*Mar 26 13:54:43.424: 00:21:e9:e2:e0:04 0.0.0.0 DHCP_REQD (7) DHCP Policy timeout
*Mar 26 13:54:43.424: 00:21:e9:e2:e0:04 0.0.0.0 DHCP_REQD (7) Pem timed out, Try to delete client in 10 secs.
*Mar 26 13:54:43.424: 00:21:e9:e2:e0:04 Scheduling deletion of Mobile Station:  (callerId: 12) in 10 seconds
*Mar 26 13:54:53.427: 00:21:e9:e2:e0:04 apfMsExpireCallback (apf_ms.c:418) Expiring Mobile!
*Mar 26 13:54:53.427: 00:21:e9:e2:e0:04 apfMsExpireMobileStation (apf_ms.c:4413) Changing state for mobile 00:21:e9:e2:e0:04 on AP 00:0f:34:89:42:30 from Associated to Disassociated

........

What version of WLC code are you running? Im betting 6.0.188?

Yes, I'm running 6.0.188.  DHCP Required and DHCP proxy are disabled.  Weird thing is, the same user can connect just fine using another Mac. The user is connecting to the same controller in both instances.  Here's the debug from a successful attempt:

.......

*Mar 26 16:24:31.129: 00:21:e9:e6:f9:27 0.0.0.0 DHCP_REQD (7) pemAdvanceState2 4473, Adding TMP rule
*Mar 26 16:24:31.129: 00:21:e9:e6:f9:27 0.0.0.0 DHCP_REQD (7) Adding Fast Path rule
  type = Airespace AP - Learn IP address
  on AP 00:0f:34:89:42:30, slot 0, interface = 29, QOS = 0
  ACL Id = 255, Jumbo F
*Mar 26 16:24:31.129: 00:21:e9:e6:f9:27 0.0.0.0 DHCP_REQD (7) Successfully plumbed mobile rule (ACL ID 255)
*Mar 26 16:24:31.129: 00:21:e9:e6:f9:27 Stopping retransmission timer for mobile 00:21:e9:e6:f9:27
*Mar 26 16:24:31.135: 00:21:e9:e6:f9:27 0.0.0.0 Added NPU entry of type 9, dtlFlags 0x0
*Mar 26 16:24:31.135: 00:21:e9:e6:f9:27 Sent an XID frame
*Mar 26 16:24:33.121: 00:21:e9:e6:f9:27 0.0.0.0 DHCP_REQD (7) State Update from Mobility-Incomplete to Mobility-Complete, mobility role=Local, client state=APF_MS_STATE_ASSOCIATED
*Mar 26 16:24:33.121: 00:21:e9:e6:f9:27 0.0.0.0 DHCP_REQD (7) pemAdvanceState2 4154, Adding TMP rule
*Mar 26 16:24:33.121: 00:21:e9:e6:f9:27 0.0.0.0 DHCP_REQD (7) Replacing Fast Path rule
  type = Airespace AP - Learn IP address
  on AP 00:0f:34:89:42:30, slot 0, interface = 29, QOS = 0
  ACL Id = 255, Jumb
*Mar 26 16:24:33.121: 00:21:e9:e6:f9:27 0.0.0.0 DHCP_REQD (7) Successfully plumbed mobile rule (ACL ID 255)
*Mar 26 16:24:33.127: 00:21:e9:e6:f9:27 0.0.0.0 Added NPU entry of type 9, dtlFlags 0x0
*Mar 26 16:24:33.127: 00:21:e9:e6:f9:27 Sent an XID frame
*Mar 26 16:24:34.300: CCKM: Send CCKM cache entry
*Mar 26 16:24:41.545: CCKM: Send CCKM cache entry
*Mar 26 16:25:05.125: CCKM: Send CCKM cache entry
*Mar 26 16:25:05.659: CCKM: Send CCKM cache entry
*Mar 26 16:25:06.332: CCKM: Send CCKM cache entry
*Mar 26 16:25:08.379: CCKM: Send CCKM cache entry
*Mar 26 16:25:18.367: CCKM: Send CCKM cache entry
*Mar 26 16:25:24.756: CCKM: Send CCKM cache entry
*Mar 26 16:25:42.158: CCKM: Send CCKM cache entry
*Mar 26 16:25:59.071: CCKM: Send CCKM cache entry
*Mar 26 16:26:02.631: CCKM: Send CCKM cache entry
*Mar 26 16:26:12.867: CCKM: Send CCKM cache entry
*Mar 26 16:26:31.121: 00:21:e9:e6:f9:27 0.0.0.0 DHCP_REQD (7) DHCP Policy timeout
*Mar 26 16:26:31.121: 00:21:e9:e6:f9:27 0.0.0.0 DHCP_REQD (7) Pem timed out, Try to delete client in 10 secs.
*Mar 26 16:26:31.121: 00:21:e9:e6:f9:27 Scheduling deletion of Mobile Station:  (callerId: 12) in 10 seconds
*Mar 26 16:26:34.258: 00:21:e9:e6:f9:27 Orphan Packet from 136.165.201.76 on mobile
*Mar 26 16:26:34.258: 00:21:e9:e6:f9:27 136.165.201.76 DHCP_REQD (7) Change state to RUN (20) last state RUN (20)

*Mar 26 16:26:34.259: 00:21:e9:e6:f9:27 136.165.201.76 RUN (20) Reached PLUMBFASTPATH: from line 4958
*Mar 26 16:26:34.259: 00:21:e9:e6:f9:27 136.165.201.76 RUN (20) Replacing Fast Path rule
  type = Airespace AP Client
  on AP 00:0f:34:89:42:30, slot 0, interface = 29, QOS = 0
  ACL Id = 255, Jumbo Frames =
*Mar 26 16:26:34.259: 00:21:e9:e6:f9:27 136.165.201.76 RUN (20) Successfully plumbed mobile rule (ACL ID 255)
*Mar 26 16:26:34.259: 00:21:e9:e6:f9:27 Assigning Address 136.165.201.76 to mobile

.........

Hello,

We are running 6.0.188. We are having the same issues with our Atheros cards but they are in PC tablets not MAC's. Has anyone found a work around that works or can pinpoint what and why this is happening?

Are you using DHCP REQUIRED!? If you are I would suggest un-checking this box. Lets see what happen.. Here is more  about DHCP requried...

http://www.my80211.com/cisco-wlc-cli-commands/2009/12/30/wlc-dhcp-address-assignment-required-option.html

"Satisfaction does not come from knowing the solution, it comes from knowing why." - Rosalind Franklin
___________________________________________________________

Have you tried disabling OKC (Opportunistic Key Caching) -I'm not sure what the Cisco term for it is, and see

if that works - I've seen similar problem on other networks, and although not ideal for roaming, at least you can connect.

OK guys. Bump up to 6.0.196 and let me know if you still have the problems. I am hearing that there might be some dropped dhcp requests as an undocumented bug in.188. Let me know if this fixes your issues.

We'll do that this weekend.  The Mac in question above is an Imac 8,1 and I believe it has an Atheros chipset (I read that Macs started using Broadcoms late 2008).  We had another ticket come in today about a user having the same problems with two other Macs and an XP machine. I'll update once we've upgraded.

Hi Eric,

Please let us know how it goes this weekend.

Thanks,

Shellie

Alright, we upgraded over the weekend and haven't had any tickets about this problem since.  It's hard to tell if the problem was 100% resolved since it was intermittent to begin with, but we're good so far.  The upgrade also got rid of the "ap draws low power" alarms. The upgrade went smoothly except for one controller on a WiSM locking up and one AP being stubborn and not joining a controller.

Hi Eric,

We just upgraded last night and so far we have not seen any issues. We are crossing our fingers

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: