Wireless Access

Reply
Contributor II

iPad constant deauth on 1 AP

Hi there

Seeing strange one over the last few days. We have a teachers iPad that constantly drops the network every few seconds for about 3 or 4 goes and then eventually gives up and just doesn't connect. Turn wifi off and on and same thing happens again.

Same iPad connecting to different AP is stable. Different iPad connecting to same IP is stable.

Seems to be this iPad on this AP that is the issue.

Done so far : Set Logging Level debugging use-debug and watched the logs.

The first time it did this I got an error message that deauth was due to Client Match

 

Feb 17 16:15:56 :522008:  <NOTI> |authmgr|  User Authentication Successful: username=kw MAC=84:85:06:cf:9b:e4 IP=10.1.191.22 role=authenticated VLAN=133 AP=JNR_L2_Base1 SSID=Wireless@TTS AAA profile=TTS@Clearpass-aaa_prof auth method=802.1x auth server=Clearpass-Server

Feb 17 16:15:56 :522053:  <DBUG> |authmgr|  PMK Cache getting updated for 84:85:06:cf:9b:e4, (def, cur, vhow) = (133, 133, 16) with vlan=133 vlanhow=16 essid=Wireless@TTS role=authenticated rhow=7

Feb 17 16:15:56 :522026:  <INFO> |authmgr|  MAC=84:85:06:cf:9b:e4 IP=0.0.0.0 User miss: ingress=0x10156, VLAN=133 flags=0x48

Feb 17 16:16:17 :501105:  <NOTI> |stm|  Deauth from sta: 84:85:06:cf:9b:e4: AP 10.1.120.157-24:de:c6:d1:9d:81-JNR_L2_Base1 Reason Client Match

Feb 17 16:16:17 :522234:  <DBUG> |authmgr|  Setting idle timer for user 84:85:06:cf:9b:e4 to 300 seconds (idle timeout: 300 ageout: 0).

Feb 17 16:16:17 :501000:  <DBUG> |stm|  Station 84:85:06:cf:9b:e4: Clearing state

 

Turned wireless off and on and got the same deauth - but each time for reason 255 - could not get it to say Client Match again - 10 times went through this and each time said = reason 255

 

Feb 17 16:16:35 :522254:  <DBUG> |authmgr|  VDR - mac 84:85:06:cf:9b:e4 rolename logon fwdmode 0 derivation_type Initial Role Contained vp not present.

Feb 17 16:16:35 :522258:  <DBUG> |authmgr|  "VDR - Add to history of user user 84:85:06:cf:9b:e4 vlan 0 derivation_type Reset Role Based VLANs index 16.

Feb 17 16:16:35 :524124:  <DBUG> |authmgr|  dot1x_supplicant_up(): MAC:84:85:06:cf:9b:e4, pmkid_present:False, pmkid:N/A

Feb 17 16:16:35 :522243:  <DBUG> |authmgr|  MAC=84:85:06:cf:9b:e4 Station Updated Update MMS: BSSID=24:de:c6:d1:9d:89 ESSID=Wireless@TTS VLAN=133 AP-name=JNR_L2_Base1

Feb 17 16:16:36 :501114:  <NOTI> |stm|  Deauth from sta: 84:85:06:cf:9b:e4: AP 10.1.120.157-24:de:c6:d1:9d:89-JNR_L2_Base1 Reason 255

 

 

SO I thought - OK - Client Match makes sense if there is an issue so looked at Airwave it had a warning that the AP had too many clients (30 clients - as there was a set of iPads in the class in use).

 

Now moving the teacher iPad makes sense if ARM and client match are doing there job but what doesn't make sense is:

  • If the iPad is de-authed - from Base1 why did it not associate to 1 of the the other 7 AP's in the nearby bases - which are easily within range
  • Why was it only de-authing this iPad and not any others (there were 30 in the room after all).
  • When I moved the class iPads to another room powered down the AP clearing all associations.  I cycled the wireless on the Ipad and it joined the AP in Base 2 next door and stayed stable...seen here:

Feb 17 16:51:10 :522260:  <DBUG> |authmgr|  "VDR - Cur VLAN updated 84:85:06:cf:9b:e4 mob 0 inform 1 remote 0 wired 0 defvlan 133 exportedvlan 0 curvlan 133.

Feb 17 16:51:10 :522029:  <INFO> |authmgr|  MAC=84:85:06:cf:9b:e4 Station authenticate: method=802.1x, role=authenticated/authenticated//logon, VLAN=133/133, Derivation=7/16, Value Pair=1

Feb 17 16:51:10 :522008:  <NOTI> |authmgr|  User Authentication Successful: username=kw MAC=84:85:06:cf:9b:e4 IP=10.1.191.22 role=authenticated VLAN=133 AP=JNR_L2_Base2 SSID=Wireless@TTS AAA profile=TTS@Clearpass-aaa_prof auth method=802.1x auth server=Clearpass-Server

Feb 17 16:51:10 :522053:  <DBUG> |authmgr|  PMK Cache getting updated for 84:85:06:cf:9b:e4, (def, cur, vhow) = (133, 133, 16) with vlan=133 vlanhow=16 essid=Wireless@TTS role=authenticated rhow=7

Feb 17 16:51:11 :522026:  <INFO> |authmgr|  MAC=84:85:06:cf:9b:e4 IP=0.0.0.0 User miss: ingress=0x10051, VLAN=133 flags=0x48

 

  • When I powered back up the AP in Base 1 and cycled the iPad it rejoined this troublesome AP in Base 1 and seemed stable (for the 5 minutes before I headed home for the day).
  • My gut feel is this will come back tomorrow as it has for the past few days...

 

So big picture remains - any idea why this iPad is deauthing and why it wouldn't auto join the next nearest AP?

Note - the remainder of the 7 AP's at this year level only had 1 client each on them at the time.

Wally

Guru Elite

Re: iPad constant deauth on 1 AP

Wally,

 

What version of ArubaOS and what encryption is being used?

 



Colin Joseph
Aruba Customer Engineering

Looking for an Answer? Search the Community Knowledge Base Here: Community Knowledge Base

Contributor II

Re: iPad constant deauth on 1 AP

Hi there

AOS 6.3.0 and 802.1X WPA2 Enterprise AES

Wally

Guru Elite

Re: iPad constant deauth on 1 AP

When it is happening, try running the command "show ap remote debug mgmt-frames ap-name <name of ap>" to see the specific management frames going to and from that access point/



Colin Joseph
Aruba Customer Engineering

Looking for an Answer? Search the Community Knowledge Base Here: Community Knowledge Base

Contributor II

Re: iPad constant deauth on 1 AP

Will do..but will be tomorrow some time..will post when i get the results..
Occasional Contributor II

Re: iPad constant deauth on 1 AP

Hi there 

 

 

I will continue this topic from here . As per the above comments i am also facing the same issue 

 

 

Oct 15 07:59:58 :522038: <INFO> |authmgr| username=kshaikh MAC=c0:ee:fb:21:8c:4b IP=192.168.48.239 Authentication result=Authentication Successful method=radius-accounting server=ClearPass
Oct 15 08:00:25 :501105: <NOTI> |stm| Deauth from sta: c0:ee:fb:21:8c:4b: AP 192.168.104.54-d8:c7:c8:a3:67:03-B1-1st-4 Reason Client Match
Oct 15 08:00:25 :522036: <INFO> |authmgr| MAC=c0:ee:fb:21:8c:4b Station DN: BSSID=d8:c7:c8:a3:67:03 ESSID=KACST_Emp VLAN=222 AP-name=B1-1st-4
Oct 15 08:00:25 :522234: <DBUG> |authmgr| Setting idle timer for user c0:ee:fb:21:8c:4b to 300 seconds (idle timeout: 300 ageout: 0).
Oct 15 08:00:25 :501000: <DBUG> |stm| Station c0:ee:fb:21:8c:4b: Clearing state
Oct 15 08:00:25 :501080: <NOTI> |AP B1-1st-4@192.168.104.54 stm| Deauth to sta: c0:ee:fb:21:8c:4b: Ageout AP 192.168.104.54-d8:c7:c8:a3:67:03-B1-1st-4 Client Match

upon checking the management frames i found out the below 

 

 

Oct 15 08:00:24  deauth      d8:c7:c8:a3:67:03  c0:ee:fb:21:8c:4b  d8:c7:c8:a3:67:03  15      Client Match (seq num 0)
Oct 15 07:59:54  assoc-resp  d8:c7:c8:a3:67:03  c0:ee:fb:21:8c:4b  d8:c7:c8:a3:67:03  15      Success
Oct 15 07:59:54  assoc-req   c0:ee:fb:21:8c:4b  d8:c7:c8:a3:67:03  d8:c7:c8:a3:67:03  39      -
Oct 15 07:59:54  auth        d8:c7:c8:a3:67:03  c0:ee:fb:21:8c:4b  d8:c7:c8:a3:67:03  15      Success (seq num 2865)
Oct 15 07:59:54  auth        c0:ee:fb:21:8c:4b  d8:c7:c8:a3:67:03  d8:c7:c8:a3:67:03  58      -

 

 

Please suggest  why it is happening here 

 

Regards

Khalid Shaikh 

 

 

Regards
Khalid Shaikh
Nesma Telecom and Technology
ACMA ACMP ACCP CCIE R&S
Guru Elite

Re: iPad constant deauth on 1 AP

There is not enough information here. A deauth is a regular part of roaming. In your case it might be moved due to client match possibly. What is the problem?


Colin Joseph
Aruba Customer Engineering

Looking for an Answer? Search the Community Knowledge Base Here: Community Knowledge Base

Occasional Contributor II

Re: iPad constant deauth on 1 AP

HI 

 

Thanks for your reply .  The problem here is that user gets disconnect upon random duration . These are the logs which I have attach at morning.  

Regards
Khalid Shaikh
Nesma Telecom and Technology
ACMA ACMP ACCP CCIE R&S
Guru Elite

Re: iPad constant deauth on 1 AP

How many access points do you have and what type?

What is the transmit power on those access points?

 

This can easily be caused by access points where the transmit power is too high, causing roaming events when a user is not moving, or causing a client to be too sticky.



Colin Joseph
Aruba Customer Engineering

Looking for an Answer? Search the Community Knowledge Base Here: Community Knowledge Base

Occasional Contributor II

Re: iPad constant deauth on 1 AP

We have total of 355  AP 105 .

Show ap active shows different power levels

2.4 GHZ 15 min  20 max

5 GHZ 15 min 25 max

 

below is the setting on the default profile used

 

Adaptive Radio Management (ARM) profile "default"
-------------------------------------------------
Parameter                                                                    Value
---------                                                                    -----
Assignment                                                                   single-band
Allowed bands for 40MHz channels                                             a-only
80MHz support                                                                Enabled
Client Aware                                                                 Enabled
Max Tx EIRP                                                                  127 dBm
Min Tx EIRP                                                                  15 dBm
Rogue AP Aware                                                               Enabled
Scan Interval                                                                10 sec
Aggressive scanning                                                          true
Active Scan                                                                  Disabled
ARM Over the Air Updates                                                     Enabled
Scanning                                                                     Enabled
Multi Band Scan                                                              Enabled
VoIP Aware Scan                                                              Enabled
Power Save Aware Scan                                                        Disabled
Video Aware Scan                                                             Enabled
Ideal Coverage Index                                                         10
Acceptable Coverage Index                                                    4
Free Channel Index                                                           25
Backoff Time                                                                 240 sec
Error Rate Threshold                                                         50 %
Error Rate Wait Time                                                         30 sec
Channel Quality Aware Arm                                                    Disabled
Channel Quality Threshold                                                    70 %
Channel Quality Wait Time                                                    120 sec
Minimum Scan Time                                                            8
Load aware Scan Threshold                                                    1250000 Bps
Mode Aware Arm                                                               Disabled
Scan Mode                                                                    all-reg-domain
Cellular handoff assist                                                      Disabled
Client Match                                                                 Enabled
Client Match report interval (sec)                                           30
Allows Client Match to automatically clear unsteerable clients after ageout  Enabled
Client Match Unsteerable Client Ageout Interval                              2 Days 0 Hours
Client Match IOS Steer backoff (sec)                                         300
Client Match Band Steer G Band Max Signal (-dBm)                             45
Client Match Band Steer A Band Min Signal (-dBm)                             75
Client Match Sticky Client Check Interval (sec)                              3
Client Match Sticky client check SNR (dB)                                    18
Client Match SNR threshold(dB)                                               10
Client Match Sticky Min Signal                                               65
Client Match Restriction timeout (sec)                                       10
Client Match Load Balancing threshold (%)                                    20
Client Match VBR Stale Entry Age (sec)                                       120
Client Match Max steer failures                                              3
Client Match Load Balancing client threshold                                 30
Client Match Load Balancing SNR threshold (dB)                               30
Client Match Load Balancing signal delta bound (dB)                          5

 

 

Regards
Khalid Shaikh
Nesma Telecom and Technology
ACMA ACMP ACCP CCIE R&S
Search Airheads
cancel
Showing results for 
Search instead for 
Did you mean: