In my WCS, I see hundreds of rogue AP. Most of them are my AP also controled by my WiSMs. Wy does I get rogue report for them? The radio mac of the rogue report is usualy one digit higher then the base mac of the AP
We're having the exact same problem with ours. We have an open TAC case, but are waiting for a software update to see if that corrects the problem. Supposedly, this is a known issue...
Same here - hundreds of rogues, both 1242's and 1230's. What software are you all running on your controllers? We are at 18.104.22.168, upgrading to 22.214.171.124 early next week for other reasons. Does anyone know what, if any, negative effect this may have on clients and/or hardware?
we're running the most current version of 3.2.x. The response I got from TAC is:
To get the fix you are looking for concerning the false rogues you will have to go to the 4.0 release, 126.96.36.199.
We haven't tried this release yet because we're leary, but will try it soon. As for negative effects, we were worried that the 4.0.x releases would kill our 1200s (known bug) but as of Friday, the TAC guy told me:
We have done testing on the latest 4.0 image an confirmed that the
issues you are talking about have been resolved, you can upgrade to
188.8.131.52 without having to worry about those issues.
So if it blows up when we go to 4, i won't be a happy camper...
I totally agree, we are just as leary. Are you on 184.108.40.206 right now? Interesting to hear though, every upgrade we perform on the WiSMs fix some things, and break others. I'm curious if the false rogue bug is just cosmetic or if it is truly affecting clients and the "rogues". If you can, keep in touch on this thread. I'd like to see how we both make out on this.
I don't know if this is related or not:
I have been working with Cisco TAC and they indicate that the following false alarm: "Disassociation Flood" alarm is due to a software bug that is to be fixed in the November timeframe (aka Concannon release):
"IDS Signature attack detected. Signature Type: Standard, Name: Disassoc flood, Description: Disassociation flood, Track: per-signature, Detecting AP Name"
What caught my attention to relate this to what you are describing is that the error/trap indicates that the supposed disassociation flood is coming from the radio MAC addresses of our own trusted APs being controlled by the WLC.
Bug is identified as CSCse70641
Externally found severe defect: Assigned (A) Problems with signatures in 220.127.116.11 Symptom:High number of 'Disassoc flood' and 'Broadcast Probe floo' alarms. In3.2 this is not showing up, for controllers on the same area The shorter mask of 4.0 seems to match additional frames resulting infalse positives Conditions: Between 3.2 and 4.0 versions, there are several changes on the standardsignature database. For 3.2, for example, signature 7 (Disassoc flood)was 0:0x00A0:0x03FF, on 4.0 now is 0:0:0x00A0:0x00FF Additionally thisdoes not matches the information present on the header of the signaturefile. If the byte stream is compared, for a disasociation flood, theframe starts with 0xA000, after applying either of the twomasks, results in 0, failing the verification. For the signature to becorrect, it a double byte swapping is needed, which is not documented orpresent.
The current workaround is as follows:
To disable the signature file -
In the controller, go to 'Security' --> 'Wireless Protection Policies'
--> 'Standard Signatures' and click 'detail' on the far right of the
signature you wish to disable. You will see a 'State' check box, simply
hit apply. The signature will now show in a disabled state.
Hope this helps
The base radio MAC gets removed before being listed in the GUI reports but the subsequent MAC's get listed then you will see them being "deleted" I am not sure if there is already a DDTS to correct this reporting issue.
we're also facing the false rogues alarm. The bug filed is CSCse87066. Currently we're running an inoffical WLC image which does not show these problems any more