Bug? Asus RT-AC86U running 386.2.6 - Total loss of 2.4 GHz Wi-Fi after some days

[Morris]

Just for the record, ac86u wifi 2.4GHz lost signal out of blue.
This problem has been existed for a few years and is still happening on latest firmware 386.7.

When this bug got triggered, you would be disconnected for a moment on both 5GHz and 2.4GHz. Of course 2.4GHz has never been able to restore itself back. You have to run this to get 2.4GHz back.

service restart_wireless

I have confirmed, ac86u was not rebooting itself, because I have tmux sessions running on SSH, I can reattach to those sessions after wifi 2.4GHz getting lost, and my both rpi4bs running on NFS is still functioning.

I have isolated the log when this bug happened.

This was when I realized my wifi dropped out and tried to connect to router through ssh to check out what was going on.


This was me trying to reset wifi by service restart_wireless

```
Jul 26 00:25:04 rc_service: amas_lanctrl 1495:notify_rc start_cfgsync
Jul 26 00:25:05 BHC: Topology change from 1 to -1.
...
Jul 26 00:25:06 wlceventd: wlceventd_proc_event(491): wl1.1: Deauth_ind F0:xx:xx:xx:C6:3B, status: 0, reason: Deauthenticated because sending station is leaving (or has left) IBSS or ESS (3), rssi:0
Jul 26 00:25:06 wlceventd: wlceventd_proc_event(491): wl1.1: Deauth_ind 00:xx:xx:xx:00:00, status: 0, reason: Deauthenticated because sending station is leaving (or has left) IBSS or ESS (3), rssi:0
Jul 26 00:25:08 kernel: device eth0 left promiscuous mode
Jul 26 00:25:08 kernel: br0: port 7(eth0) entered disabled state
Jul 26 00:25:09 kernel: device dpsta entered promiscuous mode
Jul 26 00:25:09 kernel: br0: port 7(dpsta) entered forwarding state
Jul 26 00:25:09 kernel: br0: port 7(dpsta) entered forwarding state
Jul 26 00:25:09 BHC: IN_BR eth0,R0
Jul 26 00:25:09 BHC: Topology change from -1 to 1.
Jul 26 00:25:10 lldpd[1114]: MSAP has changed for port dpsta, sending a shutdown LLDPDU
Jul 26 00:25:11 kernel: device dpsta left promiscuous mode
Jul 26 00:25:11 kernel: br0: port 7(dpsta) entered disabled state
Jul 26 00:25:11 kernel: device eth0 entered promiscuous mode
Jul 26 00:25:11 kernel: br0: port 7(eth0) entered forwarding state
Jul 26 00:25:11 kernel: br0: port 7(eth0) entered forwarding state
Jul 26 00:25:11 lldpd[1114]: MSAP has changed for port dpsta, sending a shutdown LLDPDU
Jul 26 00:25:11 BHC: IN_BR eth6,R0 eth5,R0
Jul 26 00:25:11 BHC: IN_BR eth0,R2
Jul 26 00:25:16 rc_service: amas_lanctrl 1495:notify_rc restart_acsd
Jul 26 00:25:16 rc_service: watchdog 1486:notify_rc start_cfgsync
Jul 26 00:25:16 rc_service: waitting "restart_acsd" via amas_lanctrl ...
Jul 26 00:25:17 acsd: selected channel spec: 0x1001 (1)
Jul 26 00:25:17 acsd: Adjusted channel spec: 0x1001 (1)
Jul 26 00:25:17 acsd: selected channel spec: 0x1001 (1)
Jul 26 00:25:17 acsd: acs_set_chspec: 0x1001 (1) for reason APCS_INIT
Jul 26 00:25:22 acsd: selected channel spec: 0xe27a (124/80)
Jul 26 00:25:22 acsd: Adjusted channel spec: 0xe27a (124/80)
Jul 26 00:25:22 acsd: selected channel spec: 0xe27a (124/80)
Jul 26 00:25:22 acsd: acs_set_chspec: 0xe27a (124/80) for reason APCS_INIT
Jul 26 00:25:52 rc_service: watchdog 1486:notify_rc start_cfgsync
...
Jul 26 00:40:10 BHC: Disconnected from CAP.
Jul 26 00:40:19 acsd: selected channel spec: 0x1004 (4)
Jul 26 00:40:19 acsd: Adjusted channel spec: 0x1004 (4)
Jul 26 00:40:19 acsd: selected channel spec: 0x1004 (4)
Jul 26 00:40:19 acsd: acs_set_chspec: 0x1004 (4) for reason APCS_CSTIMER
Jul 26 00:40:22 rc_service: watchdog 1486:notify_rc start_cfgsync
Jul 26 00:40:52 rc_service: watchdog 1486:notify_rc start_cfgsync
Jul 26 00:41:22 rc_service: watchdog 1486:notify_rc start_cfgsync
Jul 26 00:41:52 rc_service: watchdog 1486:notify_rc start_cfgsync
Jul 26 00:42:22 rc_service: watchdog 1486:notify_rc start_cfgsync
Jul 26 00:42:52 rc_service: watchdog 1486:notify_rc start_cfgsync
Jul 26 00:43:22 rc_service: watchdog 1486:notify_rc start_cfgsync
Jul 26 00:43:51 dropbear[5858]: Exit (router) from <192.168.9.58:60337>: Error reading: Connection timed out
Jul 26 00:43:52 rc_service: watchdog 1486:notify_rc start_cfgsync
Jul 26 00:44:22 rc_service: watchdog 1486:notify_rc start_cfgsync
Jul 26 00:44:52 rc_service: watchdog 1486:notify_rc start_cfgsync
Jul 26 00:45:10 BHC: Disconnected from CAP.
Jul 26 00:45:22 rc_service: watchdog 1486:notify_rc start_cfgsync
...
Jul 26 01:19:35 dropbear[31893]: Child connection from 192.168.9.58:59111
Jul 26 01:19:35 dropbear[31893]: Pubkey auth succeeded for 'router' with ssh-rsa key SHA256:w2aKDckiApA3R+q7Qx0TSIGpTgX5xzxacsYQoCpjnak from 192.168.9.58:59111
Jul 26 01:19:52 rc_service: watchdog 1486:notify_rc start_cfgsync
Jul 26 01:20:22 rc_service: watchdog 1486:notify_rc start_cfgsync
Jul 26 01:20:52 rc_service: watchdog 1486:notify_rc start_cfgsync
Jul 26 01:21:22 rc_service: watchdog 1486:notify_rc start_cfgsync
Jul 26 01:21:50 rc_service: service 32101:notify_rc restart_wireless
Jul 26 01:21:52 kernel: device wl0.1 left promiscuous mode
Jul 26 01:21:52 kernel: br0: port 5(wl0.1) entered disabled state
Jul 26 01:21:52 kernel: device wl1.1 left promiscuous mode
Jul 26 01:21:52 kernel: br0: port 6(wl1.1) entered disabled state
Jul 26 01:21:53 kernel: device wl0.1 entered promiscuous mode
Jul 26 01:21:53 kernel: br0: port 5(wl0.1) entered forwarding state
Jul 26 01:21:53 kernel: br0: port 5(wl0.1) entered forwarding state
Jul 26 01:21:53 kernel: device wl1.1 entered promiscuous mode
Jul 26 01:21:53 kernel: br0: port 6(wl1.1) entered forwarding state
Jul 26 01:21:53 kernel: br0: port 6(wl1.1) entered forwarding state
Jul 26 01:21:53 kernel: dpsta enabled, uif_bmap 0x3
Jul 26 01:21:53 rc_service: watchdog 1486:notify_rc start_cfgsync
Jul 26 01:21:53 rc_service: waitting "restart_wireless" via  ...
Jul 26 01:21:53 wlceventd: main(961): wlceventd Start...
Jul 26 01:21:55 kernel: br0: received packet on eth0 with own address as source address
Jul 26 01:21:56 kernel: bcm_mcast_mld_add:833 mc_fdb->rep_list fffxx:xx:xx:cde8 next fffxx:xx:xx:d4a0 prev fffxx:xx:xx:d4a0 rep_entry->list fffxx:xx:xx:d4a0 next fffxx:xx:xx:cde8 prev fffxx:xx:xx:cde8
Jul 26 01:21:57 BHC: WiFi connection status change.
Jul 26 01:21:57 BHC: bandindex(0): state is 0
Jul 26 01:21:57 BHC: bandindex(1): state is 2
Jul 26 01:21:57 BHC: Topology change from -1 to 1.
Jul 26 01:21:57 kernel: device eth0 left promiscuous mode
Jul 26 01:21:57 kernel: br0: port 7(eth0) entered disabled state
Jul 26 01:21:57 BHC: IN_BR eth0,R0 eth6,R0 eth5,R0
Jul 26 01:21:58 wlceventd: wlceventd_proc_event(527): wl1.1: Auth 00:xx:xx:xx:73:4E, status: Successful (0), rssi:0
Jul 26 01:21:58 wlceventd: wlceventd_proc_event(556): wl1.1: Assoc 00:xx:xx:xx:73:4E, status: Successful (0), rssi:0
Jul 26 01:21:58 wlceventd: wlceventd_proc_event(527): wl1.1: Auth F0:xx:xx:xx:C6:3B, status: Successful (0), rssi:0
Jul 26 01:21:58 wlceventd: wlceventd_proc_event(537): wl1.1: ReAssoc F0:xx:xx:xx:C6:3B, status: Successful (0), rssi:0
Jul 26 01:21:58 kernel: br0: received packet on wl1.1 with own address as source address
Jul 26 01:21:59 kernel: device eth0 entered promiscuous mode
Jul 26 01:21:59 kernel: br0: port 7(eth0) entered forwarding state
Jul 26 01:21:59 kernel: br0: port 7(eth0) entered forwarding state
Jul 26 01:21:59 BHC: IN_BR
Jul 26 01:21:59 wlceventd: wlceventd_proc_event(527): wl0.1: Auth 8C:xx:xx:xx:CB:32, status: Successful (0), rssi:0
Jul 26 01:21:59 wlceventd: wlceventd_proc_event(556): wl0.1: Assoc 8C:xx:xx:xx:CB:32, status: Successful (0), rssi:0
Jul 26 01:22:00 wlceventd: wlceventd_proc_event(527): wl0.1: Auth EC:xx:xx:xx:B1:D2, status: Successful (0), rssi:0
Jul 26 01:22:00 wlceventd: wlceventd_proc_event(556): wl0.1: Assoc EC:xx:xx:xx:B1:D2, status: Successful (0), rssi:0
Jul 26 01:22:01 BHC: WiFi connection status change.
Jul 26 01:22:01 BHC: bandindex(0): state is 0
Jul 26 01:22:01 BHC: bandindex(1): state is 0
Jul 26 01:22:01 BHC: IN_BR eth0,R2
```

Why do you believe this is a bug? Can you revert to old firmware and not have the issue? If not, replace the fatly router.

 

[MissingTwins]

Why do you believe this is a bug? Can you revert to old firmware and not have the issue? If not, replace the fatly router.

I have two ac86us and brought from two different counties and different year, 2.4GHz signal losing on both of them. I have swapped different versions of firmware and do all the factory reset, but haven't found available solution. Am I so lucky and got myself two fatally routers?

And they always have 2.4GHz difficulties doesn't mean they always fail from each boot. They were always good for several days to months and you even forgot about they had problems, until one day something triggered this episode. the last time I saw this issue was 1 month ago, and more previous once was half-year ago.

I had several ac68us also there were some version of flawed firmware causing 2.4GHz lost signal but got fixed after 1.5 years if I remembered correctly.

And a bug last for at least three years and just got fixed very recently that was causing WAN got stuck unless you re-powered the router kind of issues on all of the Asus routers.

I brought this ac86u three years ago, 2.4GHz became an issue after a year since I upgraded the firmware, and from then it always had 2.4GHz issues. since I have experienced with asus long existing bugs, so I have hoped it will be fixed years later, and I haven't been using 2.4GHz so much, so that isn't an issue, but lately I replaced the ac86u with ax86u and this ac86u became an IoT AP point, so the 2.4GHz issue matters now.

Asus warranty question

Hi, planning to get the 86U new from ebay as is cheaper. As I have been reading here this model tends to burn up and die, if that happens how does Asus honors warranty ? Do i need proof of purchase or what is needed ? Buyer does not have any paper just the new sealed box with the router. Will...

www.snbforums.com

My ASUS RT-AC86U warranty experience a year or so ago (with full purchase documentation) was miserable. It took a week of frustrating back and forth to convince ASUS that the problem (dead 2.4 Ghz radio) wasn't operator error. Then about a month to send in the unit (at my cost) and finally receive a replacement (not repaired) unit. Buying a new unit would have been cheaper if my client had been paying for my time. Fortunately we had an old 68U unit we had pressed into service. (Do those ever fail!?)

 

[Morris]

Three years from now you will still be waiting. I'm sorry, the fix is replacement. You could get a another AX if you want to be confident

 

[zakdav]

Hi, I've same issue and I've solved changing usb device to a pendrive (256 gb ntfs formatted), but also new generation external ssd (like samsung T7) might be ok (I'm going to make the switch next days).
I've solved so for me is enought , but I think that connecting some old usb drive (the issue was caused by an internal ssd with sata - usb adapter ) might absorb too much power that cause a general shortage of power and related 2.4 ghz issues.

 

[explorer200]

The solution is to install beefier fans on the AC86U before the thermals kill the board.

They overheat.

 

[zakdav]

The solution is to install beefier fans on the AC86U before the thermals kill the board.

They overheat.

wasn't my issue, I've very few devices connected, cpu is not more than 2% but thanks for information.

 

[explorer200]

wasn't my issue, I've very few devices connected, cpu is not more than 2% but thanks for information.

What's your internal temp?

[ISSUE][RT-AC86U][384.4_2] CPU temp too hot?

Just got my new AC86U and unfortunately I find these in the logs especially during CPU intensive task like transferring files to/from its USB3.0 share May 5 12:43:51 kernel: thermal cooling_device1: turn off CPU#1 May 5 12:43:51 kernel: IRQ6 no longer affine to CPU1 May 5 12:43:51 kernel...

www.snbforums.com

 

[zakdav]

What's your internal temp?

[ISSUE][RT-AC86U][384.4_2] CPU temp too hot?

Just got my new AC86U and unfortunately I find these in the logs especially during CPU intensive task like transferring files to/from its USB3.0 share May 5 12:43:51 kernel: thermal cooling_device1: turn off CPU#1 May 5 12:43:51 kernel: IRQ6 no longer affine to CPU1 May 5 12:43:51 kernel...

www.snbforums.com

I've not checked the internal temp, but Issue happens immediatly after I've connected external drive, without any file transfer operation, and immedialely disappears when I remove the device, and reboot. I've also tested heavy file tranfer with my new usb pendrive device, and no more issues on 2.4 ghz. For this reason my case might not seems related to thermal issues but is more suitable with power issue.
[EDIT]
checked now with 1T samsung T7 ssd (NTFS formatted) and all works fine

 

[drinkingbird]

If you are experiencing issues with your 2.4Ghz & 5Ghz networks.

Step 1: Hard Reset the router (Hold the reset button on the back of the device for 5 seconds) and do not import a config.
Step 2: During the initial setup do not use capitals or special characters in the SSID or password fields for your 2.4 & 5Ghz networks, use only lowercase and numbers.
Step 3: Use whatever you would normally for your admin login and password.
Step 4: Connect devices on your 2.4Ghz/5Ghz networks.

Reasoning: I suspect because this router is running Linux (A case sensitive OS), some internal part of this router wasn't programmed to handle capitals and special characters from the SSID and Password fields correctly.

You're digging up old threads and posting inaccurate info. See my other reply.

 

[Ripshod]

You're digging up old threads and posting inaccurate info. See my other reply.

It's just a generic response copy/pasted with no real thought.
Has been used in another thread.
Here:
Post in thread 'RT-AC86U 2.4GHz problems' https://www.snbforums.com/threads/rt-ac86u-2-4ghz-problems.58113/post-865670