I have the 4400 controllers with 1130 APs. I have 32 users connected to two access point. Once users try to log in, the whole network gets really slow. When I sniffed the air there were a lot of "duration attacks"
I just want to know if anyone knows how we can prevent this from happening. We tested out HP access points with the same class and doesn't seem to have that issue. Thanks for your help. If you need more info let me know.
Can you narrow down the area it's coming from? If so, you can usually use a product such as Airmagnet or something free like Backtrack 2 to track down the device. I also know there are some issues with certain device drivers that will cause these type of issues on Cisco LWAPP systems and so far in my experience simply updating them can resolve. Depending on how big your wireless network is, you should be able to isolate the area it's occuring fairly easy by simply looking at your map and determining the ap's location
Thanks a lot of the reply. This is how the setup is. We have a class room with 2 access points and around 36 macbook laptops. The macbooks are the old g4s. All the laptops should have been updated to the latest software as well. Somehow I still catch some laptops sending out duration attacks.
Excerpt: "Meru's secret [manipulation of the RF] may leave a bitter aftertaste, especially if a neighboring business is running a Meru system on the same channel as your non-Meru system. Cisco was unambiguous in claiming that Meru is violating 802.11 standards by artificially manipulating the NAV (network allocation vector) value in certain duration fields (see "Duration, Duration, Duration" below). Meru denies these allegations, claiming its products are "100 percent standards-compliant." Based on our understanding of 802.11's virtual carrier sense architecture and the role that duration field values play in managing contention, we find Cisco's charges credible, but we'll reserve final judgment until other industry experts weigh in on this controversial issue."
In other words, by manipulating the carrier sense in an unorthodox manner, the Cisco APs never get a chance to talk on the RF.
For some reason, Cisco products appear to be more susceptable to this Meru-induced issue.
Your Cisco WLC should be able to see the adjacent WiFi devices - if any exist.
Or, if you have a wireless sniffer (AirMagnet, etc.), you might be able to see adjacent "rogue" access points. Even a laptop with WiFi might be able to see a list of foreign SSIDs that are not yours.
If you can get the wireless MAC address of these foreign APs (assuming that they are there), you can lookup OUI (the first three bytes of the MAC address) at the following site to determine the manufacturer of the access point:
If Meru pops up, it might be the source of your problem. If so, you may be able to work around this problem by using a channel other than that of the neighboring Meru WLAN (since Meru uses the *same* channel for *EVERY* access point in its WLAN - yes, bizarre, but true).
Transferring Crash file from standby:
Login to the Active WLC in HA.
(Cisco Controller) >transfer upload datatype crash
(Cisco Controller) >transfer upload filename <Desired filename>
(Cisco Controller) >transfer up...
This is the start of a display filter cross reference between Wireshark and OmniPeek.
The 1st installment is a table of advanced filters. More filters will be added as time allows.
It is a living doc, so check back for changes every so often
Please feel ...
I have created a Powershell script to automatically add a Wireless Guest User on Cisco WLCs. (tested on 2500 Series)
The script should be completely self explanatory.
Powershell SNMP Module (Install-Module -Name SNMP)
SNMP Write Access to...