Frequent "deauthenticated due to local deauth request" disconnects

Installing and Using OpenWrt
1

Hi!
I have a strange error resulting in frequent disconnects of a device from an Archer C60 v2.
Here is the log:
Logfile

You can see this repeating every few seconds
hostapd: wlan0: STA c8:3c:85:42:13:37 IEEE 802.11: deauthenticated due to local deauth request
hostapd: wlan0: STA c8:3c:85:42:13:37 IEEE 802.11: authenticated
hostapd: wlan0: STA c8:3c:85:42:13:37 IEEE 802.11: associated (aid 1)

And I do not have any idea what is wrong, whether it is the router, the device or something else (deauth attack?)

Please note, that it is a router from a customer, so I do not have unlimited access to the device to try stuff out.

Cheers
James

2

Does it happen on just this client or with others too? Is the client on some power saving maybe?
Any logs from the radius?
cat /etc/config/wireless ?

1 Like
3
  • What channel is the customer running the AP on?
  • Has changing the channel been tried yet?
  • Can you get the results of a channel scan or survey from a "WiFi Analyzer" app - to see how congested the channel in question may be at the customer's location?

Please note, (in the US) there are only 3 non-overlapping channels on 2.4 GHz:

  • 1
  • 6
  • and 11

So basically, please try seeing if there's better service on another channel. I think that the issue is that the 42:13:37 device has a hidden station problem. See: AR9344 Wireless Issue -

4

It is happening for me too with a C7v2, I think it is a bug in the ath10k driver or some specific issue of Apple clients.

5

(this thread is 3 years old, perhaps you should make a new one)

1 Like
6

Sorry, didn't notice - meanwhile I opened one here

1 Like
7

I wonder why threads this old are still available for posting and not locked.

@tmomas ?

8

It doesn't happen automatically, only if someone marks the thread as solved (or an admin closes it actively). Many threads just fizzle out, without anyone coming back to them and actively closing them (respectively marking them as closed) - and there are too many daily threads to manage revisiting old ones to determine if everything has been covered or not (unless they pop up again by chance, like this one). At the same time an automated expiry can be unfriendly for threads that genuinely are long running (e.g. the active community builds or device exploration threads that may need to remain open for years).

1 Like
9

This should not be a problem if the condition to automatically lock the thread takes into account the last post. For example, we could mark as closed a thread 6 or 12 months after the last answer and will not affect active community builds. Or we could apply this rule on other categories and not in Community Builds.

First post in 2022, happy new year to everyone!

1 Like