Wireless Access

last person joined: yesterday 

Access network design for branch, remote, outdoor, and campus locations with HPE Aruba Networking access points and mobility controllers.
Back to discussions
Expand all | Collapse all

iPad constant deauth on 1 AP

This thread has been viewed 2 times

  • 1.  iPad constant deauth on 1 AP

    Posted Feb 17, 2014 05:43 AM

    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



  • 2.  RE: iPad constant deauth on 1 AP

    EMPLOYEE
    Posted Feb 17, 2014 05:59 AM

    Wally,

     

    What version of ArubaOS and what encryption is being used?

     



  • 3.  RE: iPad constant deauth on 1 AP

    Posted Feb 17, 2014 06:53 AM

    Hi there

    AOS 6.3.0 and 802.1X WPA2 Enterprise AES

    Wally



  • 4.  RE: iPad constant deauth on 1 AP

    EMPLOYEE
    Posted Feb 17, 2014 07:24 AM

    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/



  • 5.  RE: iPad constant deauth on 1 AP

    Posted Feb 17, 2014 07:45 AM
    Will do..but will be tomorrow some time..will post when i get the results..


  • 6.  RE: iPad constant deauth on 1 AP

    Posted Oct 15, 2015 01:17 AM

    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 

     

     



  • 7.  RE: iPad constant deauth on 1 AP

    EMPLOYEE
    Posted Oct 15, 2015 04:43 AM
    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?


  • 8.  RE: iPad constant deauth on 1 AP

    Posted Oct 15, 2015 04:50 AM

    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.  



  • 9.  RE: iPad constant deauth on 1 AP

    EMPLOYEE
    Posted Oct 15, 2015 04:55 AM

    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.



  • 10.  RE: iPad constant deauth on 1 AP

    Posted Oct 15, 2015 06:49 AM

    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

     

     



  • 11.  RE: iPad constant deauth on 1 AP

    EMPLOYEE
    Posted Oct 15, 2015 06:52 AM

    Your max TX EIRP should be 18 and your min should be 12.  Anything higher than that could contribute to a sticky client issue.  Allowed bands for 40 mhz channels should be done if you have a high density environment to provide more channel reuse.  Try that and see if you still have the same issue.



  • 12.  RE: iPad constant deauth on 1 AP

    Posted Oct 15, 2015 07:08 AM

    Thank you . Let me try this and give you the result on sunday 

     

    Regards

    Khalid Shaikh 



  • 13.  RE: iPad constant deauth on 1 AP

    Posted Oct 25, 2015 08:23 AM

    Hi 

     

    I tried the above mentioned recommendation . Below is the output of show ap active 

     

    B1-1st-4              BLDG_1_ClearPass  192.168.104.54  3            AP:HT:11/12/20       5            AP:HT:48-/12/23      105      2da    19d:3h:4m:31s    N/A
B1-1st-2              BLDG_1_ClearPass  192.168.104.58  1            AP:HT:11/12/20       1            AP:HT:48-/18/23      105      2ad    19d:3h:4m:57s    N/A
B1-1st-1              BLDG_1_ClearPass  192.168.104.60  1            AP:HT:11/12/20       6            AP:HT:44+/18/23      105      2da    6d:5h:1m:54s     N/A
B1-1st-5              BLDG_1_ClearPass  192.168.104.72   0                                 1            AP:HT:56/18/23       105      2a     19d:3h:5m:5s     N/A
B1-GF-2               BLDG_1_ClearPass  192.168.104.83   0            AP:HT:11/12/20       2            AP:HT:44+/18/23      105      2ad    19d:3h:4m:36s    N/A
B1-1st-3              BLDG_1_ClearPass  192.168.104.90   1            AP:HT:1/12/20        7            AP:HT:40-/18/23      105      2ad    19d:3h:5m:12s    N/A
B1-GF-1               BLDG_1_ClearPass  192.168.104.91   1            AP:HT:1/12/20        1            AP:HT:40-/18/23      105      2ad    19d:3h:5m:29s    N/A

     

    But I am still facing the issue of disconnection . Below is the latest disconnection output faced . 

     

     

     

    Oct 25 15:14:11  authmgr[2293]: <522036> <INFO> |authmgr|  MAC=c0:ee:fb:21:8c:4b Station DN: BSSID=d8:c7:c8:a3:e5:9a ESSID=KACST_Emp VLAN=222 AP-name=B1-1st-1
Oct 25 15:14:11  authmgr[2293]: <522234> <DBUG> |authmgr|  Setting idle timer for user c0:ee:fb:21:8c:4b to 300 seconds (idle timeout: 300 ageout: 0).
Oct 25 15:14:11  stm[800]: <501000> <DBUG> |AP B1-1st-1@192.168.104.60 stm|  Station c0:ee:fb:21:8c:4b: Clearing state
Oct 25 15:14:11  stm[800]: <501105> <NOTI> |AP B1-1st-1@192.168.104.60 stm|  Deauth from sta: c0:ee:fb:21:8c:4b: AP 192.168.104.60-d8:c7:c8:a3:e5:9a-B1-1st-1 Reason Unspecified Failure
Oct 25 15:14:16  authmgr[2293]: <522008> <NOTI> |authmgr|  User Authentication Successful: username=kshaikh MAC=c0:ee:fb:21:8c:4b IP=192.168.48.103 role=Domain VLAN=222 AP=B1-1st-1 SSID=KACST_Emp AAA profile=ClearPass_AAA auth method=802.1x auth server=ClearPass
Oct 25 15:14:16  authmgr[2293]: <522029> <INFO> |authmgr|  MAC=c0:ee:fb:21:8c:4b Station authenticate: method=802.1x, role=Domain/Domain//Limited_Access, VLAN=222/222, Derivation=7/1, Value Pair=0
Oct 25 15:14:16  authmgr[2293]: <522035> <INFO> |authmgr|  MAC=c0:ee:fb:21:8c:4b Station UP: BSSID=d8:c7:c8:a3:e5:92 ESSID=KACST_Emp VLAN=222 AP-name=B1-1st-1
Oct 25 15:14:16  authmgr[2293]: <522044> <INFO> |authmgr|  MAC=c0:ee:fb:21:8c:4b Station authenticate(start): method=802.1x, role=Domain/Domain//Limited_Access, VLAN=222/222, Derivation=7/1, Value Pair=0, flags=0x8
Oct 25 15:14:16  authmgr[2293]: <522049> <INFO> |authmgr|  MAC=c0:ee:fb:21:8c:4b,IP=N/A User role updated, existing Role=Domain/Domain, new Role=Domain/Domain, reason=Station Authenticated with auth type: 4
Oct 25 15:14:16  authmgr[2293]: <522050> <INFO> |authmgr|  MAC=c0:ee:fb:21:8c:4b,IP=N/A User data downloaded to datapath, new Role=Domain/112, bw Contract=0/0, reason=Download driven by user role setting, idle-timeout=300
Oct 25 15:14:16  authmgr[2293]: <522077> <DBUG> |authmgr|  MAC=c0:ee:fb:21:8c:4b ingress 0x0x10667 (tunnel 1639), u_encr 64, m_encr 64, slotport 0x0x2100 , type: local, FW mode: 0, AP IP: 0.0.0.0 mdie 0 ft_complete 0
Oct 25 15:14:16  authmgr[2293]: <522078> <DBUG> |authmgr|  MAC=c0:ee:fb:21:8c:4b, wired: 0, vlan:222 ingress:0x0x10667 (tunnel 1639), ingress:0x0x10667 new_aaa_prof: ClearPass_AAA, stored profile: ClearPass_AAA stored wired: 0 stored essid: KACST_Emp, stored-ingress: 0x0x1038f
Oct 25 15:14:16  authmgr[2293]: <522243> <DBUG> |authmgr|  MAC=c0:ee:fb:21:8c:4b Station Updated Update MMS: BSSID=d8:c7:c8:a3:e5:92 ESSID=KACST_Emp VLAN=222 AP-name=B1-1st-1
Oct 25 15:14:16  authmgr[2293]: <522246> <DBUG> |authmgr|  Idle timeout should be driven by STM for MAC c0:ee:fb:21:8c:4b.
Oct 25 15:14:16  authmgr[2293]: <522247> <DBUG> |authmgr|  User idle timer removed for user with  MAC c0:ee:fb:21:8c:4b.
Oct 25 15:14:16  authmgr[2293]: <522254> <DBUG> |authmgr|  VDR - mac c0:ee:fb:21:8c:4b rolename Domain fwdmode 0 derivation_type Dot1x Aruba VSA Role Contained vp not present.
Oct 25 15:14:16  authmgr[2293]: <522254> <DBUG> |authmgr|  VDR - mac c0:ee:fb:21:8c:4b rolename Limited_Access fwdmode 0 derivation_type Initial Role Contained vp not present.
Oct 25 15:14:16  authmgr[2293]: <522254> <DBUG> |authmgr|  VDR - mac c0:ee:fb:21:8c:4b rolename NULL fwdmode 0 derivation_type Matched User Rule vp present.
Oct 25 15:14:16  authmgr[2293]: <522254> <DBUG> |authmgr|  VDR - mac c0:ee:fb:21:8c:4b rolename NULL fwdmode 0 derivation_type VLAN from pmk-cache vp not present.
Oct 25 15:14:16  authmgr[2293]: <522255> <DBUG> |authmgr|  "VDR - set vlan in user for c0:ee:fb:21:8c:4b vlan 222 fwdmode 0 derivation_type Current VLAN updated.
Oct 25 15:14:16  authmgr[2293]: <522255> <DBUG> |authmgr|  "VDR - set vlan in user for c0:ee:fb:21:8c:4b vlan 222 fwdmode 0 derivation_type Current VLAN updated.
Oct 25 15:14:16  authmgr[2293]: <522255> <DBUG> |authmgr|  "VDR - set vlan in user for c0:ee:fb:21:8c:4b vlan 222 fwdmode 0 derivation_type Default VLAN.
Oct 25 15:14:16  authmgr[2293]: <522258> <DBUG> |authmgr|  "VDR - Add to history of user user c0:ee:fb:21:8c:4b vlan 0 derivation_type Reset Role Based VLANs index 1.
Oct 25 15:14:16  authmgr[2293]: <522258> <DBUG> |authmgr|  "VDR - Add to history of user user c0:ee:fb:21:8c:4b vlan 0 derivation_type Reset Role Based VLANs index 2.
Oct 25 15:14:16  authmgr[2293]: <522258> <DBUG> |authmgr|  "VDR - Add to history of user user c0:ee:fb:21:8c:4b vlan 0 derivation_type Reset VLANs for Station up index 30.
Oct 25 15:14:16  authmgr[2293]: <522258> <DBUG> |authmgr|  "VDR - Add to history of user user c0:ee:fb:21:8c:4b vlan 222 derivation_type Current VLAN updated index 0.
Oct 25 15:14:16  authmgr[2293]: <522258> <DBUG> |authmgr|  "VDR - Add to history of user user c0:ee:fb:21:8c:4b vlan 222 derivation_type Current VLAN updated index 3.
Oct 25 15:14:16  authmgr[2293]: <522258> <DBUG> |authmgr|  "VDR - Add to history of user user c0:ee:fb:21:8c:4b vlan 222 derivation_type Default VLAN index 31.
Oct 25 15:14:16  authmgr[2293]: <522259> <DBUG> |authmgr|  "VDR - Do Role Based VLAN Derivation user c0:ee:fb:21:8c:4b role Domain authtype 4 rolehow Aruba VSA.
Oct 25 15:14:16  authmgr[2293]: <522260> <DBUG> |authmgr|  "VDR - Cur VLAN updated c0:ee:fb:21:8c:4b mob 0 inform 1 remote 0 wired 0 defvlan 222 exportedvlan 0 curvlan 222.
Oct 25 15:14:16  authmgr[2293]: <524124> <DBUG> |authmgr|  dot1x_supplicant_up(): MAC:c0:ee:fb:21:8c:4b, pmkid_present:True, pmkid:3d c6 4e 07 08 84 6e b8 86 23 d4 d0 9b 47 19 99
Oct 25 15:14:16  stm[2014]: <501095> <NOTI> |stm|  Assoc request @ 15:14:16.925948: c0:ee:fb:21:8c:4b (SN 55): AP 192.168.104.60-d8:c7:c8:a3:e5:92-B1-1st-1
Oct 25 15:14:16  stm[2014]: <501100> <NOTI> |stm|  Assoc success @ 15:14:16.926940: c0:ee:fb:21:8c:4b: AP 192.168.104.60-d8:c7:c8:a3:e5:92-B1-1st-1
Oct 25 15:14:16  stm[800]: <501093> <NOTI> |AP B1-1st-1@192.168.104.60 stm|  Auth success: c0:ee:fb:21:8c:4b: AP 192.168.104.60-d8:c7:c8:a3:e5:92-B1-1st-1
Oct 25 15:14:16  stm[800]: <501095> <NOTI> |AP B1-1st-1@192.168.104.60 stm|  Assoc request @ 15:14:16.499583: c0:ee:fb:21:8c:4b (SN 55): AP 192.168.104.60-d8:c7:c8:a3:e5:92-B1-1st-1
Oct 25 15:14:16  stm[800]: <501100> <NOTI> |AP B1-1st-1@192.168.104.60 stm|  Assoc success @ 15:14:16.500932: c0:ee:fb:21:8c:4b: AP 192.168.104.60-d8:c7:c8:a3:e5:92-B1-1st-1
Oct 25 15:14:16  stm[800]: <501109> <NOTI> |AP B1-1st-1@192.168.104.60 stm|  Auth request: c0:ee:fb:21:8c:4b: AP 192.168.104.60-d8:c7:c8:a3:e5:92-B1-1st-1 auth_alg 0
Oct 25 15:14:20  mdns[2093]: <527000> <DBUG> |mdns|  mdns_parse_auth_userrole_message 289 Auth User ROLE: MAC:c0:ee:fb:21:8c:4b, NAME:kshaikh, ROLE_NAME:Domain
Oct 25 15:14:35  mdns[2093]: <527000> <DBUG> |mdns|  mdns_parse_packet 2189 mdns query packet received - info; mac=c0:ee:fb:21:8c:4b, ip=192.168.48.103, origin=1
Oct 25 15:14:35  mdns[2093]: <527000> <DBUG> |mdns|  mdns_parse_packet_from_sos 423 pkt from SOS: vlan 222, mac c0:ee:fb:21:8c:4b ip 192.168.48.103
Oct 25 15:14:35  mdns[2093]: <527000> <DBUG> |mdns|  mdns_parse_query_packet 1833 There was no response to query from mac:c0:ee:fb:21:8c:4b, ip: 192.168.48.103
Oct 25 15:14:46  authmgr[2293]: <522036> <INFO> |authmgr|  MAC=c0:ee:fb:21:8c:4b Station DN: BSSID=d8:c7:c8:a3:e5:92 ESSID=KACST_Emp VLAN=222 AP-name=B1-1st-1
Oct 25 15:14:46  authmgr[2293]: <522234> <DBUG> |authmgr|  Setting idle timer for user c0:ee:fb:21:8c:4b to 300 seconds (idle timeout: 300 ageout: 0).
Oct 25 15:14:46  stm[2014]: <501000> <DBUG> |stm|  Station c0:ee:fb:21:8c:4b: Clearing state
Oct 25 15:14:46  stm[2014]: <501105> <NOTI> |stm|  Deauth from sta: c0:ee:fb:21:8c:4b: AP 192.168.104.60-d8:c7:c8:a3:e5:92-B1-1st-1 Reason Client Match
Oct 25 15:14:46  stm[800]: <501000> <DBUG> |AP B1-1st-1@192.168.104.60 stm|  Station c0:ee:fb:21:8c:4b: Clearing state
Oct 25 15:14:46  stm[800]: <501080> <NOTI> |AP B1-1st-1@192.168.104.60 stm|  Deauth to sta: c0:ee:fb:21:8c:4b: Ageout AP 192.168.104.60-d8:c7:c8:a3:e5:92-B1-1st-1 Client Match


  • 14.  RE: iPad constant deauth on 1 AP

    EMPLOYEE
    Posted Oct 25, 2015 08:29 AM

    You should open a TAC case in parallel so that they can obtain detailed information about your case and attempt to push this forward.  There is a limit to what personal information we can ask you here and that will keep us from making a real determination.

     

    You mentioned that the version of code is 6.3.0.x  You are missing the last digit.  What is the output of "show version"?

     



  • 15.  RE: iPad constant deauth on 1 AP

    Posted Oct 25, 2015 08:32 AM

    Hi 

     

    The version is 6.3.1.13 

     

    Thanks I will open case with TAC 

     

     

     



  • 16.  RE: iPad constant deauth on 1 AP

    Posted Nov 18, 2015 01:09 AM

    I dont think this is a problem of Aruba contorller

    This is more an issue with the apple IOS9

     

    Check if the apple devices does have IOS 9?

    There are multiple treads of users having issues with IOS 9 with random disconnects, and this happened after the upgraded to IOS 9.

     

    Im facing the same issue and for what i see this didnt happen before and now all of the sudden its happening... and yes it was after the users did the upgrade to ios 9.

     

    Cheers

    Carlos