Forum

To all concerned:

There seems to be a bug when using MAC Address ACLs to Block or Allow Client Association to Cisco access points with the 12.3(2)JA and JA2 code. It just does not flat out work. Older code such as 12.2(15) is flaky and works only about half of the time. I'm still looking at older versions.

Apparently there is a bug with association filters in 12.3(2) firmware. I'm opening a TAC case on it.

When you experience problems with Cisco products that you can't overcome, the fastest way to get them resolved is by using Cisco's Technical Assistance Center at www.cisco.com/tac.

Joel

Cisco TAC does know about the bug. It is ID: CSCeh08952 and will most likely be resolved in the next maintenance release of 12.3(2) code.

Joel

Joel rocks. I knew there was a reason he was triple crown certified. ;-D Thanks for taking the time to hunt that down Joel. This is affecting our ability to move up to the latest code in the CWAP class. I've stepped down to 12.2(15) and it only works about half the time...it works and then stops working...and starts working again. Flakey for sure.

Thanks David for mentioning this. It may not mean much to the average enterprise user, but to a CWAP instructor, it can be a pain. :) I'm downgrading even further to XR2 and then to 12.2 if that doesn't do the trick. I sure wish Cisco would get this bug fixed in a hurry.

Devinator

Joel wins a prize. A golf shirt!

Not much of a need for MAC filters/MAC ACLS in the enterprise these days do to the spoofing and the administrative headache. I teach that it still makes since in the enterprise when using older legacy radio cards that might have little or no security in the client utilities... like some old handheld scanners. A MAC filter is better than nothing. Also makes sense in bridging as another "layer" of security because you only have to create a few filters. By no means obviously is it the end all security solution.

And of course it still makes sense in SOHO environments as another layer of security because once again you only have to create a few filters. Put's your apple higher up on the fruit tree.

To me the EVEN BIGGER issue is how the Cisco MAC ACL is EVEN apply to prevent the protection mechanism from kicking in!!!

I thought in a mixed-mode network that if a DSSS client gets associated..... then the protection mechanism kicks in and the AP begins signaling everyone in the Beacons.

However, if you use a MAC ACL with a Cisco AP,

I looked at the process in Wildpackets..... With the MAC ACL, the DSSS stations receive an association response frame with a response code of success, however the AP immediately sends a DEAUTH frame and knocks off the station.

Despite the temporary association by the DSSS clients... the protection mechanism does not kick in! Which is great for the classroom. But this makes so sense because the DSSS clients do indeed get associated for a few microseconds.

According to the standard, the protection mechanism should actually kick in.

I should probably post this to the standards forum.

I get exactly the same thing with AirMagnet. Section 7.3.2.13 of 802.11g says, "If one or more NonERP STAs are associated in the BSS, the Use_Protection bit shall be set to 1 in transmitted
ERP Information Elements." What SHOULD happen if the Cisco AP were complying with the standard is that it would immediately enable protection. Instead, it seems that having an Association ACL enabled tells the AP, "nevermind the rules, let's just not enable protection like we're supposed to, get this guy bumped off the AP, and then sweep it under the rug in a big hurry."

Sometimes the power of IOS can be a big benefit. It allows you to do all kinds of nutty stuff like this. It's all about total control of the packets that traverse (or don't traverse) the device -- but -- it doesn't help much when wacky bugs get in the way, does it?

Joel

3 main things can cause an 802.11b/g AP to kick on protection:

1. An 802.11b client station associates with it. This sets the Use_Protection bit to 1 and the Non-ERP Station Present bit to 1.

2. An 802.11b access point is somewhere near it - within hearing range

3. An 802.11b/g access point is somewhere near it - within hearing range - with the Use_Protection bit set to 1.

Even with the Association ACLs applied to prevent problem #1 above, you still have a problem with #2 and #3 above unless you do the following:

Disable all 802.11b rates (1, 2, 5.5, & 11 Mbps) on the AP, and set at least one OFDM data rate to basic (6 Mbps makes the best choice). This works in a lab environment where your goal is to prevent protection from being enabled at all costs, but not in a production environment where protection may be needed. In production environments, the best way to approach this is to minimize ERP (802.11b) station connections to ERP (802.11g) APs by enabling 1, 2, 5.5, and 11 Mbps, and setting one of the OFDM rates (ie. 6 Mbps) as Basic (required). This allows the AP to use protection and to announce use of it, but will minimize 802.11b connections. Since you wouldn't have a problem with #1 above, you'd likely then not have a problem with #2 and #3 either unless you had neighboring APs from another organization.

From a classroom standpoint, this is a pain all the way around.

Devinator

Gentlemen:

1. This Cisco bug reference appears unrelated to the protection problems observed here.

CSCeh08952 Bug Details
Headline: IP filters with TCP option does not work on AP running IOS

http://www.cisco.com/cgi-bin/Support/Bugtool/onebug.pl?bugid=CSCeh08952&Submit=Search

2. Using MAC filters to block nonERP client associations (or promptly terminate them) can avoid some but not all occasions of protection use (more on this below).

3. Since MAC filters are proprietary we need not fault vendors for delaying standard consequences of association, such as protection, while the access point processes the filter.

4. Using proprietary classifications for ERP access points as B-Only, G-Only, or B/G-Only confuses rather than helps when trying to predict and/or avoid protection. A station involved in provoking protection is either DSSS or HR/DSSS, also known as nonERP. A station involved in requiring or using protection is ERP.

5. Protection is enabled and disabled by each ERP station for its own transmissions. Under only one circumstance must a station enable protection -- when it receives an ERP information element with Use_Protection=1 from its access point in a beacon (or when it is the access point sending such a beacon). Otherwise any ERP station may use protection at any time it feels like it. It is up to each vendor. The standard suggests several possibilities for serious consideration by vendors.

6. Protection is required or not required by each ERP access point. Under only one circumstance must an access point require protection -- when a nonERP client is associated with it. In that case an ERP access point shall set both its Use_Protection=1 and NonERP_Present=1. Otherwise any ERP access point may set either Use_Protection=1 or NonERP_Present=1 at any time it feels like it. It is up to each vendor. The standard suggests several possibilities for serious consideration by vendors.

7. More precisely Use_Protection=1 means "?I, your ERP access point, for any one of sundry reasons have decided to use protection mechanisms and I want my ERP clients to as well.?" And NonERP_Present=1 means "?I, your ERP access point, have spotted at least one of those pesky nonERP stations in our channel doing something more than simply probing for access points, and that is probably the reason I also set Use_Protection=1.?" Usually but not always Use_Protection and NonERP_Present are either both set to zero or both set to one.

8. If the object is to avoid the use of protection in our BSS regardless of the need for protection, as one might want in a lab or classroom demonstration, and one can do without all of the nonERP rates, there is a solution -- remove all nonERP rates from the access point's supported rates list. An ERP station that cannot transmit at a nonERP rate cannot transmit a protection frame -- but it can suffer uneven and unpredictable performance degradation.

9. If the object is to minimize the use of protection in our BSS but to use it in those instances when our vendor has deemed it will help avoid uneven and unpredictable performance degradation, first we must both block nonERP associations (by having at least one ERP rate in the basic rates list) and support transmissions that can be demodulated by nonERP stations (by having at least one nonERP rate in the supported rates list of the access point). Then we must discover what other protection triggers the vendors have coded and adjust for them if possible.

10. The only occasion for an ERP station to use protection is when it is contending in the channel with a nonERP station and intends to use ERP-OFDM to communicate. A nonERP station, client or access point, is identified as such by its supported rates list published in various management frames. If a station's supported rates list contains nothing more than 1, 2, 5.5, and 11, then a receiving ERP station will assume the frame was transmitted by a nonERP station. Under these circumstances an ERP vendor is well advised to code his ERP station to use protection. (One exception is if the nonERP client is only passing through, such as might be the case if its supported rates list is found in nothing more than its probe request frames.)

11. Besides detecting nonERP present by receiving supported rates lists in management frames, I am aware of one other vendor specific protection trigger. Cisco ERP access points "require" protection in their own BSS's when receiving beacons from other ERP BSS's where the ERP information element contains both Use_Protection=1 and NonERP_Present=1. However in this case the Cisco access point leaves its own NonERP_Present=0 which keeps the next Cisco access point in a series from itself requiring protection. This is the so-called protection ripple effect.

12. If protection in our BSS shifts erratically between required and not required, enabled and not enabled, used and not used, it is not likely the fault of bugs in the software or hardware. It is more likely a weak communications path occasioned by channel separation or range. If you insist on protection being either always used or always not used then try a different channel, lower the power, or reorient the antenna. Or, as put by Dr. Strangelove in the 1960's, "learn to stop worrying and love the bomb."

I hope this helps. Thanks. /criss