[NEBULA] Deauth by STA Timeout reason 2

DerLord

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

DerLord

Hello again,

after a lot of chatting with @Nebula_Dean who provided absolutely outstanding support (this man deserves a raise!) we came to following conclusions:

1. The state machine of the Galaxy S6 Edge's NIC (@Nebula_Dean got one himself just for double checking) is kinda bugged and doesn't provide acceptable fallbacks in error cases.
2. The Galaxy S6 Edge doesn't really support advanced features like 802.11k/v/r, but attempts to use them anyways (with horrible outcomes).

So @WaYne was indeed right about the 802.11k/v/r. Maybe the error persisted because I had a few problem on my network's side anyways.
After disabling 802.11k/v and 802.11r and rebooting the AP, the error hasn't shown up again.

I wanted to test if either 802.11k/v or 802.11r is producing the error, but "sadly" the phone died yesterday.
The client is now using an One Plus 6 and hasn't faced any issues since then.

Thanks to all of you for your help (again, especially @Nebula_Dean who clearly had a lot of more important work to do, but still provided every imaginable support)!

If someone faces an issue like this again, disable 802.11k/v/r like @WaYne suggested and everything should work out as expected.

Best wishes and thanks again,
Niklas

DerLord

@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.

Carlos4311

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

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

Markus_H

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

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

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

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

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

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

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

@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.