Wireless Access

Hello,

We had an issue with a customer with an iPad who were experiencing intermittent connectivity to the wifi network.

Looking at this goodput and indicated that he had none basically. They were very low.

SNR was about 10. He was on CH 40, HT.

We did notice a block ack attack that was detected during the time he was experiencing his issues.

I need to know if this attack was the absolute cause of the issue as we only have 1 trap detected of this event for this user.

Would such a low SNR produce this type of IDS event? or are they un-related and there truly was some source inteference or attack that produced this event.

Please keep in mind that this a corporate environment, downtown urban city on the 5th floor of an office building

Here are the details of the trap. (mac addresses were changed)

10/17/2012 12:16 PM

wlsxBlockAckAttackDetected wlsxTrapAPMacAddress.0: D8:C7:C8:YY:XX:ZZ,
wlsxTrapReceiverMac.0: D8:C7:C8:YY:XX:ZZ, wlsxTrapSnr.0: 10,
wlsxTrapAPLocation.0: correlated-DV-C-199B-05-AP01, wlsxTrapAPChannel.0:
40, wlsxTrapTargetAPBSSID.0: D8:C7:C8:YY:XX:ZZ, wlsxTrapAPRadioNumber.0:
1, wlsxTrapTime: 10/17/2012 12:37:49 UTC-4, wlsxTrapSourceMac.0:
DE:AD:BE:EF:CA:FE

How would I protect against it?

Pmonardo,

I suspect this was not an attack but rather control traffic related to the low SNR client.

A lot of mobile clients including IOS devices behave in ways that make it difficult for the infrastructure to manage them, especially around power save behavior.  We have various optimizations to "nudge" the client to interact with us to maintain state.  One of those is that we will send Block Ack Requests to a weak or disappeared client under certain conditions.  This can appear as a BAR storm.

One situation where this can occur is outdoor campus networks where you have clients come out of a building, move to another building, and go back indoors.

In your case, your output shows the AP itself as the target which would not necessarily be consistent with this explanation.   

Regardless, the solution to try is to set "Maximum Transmit Failures" to a value of anywhere between 15 and 20.  This will force the AP to age out weak or non-present clients that are no longer engaging properly with the infrastructure.  You can find this parameter under the SSID profile.   From the CLI it is called "max-tx-fail" and defaults to disabled  (no limit).

If that does not clear up the issue I recommend you open a TAC case and have a support engineer work through your specific situation and configuration in more detail.

Thank you for your input.

Currently our value is set to 0.

We possibly have clients going from the 5th floor to the 56th floor where the service is offered. Two separate controllers basically configured the same way but are on different networks.

If I try this solution by setting the "Maximum Transmit Failures" to 15-20, what impact on the infrastructure can it have?

I would definitely like to limit the IDS events that are not indicative of a problem and make sure the ones we do get are legit.

Just curious if you were able to find a resolution to this issue.. I have been experiencing the same problem with a Linux based mobile router (InMotion Router OMM).

I have tried turning on BC/MC Optimization, increasing the "Max Transmit Failures" to 20 under the SSID settings. Also tried turning off "Detect Block ACK DoS" under IDS settings.

The device is deleted from the controller causing the connection to drop on the router device. Although the device reports that the wireless connection is fine, no traffic (ping packets in this case) are able to go through. This happens every 1 minute or so which is very disturbing for any continous wireless communication.

Here are some other posts regarding the Block ACK packets but there are no resolutions posted:

http://community.arubanetworks.com/t5/802-11n-and-802-11ac-Basics-RF/Block-Ack-Request/td-p/51284

http://community.arubanetworks.com/t5/Wireless-IPS-and-Content/Block-Ack-Attack-the-cause-of-wifi-outage/td-p/48270

http://community.arubanetworks.com/t5/802-11n-and-802-11ac-Basics-RF/Block-ack-attack-causes/td-p/57184

Thanks!

We indeed make the changes to MAX-TX-Fail to 15 along with a bunch of others a while back...trying to remember them all.

- Local probe threshold was changed to 30

- station-handoff assist was enabled

- DOS Prevention

amongst others.

Did this fix the problem? I cannot tell you 100% to be honest, it definitely improved mobility and made users associate to the correct AP as we had a technician walk the floor after we made the changes and his SNR was always good and he was able to dissasociate/associate to the proper APs relatevely seamlessly.

I have not turned on BC/MC Optimization that is for sure. I should enable Drop Broadcast and Multicast but that will require a maintenance window for the client.