[NEBULA] Deauth by STA Timeout reason 2

DerLord
DerLord Posts: 18  Freshman Member
First Anniversary 10 Comments Friend Collector First Answer
edited April 2021 in Nebula
Hello,

some clients on my WLAN Network are randomly disconnecting themselves with the following message:

Station: [MAC] has deauth by STA Timeout on
Channel: 44, SSID: [SSID], 5GHz, Tx/Rx: 16160688/1367848 Bytes.
reason 2, Interface:wlan-2-1

One of them has to restart the WLAN-Adapter to be able to reconnect again (Samsung Galaxy S6 Edge).
I sadly can't find the reason for this kind of behaviour. The device is completely static when this error occures.

- IEEE 802.11k/v/r are enabled
- U-APSD, Walled garden, Layer 2 isolation and Intra-BSS traffic blocking are disabled
- The SSID is visible
- The band is set to concurrent with activated Band select
- Load balancing is disabled
- Smart steering is enabled with a signal threshold of -65dBm and a disassoc threshold of -90dBm
- The retries are set to 2

There are 2 NWA1123-ACv2 APs on my site, all managed over Nebula.

Is there something I can do to prevent this issue from happening?

Thanks in Advance,
Niklas

Best Answers

  • DerLord
    DerLord Posts: 18  Freshman Member
    First Anniversary 10 Comments Friend Collector First Answer
    edited December 2022 Answer ✓
    @stoph3d What we did back then was creating a separate 5 GHz SSID which had k/v/r disabled. We then used this SSID only for this specific device. This at least enabled us to let all the other devices roam and get the erroring device to work as it should.

    I sadly can't tell anything about updates to APs or Nebula, and as this thread is officially resolved, I'm not sure if any of the Zyxel employees will jump in again to shed light on this matter.
«1

All Replies

  • Carlos4311
    Carlos4311 Posts: 11  Freshman Member
    First Anniversary First Comment
    were the stations (clients) idle before you see the log?
    I noticed from my macbook , sometimes I have it lid closed for some moments and the AP tells the same thing.
    the reason code also says something about "Previous authentication no longer valid"
    https://community.cisco.com/t5/wireless-mobility-documents/802-11-association-status-802-11-deauth-reason-codes/ta-p/3148055

    maybe its security reasons something like idle timout?
  • DerLord
    DerLord Posts: 18  Freshman Member
    First Anniversary 10 Comments Friend Collector First Answer
    edited October 2018
    Carlos4311 said:
    were the stations (clients) idle before you see the log?
    I noticed from my macbook , sometimes I have it lid closed for some moments and the AP tells the same thing.
    the reason code also says something about "Previous authentication no longer valid"
    https://community.cisco.com/t5/wireless-mobility-documents/802-11-association-status-802-11-deauth-reason-codes/ta-p/3148055

    maybe its security reasons something like idle timout?
    Hey there,

    thanks for your answer.
    The client is (almost always) streaming HD Videos which makes it the most active client in my whole Network (Around 3 GB downstream per day), so I guess idle isn't an option here.

    I can't find a matching option in Nebula for configuring timeouts or other security reasons matching this case. Could you tell me where to find an option for configuring this in Nebula?

    Best wishes,
    Niklas
  • I can see the same behaviour for some of my clients and this happens only since the last firmware update. I think there are some issues in the latest firmware, this is one of them ...
  • FMAlchmst
    FMAlchmst Posts: 17  Freshman Member
    First Anniversary Friend Collector First Comment Ideas master
    edited October 2018
    You could actually verify what carlos is mentioning by entering the client page and select those clients which you are seeing the logs to check if the client had any traffic around that time.
    Seems it would only take a simple srceen off or a coffee break to meet this log.

    BTW I couldn't find any timeout config either, seems its not as complete as an NXC. 
  • DerLord
    DerLord Posts: 18  Freshman Member
    First Anniversary 10 Comments Friend Collector First Answer
    FMAlchmst said:
    You could actually verify what carlos is mentioning by entering the client page and select those clients which you are seeing the logs to check if the client had any traffic around that time.
    Seems it would only take a simple srceen off or a coffee break to meet this log.

    BTW I couldn't find any timeout config either, seems its not as complete as an NXC. 
    Hello FMAIchmst,

    I did as you said and checked the logs and looked up if the client had traffic in that specified time.
    A strange thing here is that the client's is not loosing connection while it is idle. In fact, idling 10 hours (over night for example) doesn't break the connection even once.
    The connection only breaks when the client has a high network activity.
    I tested this with streaming HD Videos. At some point the connection simply breaks off (reason 2 again). A simple reconnection isn't possible. The Wi-Fi Adapter has to be restarted manually.

    Best wishes,
    Niklas
  • FMAlchmst
    FMAlchmst Posts: 17  Freshman Member
    First Anniversary Friend Collector First Comment Ideas master
    Hey DerLord,
    I may as well try this too, I have a client of mine telling similar things but sadly it's difficult for me to gather enough info as common folks only speak of  "wifi disconnect" "no internet"  and "I don't know" .... (sigh) 
    What App were you using for streaming? I don't have a Samsung phone at hand, what else do you recommend for testing this?


  • DerLord
    DerLord Posts: 18  Freshman Member
    First Anniversary 10 Comments Friend Collector First Answer
    FMAlchmst said:
    Hey DerLord,
    I may as well try this too, I have a client of mine telling similar things but sadly it's difficult for me to gather enough info as common folks only speak of  "wifi disconnect" "no internet"  and "I don't know" .... (sigh) 
    What App were you using for streaming? I don't have a Samsung phone at hand, what else do you recommend for testing this?


    Hey there,

    I'm testing this with "YouTube" and "Netflix". I just look up the logs from the time the clients get disconnected and it's always the same reason code (2).
    I sadly can't recommend any devices for testing for this issue. I only have a notebook available for testing, but the issue never happens there.
  • WaYne
    WaYne Posts: 12  Freshman Member
    First Anniversary Friend Collector First Answer First Comment
    Guys, would it be better if simply turned off IEEE802.11kvr? I had bad experiences with those settings before switching to nebula, never tried it on NAPs but still never wanted to turn them on. 
    One thing you could do is, turn off one setting at a time, then you'll know which ones causing the pain.
  • DerLord
    DerLord Posts: 18  Freshman Member
    First Anniversary 10 Comments Friend Collector First Answer
    edited October 2018
    WaYne said:
    Guys, would it be better if simply turned off IEEE802.11kvr? I had bad experiences with those settings before switching to nebula, never tried it on NAPs but still never wanted to turn them on. 
    One thing you could do is, turn off one setting at a time, then you'll know which ones causing the pain.
    Sadly I already checked this for my situation.
    Turning off k/v/r (sometimes) results in a short disconnect while roaming around. The issue still persists, even with all 3 turned off.
  • Zyxel_Dean
    Zyxel_Dean Posts: 237  Zyxel Employee
    First Anniversary Friend Collector First Answer First Comment
    @DerLord

    The log is almost same as what @Carlos4311 said, if a station idle for too long, then the AP will de-associate the client.

    Is it possible to provide a snippet of the eventlogs while this happened? I will need to check unfiltered logs before and after the event 2 hours. Also I'll need sometime to try reproduce this locally, especially finding a S6 edge.

    Another thing, did other androids or iOS device have the disconnection? and were they able to retry connecting or jump to another SSID?
    When the station needs wifi on/off to recover, this is likely to be an NIC issue on the device, normally it should skip to another SSID if disconnection happens or internet loss. 


Nebula Tips & Tricks