Far easier said than done on a big campus, where users are free to bring
whatever devices they want. It is also interesting that
circumstantially, this problem started on 4.0 code, and is resolved in
4.1 code- sort of points away from the individual drivers, as does other
anecdotal evidence. I haven't really heard of it happening on non-Cisco
systems, but that may just reflect Cisco's market share.
 
Lee H. Badman
Wireless/Network Engineer
Information Technology and Services
Syracuse University
315 443-3003
________________________________

From: Frank Bulk - iNAME [mailto:[EMAIL PROTECTED] 
Sent: Thursday, October 04, 2007 10:55 PM
To: [email protected]
Subject: Re: [WIRELESS-LAN] WPA "Countermeasures" - radios shutting down
in LWAPP for legitimate users
 
I've heard of this before.....my best understanding of the symptom is
that the access point has detected two MIC failures within 60 seconds.
Netgear does a nice job of summarizing the issue:
http://documentation.netgear.com/reference/nld/wireless/WirelessNetworki
ngBasics-3-15.html.
 
Unfortunately, I've heard that there are some buggy drivers that
generate frames with wrong MICs and so create this problem.  Hopefully
the MAC addresses are the same and you can trace them down and work with
the constituents to resolve the problem.
 
Regards,
 
Frank
 
From: Lee H Badman [mailto:[EMAIL PROTECTED] 
Sent: Thursday, October 04, 2007 8:23 AM
To: [email protected]
Subject: [WIRELESS-LAN] WPA "Countermeasures" - radios shutting down in
LWAPP for legitimate users
 
We are seeing huge quantities of this:
 
The AP '00:0f:f7:a7:a0:c0' received a WPA MIC error on protocol '0' from
Station '00:13:02:82:1c:8d'. Counter measures have been activated and
traffic has been suspended for 60 seconds.
 
Which means that radios are being disabled for 60 seconds- and all
networks on those radios- each time this countermeasure is invoked
because of something viewed as a potential attack happens for each user
listed, at the front end of the 802.1x authentication/encryption key
setup (we're using PEAP w/ MS-CHAP v/TKIP/WPA1).
 
What is very confusing- each user listed ends up on the network, just
fine. But in the meantime, we have radios being shut down all over the
place. This countermeasure is defined by the standard, so it's hard to
bash the hardware in this case. Clients involved are using Mac, XP, and
Vista- hundreds daily, and not consistent (sometimes a client has the
issue, sometimes not).
 
Our controllers are 4.0.207.
 
Cisco is saying a few things in response: this is likely a client driver
issue and that all drivers need to be kept up to date (easier said than
done on our campus). Also- in version 4.1 of the controllers, the
60-second "radio off" period can be turned off. Finally, WPA2 negates
this.
 
My questions- is anyone else seeing this, and have you found any causes
for good clients to show up as attackers and cause the radios to turn
off? And, has anyone found any real concerns with 4.1 code on the
controllers?
 
Thanks very much-
 
Lee H. Badman
Wireless/Network Engineer
Information Technology and Services
Syracuse University
315 443-3003
 
********** Participation and subscription information for this EDUCAUSE
Constituent Group discussion list can be found at
http://www.educause.edu/groups/. 
********** Participation and subscription information for this EDUCAUSE
Constituent Group discussion list can be found at
http://www.educause.edu/groups/.

**********
Participation and subscription information for this EDUCAUSE Constituent Group 
discussion list can be found at http://www.educause.edu/groups/.

Reply via email to