ASUS RT-AC88U Firmware version 3.0.0.4.384.81116

[Tomatosoup]

Hello, I signed up here because I was pointed to this thread via https://superuser.com/questions/1517940/is-this-likely-to-be-a-wi-fi-deauthentication-attack

That question I posted there because I thought it could be a WiFi attack. Maybe it's not that likely? ;-)

So well, I might have similar problems (or log messages) for second 5 GHz (the 'backhaul') but on RT-AX92U running most recent firmware (3.0.0.4.384_6437 at the moment). Though my connection issues on second 5 GHz are resolved by enabling instead of disabling the MAC filter, setting it to Accept and allow only whitelisted devices... 2,4 GHz and first 5 GHz (ac-mode). So that seems like the opposite thing actually?

I've got the same problem after a factory reset of the router and with several, if not all firmwares I tested (official ASUS firmware). I also tested a lot of other settings or combinations of router settings. Also used the Repeater mode, same thing. Now in AiMesh mode again and well, it's a workaround (enabling the MAC filtering)...

 

[follower]

Hello, I signed up here because I was pointed to this thread via https://superuser.com/questions/1517940/is-this-likely-to-be-a-wi-fi-deauthentication-attack

That question I posted there because I thought it could be a WiFi attack. Maybe it's not that likely? ;-)

So well, I might have similar problems (or log messages) for second 5 GHz (the 'backhaul') but on RT-AX92U running most recent firmware (3.0.0.4.384_6437 at the moment). Though my connection issues on second 5 GHz are resolved by enabling instead of disabling the MAC filter, setting it to Accept and allow only whitelisted devices... 2,4 GHz and first 5 GHz (ac-mode). So that seems like the opposite thing actually?

I've got the same problem after a factory reset of the router and with several, if not all firmwares I tested (official ASUS firmware). I also tested a lot of other settings or combinations of router settings. Also used the Repeater mode, same thing. Now in AiMesh mode again and well, it's a workaround (enabling the MAC filtering)...

The post you linked is normal.

 

[Submit]

Hello, I signed up here because I was pointed to this thread via https://superuser.com/questions/1517940/is-this-likely-to-be-a-wi-fi-deauthentication-attack

That question I posted there because I thought it could be a WiFi attack. Maybe it's not that likely? ;-)

So well, I might have similar problems (or log messages) for second 5 GHz (the 'backhaul') but on RT-AX92U running most recent firmware (3.0.0.4.384_6437 at the moment). Though my connection issues on second 5 GHz are resolved by enabling instead of disabling the MAC filter, setting it to Accept and allow only whitelisted devices... 2,4 GHz and first 5 GHz (ac-mode). So that seems like the opposite thing actually?

I've got the same problem after a factory reset of the router and with several, if not all firmwares I tested (official ASUS firmware). I also tested a lot of other settings or combinations of router settings. Also used the Repeater mode, same thing. Now in AiMesh mode again and well, it's a workaround (enabling the MAC filtering)...

If you want to escape from a long explanation, this is for short: look for a WiFi repeater or range extender in your wireless network and unplug it, then see if there is a change in the system log.

I tried turning off WPS and UPnP services, buying a new ONT (optical network terminal) cable, upgrade and downgrade ASUS firmware, enabling en disabling MAC filter, treated as Wi-Fi deauthentication attack... even light a candle.

In my case a NetGear WN2500RP was causing that mess... if you do not have such devices, maybe this helps you trying something else. I have an ASUS RT-AC3100 with Firmware version 3.0.0.4.384.81116 (19-sept-2019), originally the error log reads as follows:

Jan 20 14:18:39 syslog: WLCEVENTD wlceventd_proc_event(386): eth1: Deauth_ind 04:A1:51:E8:3B:24, status: 0, reason: Class 3 frame received from nonassociated station (7)

First let’s “read” the log:

• Jan 20 14:18:39 syslog: says (time of the event) syslog
• WLCEVENTD: Wireless LAN Controller Event Daemon
• wlceventd_proc_event(386): indicates an error event 386 regarding a synchronization problem that occurs when you use the default database
• eth1: location of the error in the Ethernet interface 1, in this case is the second wireless because wlan0 is the name of the first wireless network interface in the system
• Deauth_ind 04:A1:51:E8:3B:24, status: 0: Deauthenticated indicates (address) status zero
  • 04:A1:51:xx:xx:xx is “format 1” Assigned MAC range to NETGEAR Vendor
• Class 3 frame received from nonassociated station (7): according to 802.11 Deauth Reason Codes definition is “station is leaving (or has left) IBSS or ESS

Putting all together, the error log indicates the time of error in the second wireless local area network regarding a synchronization event caused by the use of a default database, specifically in the second wireless ethernet interface using a NETGEAR assigned MAC address. Also says that this device is been de- authenticated because the station is not associated to station seven or has left it.

Finally, after studied and learned to read the log, and only if you know all the details of your network, it sends you directly to the problem.

 

[Tomatosoup]

If you want to escape from a long explanation, this is for short: look for a WiFi repeater or range extender in your wireless network and unplug it, then see if there is a change in the system log.

I tried turning off WPS and UPnP services, buying a new ONT (optical network terminal) cable, upgrade and downgrade ASUS firmware, enabling en disabling MAC filter, treated as Wi-Fi deauthentication attack... even light a candle.

In my case a NetGear WN2500RP was causing that mess... if you do not have such devices, maybe this helps you trying something else. I have an ASUS RT-AC3100 with Firmware version 3.0.0.4.384.81116 (19-sept-2019), originally the error log reads as follows:

Jan 20 14:18:39 syslog: WLCEVENTD wlceventd_proc_event(386): eth1: Deauth_ind 04:A1:51:E8:3B:24, status: 0, reason: Class 3 frame received from nonassociated station (7)

First let’s “read” the log:

• Jan 20 14:18:39 syslog: says (time of the event) syslog
• WLCEVENTD: Wireless LAN Controller Event Daemon
• wlceventd_proc_event(386): indicates an error event 386 regarding a synchronization problem that occurs when you use the default database
• eth1: location of the error in the Ethernet interface 1, in this case is the second wireless because wlan0 is the name of the first wireless network interface in the system
• Deauth_ind 04:A1:51:E8:3B:24, status: 0: Deauthenticated indicates (address) status zero
  • 04:A1:51:xx:xx:xx is “format 1” Assigned MAC range to NETGEAR Vendor
• Class 3 frame received from nonassociated station (7): according to 802.11 Deauth Reason Codes definition is “station is leaving (or has left) IBSS or ESS

Putting all together, the error log indicates the time of error in the second wireless local area network regarding a synchronization event caused by the use of a default database, specifically in the second wireless ethernet interface using a NETGEAR assigned MAC address. Also says that this device is been de- authenticated because the station is not associated to station seven or has left it.

Finally, after studied and learned to read the log, and only if you know all the details of your network, it sends you directly to the problem.

But in my case it points to multiple client devices, like my desktop PC and my phone, for instance.

I removed the MAC addresses from the list by the way and now I have an empty Reject list (MAC filtering enabled). When I disable my MAC filter I can't ping my NAS for instance. When I have it enabled I can and everything seems fine.

 

[Eric Lieb]

I am getting a ton of these in the log too

WLCEVENTD wlceventd_proc_event(386): eth6: Deauth_ind 68:27:37:5D:8A:00, status: 0, reason: Class 3 frame received from nonassociated station (7)


I cant find anything on my network that matches that mac address tho.

 

[Grisu]

Please search for WLCEVENTD, there are already many threads about this very topic (nothing to screw your head about).

 

[Submit]

I am getting a ton of these in the log too

WLCEVENTD wlceventd_proc_event(386): eth6: Deauth_ind 68:27:37:5D:8A:00, status: 0, reason: Class 3 frame received from nonassociated station (7)


I cant find anything on my network that matches that mac address tho.

Look for a Samsung device... a TV, a cell phone, etc.

 

[Eric Lieb]

Look for a Samsung device... a TV, a cell phone, etc.

Was a smart tv... Not sure why it was the only device throwing these errors every 30 seconds but i removed it from teh network. I also flashed back to 384.14_2 and most of my stability issues are gone now. There is something about 384.15 that is unstable with my setup.