"The duration value in the WLAN frame indicates the time duration in milliseconds for which the channel is reserved. The Network Allocation Vector (NAV) stores this duration information. The rule is that any node can transmit only if the NAV reaches zero.
Attackers make use of the above vulnerability. They inject packets into the WLAN with huge duration values. This would force the other nodes in the WLAN to keep quite as they cannot send any packet until this value reaches zero. If the attacker sends such frames continuously it will prevent other nodes in the WLAN from operation for a long time and there by disrupting the entire wireless service."
The Omnipeek sniffer or some wireless sniffers can identify this attack and the packets can be seen in the logs. This effectively make the wireless network down, as many devices will be waiting and the attacker will be utilizing the bandwindth."
Some of the other examples where this type of issue is identified :
1 ) Meru Wireless AP
Below excerpts taken from
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).
2) Apple IPhone
The finding in question was that the Apple iPhone, iPad, and other mobile devices based on the latest Broadcom chipsets are setting really long Duration values in the range of 10-14ms within Wi-Fi control frames (e.g. RTS/CTS-to-self). This essentially reserves the medium for the device to transmit without a collision. The problem is that this is an excessively long period of time for an 802.11n capable device, and through my packet analysis I have found that no large frame transmission is subsequently occurring. This indicates that a performance problem may exist with the devices, and may be reported as an NAV DoS attack on the network by WIPS systems.
3) Intel client
Intel clients use the technique of sending a long duration (usually 4ms) in an RTS frame, sending their data and then releasing with a CFE frame. They only do this under certain circumstances however. You can see it by associating an 11n Intel client (I used a 6205) to an 11n AP (using the 2.4GHz radio) and then associating a legacy (non-11n) client. From a wired pc, then ping the 11n client. You'll see the RTS frames that the 11n client sends (for wireless protection) have a large duration and after it transmits the ping response, it sends a CFE.
So someone at Intel believes this is a better method of sending data in a crowded environment. They don't do this behavior in 5GHz as far as I've seen. Broadcom may be trying to replicate something like this.
So if in your WLAN network if you are seeing such packets, try to identify the device, client or AP, see if its one of above. If not, post in comments.