04-09-2012 12:44 PM
Need help, why my controller DoS the client when it roam?
Controller: 3600, AOS 18.104.22.168
We are testing new laptops to be used for doctors in the hospital. During test, the laptop roamed and suddenly disconnected. When the laptop disconnected the log showed the laptop was DoS
(WC01) #show log all | include a0:88:b4:07:35:5c Apr 9 12:06:43 sapd: <127109> <WARN> |AP MOBW.1.120A@172.18.8.42 sapd| |ids-ap| AP(d8:c7:c8:23:0e:40): Power Save DoSn AP detected a Power Save DoS attack on client a0:88:b4:07:35:5c and access point (BSSID d8:c7:c8:18:4d:61 and SSID btnrh_wNEL 6). SNR of client is 7. Additional Info: Pwr-Mgmt-On-Pkts:49; Pwr-Mgmt-Off-Pkts:61. Apr 9 12:08:21 sapd: <127109> <WARN> |AP MOBW.1.120A@172.18.8.42 sapd| |ids-ap| AP(d8:c7:c8:23:0e:40): Power Save DoSn AP detected a Power Save DoS attack on client a0:88:b4:07:35:5c and access point (BSSID d8:c7:c8:23:0a:71 and SSID btnrh_wNEL 6). SNR of client is 24. Additional Info: Pwr-Mgmt-On-Pkts:54; Pwr-Mgmt-Off-Pkts:66. Apr 9 14:01:31 sapd: <127109> <WARN> |AP MOBW.1.120B@172.18.15.128 sapd| |ids-ap| AP(d8:c7:c8:23:0c:80): Power Save D An AP detected a Power Save DoS attack on client a0:88:b4:07:35:5c and access point (BSSID d8:c7:c8:23:0d:10 and SSID btnrhANNEL 11). SNR of client is 8. Additional Info: Pwr-Mgmt-On-Pkts:172; Pwr-Mgmt-Off-Pkts:72.
During the client de-auth, show auth-tracebuf indicated the client tried but failed re-authentication
Apr 9 13:58:32 station-down * a0:88:b4:07:35:5c 00:0b:86:8e:42:c8 - - Apr 9 13:58:32 station-up * a0:88:b4:07:35:5c 00:0b:86:8e:2c:c8 - - wpa tkip Apr 9 13:58:32 eap-id-req <- a0:88:b4:07:35:5c 00:0b:86:8e:2c:c8 1 5 Apr 9 13:58:32 eap-start -> a0:88:b4:07:35:5c 00:0b:86:8e:2c:c8 - - Apr 9 13:58:32 eap-id-req <- a0:88:b4:07:35:5c 00:0b:86:8e:2c:c8 1 5 Apr 9 13:58:32 eap-id-resp -> a0:88:b4:07:35:5c 00:0b:86:8e:2c:c8 1 39 host/nerh123910.btnrh.boystown.org Apr 9 13:58:32 rad-req -> a0:88:b4:07:35:5c 00:0b:86:8e:2c:c8 65409 237 Apr 9 13:58:32 eap-id-resp -> a0:88:b4:07:35:5c 00:0b:86:8e:2c:c8 1 39 host/nerh123910.btnrh.boystown.org
The only way to make this client came back is disconnect and reconnect the ssid.
Solved! Go to Solution.
04-09-2012 02:13 PM - edited 04-09-2012 02:23 PM
It seems like when the client is fast roaming, hitting the 6th or 7th AP in a short period, controller (or AP) will IDS DoS this client.
Can we adjust these parameters: number of APs in x seconds clients can hit before being DoS? For the hospital environment, roaming is essential.
04-19-2012 02:34 PM
Just redo the test with user-debug and send log to TAC.
The problem is consistent, after 7-9 APs roam, in about 5 minutes, client will be deauth and DoS by the AP with error reason 255. Anyone knows the meaning of error 255?
TAC is working on this case .
04-19-2012 07:34 PM
That is a generic error. There are association thresholds that could be exceeded for that client.
Aruba Customer Engineering
Looking for an Answer? Search the Community Knowledge Base Here: Community Knowledge Base
04-23-2012 07:02 AM - edited 04-23-2012 02:09 PM
In "ids dos-profile default" a knob "Detect Power Save DoS Attack" was enable by default.
From the UG 6.1:
"Detect Meiners Power Save DoS Attack
To save on power, wireless clients will "sleep" periodically, during which they cannot transmit or receive. A
client indicates its intention to sleep by sending frames to the AP with the Power Management bit ON. The
AP then begins buffering traffic bound for that client until it indicates that it is awake. An intruder could
exploit this mechanism by sending (spoofed) frames to the AP on behalf of the client to trick the AP into
believing the client is asleep. This will cause the AP to buffer most, if not all, frames destined for the client."
I am going to disable this IDS Detect Power Save DoS Attack. Any advices?
05-07-2012 06:50 AM
TAC suggested disabling 'mode-aware' in arm profile. I disagreed because we deployed APs in hospital where client roaming is critical, so the APs were deployed at high density, about 20 feet apart. In this environment ‘mode-aware’ is important to help avoid high level of interference.
At this time, disable PowerSave DoS in IDS work for us.
05-17-2012 11:08 AM
We have PC's go into power save mode and trigger the power dos attack which then blacklists them. Aside from disabling the feature - which metric should be modified below to prevent normal laptop operations from trigerring a blacklisting?
Detect Power Save DoS Attack X
Power Save DoS Detection Threshold 90%
Power Save DoS Detection Minimum Frames 60
Power Save DoS Detection Quiet Time 900 sec
05-30-2012 07:30 AM - edited 05-30-2012 07:32 AM
UPDATE from TAC:
In "ids dos-profile default", double "Power Save DoS Detection Minimum Frames" to 120
We re-enable "Detect Power Save DoS Attack" and still testing. it seems ok.