What's new

Intermittent loss of Wi-Fi since upgrading to 386.7

  • SNBForums Code of Conduct

    SNBForums is a community for everyone, no matter what their level of experience.

    Please be tolerant and patient of others, especially newcomers. We are all here to share and learn!

    The rules are simple: Be patient, be nice, be helpful or be gone!

Expect a new firmware release soon for AX88U. Asus just released 49599 for AX86U with connection issues fix. Both routers have the same 5GHz SoC. You may have to switch to Asuswrt for more stable Wi-Fi.
 
I have the same issue on my ax88u since 386.7.
wifi disconnects, followed by a log spam (until reboot) with the wlc_send_bar, wlc_ampdu_recv_addba_resp failed and wlc_recvfilter bad frame control and other errors

Moved all my google nest devices to 2.4ghz (I have a different ssid for 2.4 and 5ghz), that did make the frequency of the crashes less often.

Then a few days later reset the "Group Key Rotation Interval" back to the default of 3600 (had it set to 8 hours before since years), and now it is actually happening a lot more than before.
Just set it to '0' for both 2.4 ang 5ghz, lets see if this at least makes it again less frequent. Obviously this has some security concerns.

Let's see, hope a new FW version comes soon
 
Last edited:
After some days with no issue on 386.7_1, the intermittent wifi outages accompanied by massive log spamming have returned.

Reluctantly reverted to 386.5_2. :(
 
Ok, crash again. so Group Key Rotation Interval back to 3600 and going to dirty downgrade to 386.5_2 now :(
 
Last edited:
To follow up from my previous post.

I've had no router reboots and no WAN connection issues.

I posted my devices on 2.4 which has been solid no drops there now here is 5Ghz.

The device starting with the 56: is my Galaxy S10 cell phone which goes on and off the network as I leave the house.

The device starting with 50: is my work laptop which pretty much stays stationary until I'm in office Tue and Wed I work from home the rest of the week.

now that the week has started I will be on the work laptop alot more so will monitor it for connection drops but I haven't noticed anything so far while working in the last 10 days.

View attachment 42448

Here is info from wlceventd.log yesterday and this morning

Code:
Jul  3 02:44:46 RT-AX88U-0B10 wlceventd: wlceventd_proc_event(534): eth7: Assoc 56:A6:DC:1F:79:91, status: Successful (0)
Jul  3 04:12:08 RT-AX88U-0B10 wlceventd: wlceventd_proc_event(469): eth7: Deauth_ind 50:E0:85:DB:5A:6A, status: 0, reason: Unspecified reason (1)
Jul  3 04:12:08 RT-AX88U-0B10 wlceventd: wlceventd_proc_event(505): eth7: Auth 50:E0:85:DB:5A:6A, status: Successful (0)
Jul  3 04:12:08 RT-AX88U-0B10 wlceventd: wlceventd_proc_event(515): eth7: ReAssoc 50:E0:85:DB:5A:6A, status: Successful (0)
Jul  3 04:12:11 RT-AX88U-0B10 wlceventd: wlceventd_proc_event(469): eth7: Deauth_ind 50:E0:85:DB:5A:6A, status: 0, reason: Station requesting (re)association is not authenticated with responding station (9)
Jul  3 04:12:11 RT-AX88U-0B10 wlceventd: wlceventd_proc_event(486): eth7: Disassoc 50:E0:85:DB:5A:6A, status: 0, reason: Disassociated because sending station is leaving (or has left) BSS (8)
Jul  3 04:12:12 RT-AX88U-0B10 wlceventd: wlceventd_proc_event(505): eth7: Auth 50:E0:85:DB:5A:6A, status: Successful (0)
Jul  3 04:12:12 RT-AX88U-0B10 wlceventd: wlceventd_proc_event(515): eth7: ReAssoc 50:E0:85:DB:5A:6A, status: Successful (0)
Jul  3 11:14:23 RT-AX88U-0B10 wlceventd: wlceventd_proc_event(469): eth7: Deauth_ind 56:A6:DC:1F:79:91, status: 0, reason: Deauthenticated because sending station is leaving (or has left) IBSS or ESS (3)
Jul  3 11:14:23 RT-AX88U-0B10 wlceventd: wlceventd_proc_event(469): eth7: Deauth_ind 56:A6:DC:1F:79:91, status: 0, reason: Deauthenticated because sending station is leaving (or has left) IBSS or ESS (3)
Jul  3 11:14:24 RT-AX88U-0B10 wlceventd: wlceventd_proc_event(486): eth7: Disassoc 56:A6:DC:1F:79:91, status: 0, reason: Disassociated because sending station is leaving (or has left) BSS (8)
Jul  3 11:35:37 RT-AX88U-0B10 wlceventd: wlceventd_proc_event(505): eth7: Auth 56:A6:DC:1F:79:91, status: Successful (0)
Jul  3 11:35:37 RT-AX88U-0B10 wlceventd: wlceventd_proc_event(534): eth7: Assoc 56:A6:DC:1F:79:91, status: Successful (0)
Jul  3 14:33:15 RT-AX88U-0B10 wlceventd: wlceventd_proc_event(469): eth7: Deauth_ind 50:E0:85:DB:5A:6A, status: 0, reason: Unspecified reason (1)
Jul  3 14:33:15 RT-AX88U-0B10 wlceventd: wlceventd_proc_event(505): eth7: Auth 50:E0:85:DB:5A:6A, status: Successful (0)
Jul  3 14:33:15 RT-AX88U-0B10 wlceventd: wlceventd_proc_event(469): eth7: Deauth_ind 50:E0:85:DB:5A:6A, status: 0, reason: Deauthenticated because sending station is leaving (or has left) IBSS or ESS (3)
Jul  3 14:33:16 RT-AX88U-0B10 wlceventd: wlceventd_proc_event(469): eth7: Deauth_ind 50:E0:85:DB:5A:6A, status: 0, reason: Previous authentication no longer valid (2)
Jul  3 14:33:16 RT-AX88U-0B10 wlceventd: wlceventd_proc_event(505): eth7: Auth 50:E0:85:DB:5A:6A, status: Successful (0)
Jul  3 14:33:16 RT-AX88U-0B10 wlceventd: wlceventd_proc_event(469): eth7: Deauth_ind 50:E0:85:DB:5A:6A, status: 0, reason: Deauthenticated because sending station is leaving (or has left) IBSS or ESS (3)
Jul  3 14:33:17 RT-AX88U-0B10 wlceventd: wlceventd_proc_event(469): eth7: Deauth_ind 50:E0:85:DB:5A:6A, status: 0, reason: Previous authentication no longer valid (2)
Jul  3 14:33:17 RT-AX88U-0B10 wlceventd: wlceventd_proc_event(505): eth7: Auth 50:E0:85:DB:5A:6A, status: Successful (0)
Jul  3 14:33:17 RT-AX88U-0B10 wlceventd: wlceventd_proc_event(469): eth7: Deauth_ind 50:E0:85:DB:5A:6A, status: 0, reason: Deauthenticated because sending station is leaving (or has left) IBSS or ESS (3)
Jul  3 14:33:18 RT-AX88U-0B10 wlceventd: wlceventd_proc_event(469): eth7: Deauth_ind 50:E0:85:DB:5A:6A, status: 0, reason: Previous authentication no longer valid (2)
Jul  3 14:33:26 RT-AX88U-0B10 wlceventd: wlceventd_proc_event(534): eth7: Assoc 50:E0:85:DB:5A:6A, status: Successful (0)
Jul  3 14:47:08 RT-AX88U-0B10 wlceventd: wlceventd_proc_event(486): eth7: Disassoc 56:A6:DC:1F:79:91, status: 0, reason: Disassociated because sending station is leaving (or has left) BSS (8)
Jul  3 14:47:08 RT-AX88U-0B10 wlceventd: wlceventd_proc_event(486): eth7: Disassoc 56:A6:DC:1F:79:91, status: 0, reason: Disassociated because sending station is leaving (or has left) BSS (8)
Jul  3 14:47:10 RT-AX88U-0B10 wlceventd: wlceventd_proc_event(534): eth7: Assoc 56:A6:DC:1F:79:91, status: Successful (0)
Jul  3 17:30:53 RT-AX88U-0B10 wlceventd: wlceventd_proc_event(469): eth7: Deauth_ind 56:A6:DC:1F:79:91, status: 0, reason: Deauthenticated because sending station is leaving (or has left) IBSS or ESS (3)
Jul  3 17:30:53 RT-AX88U-0B10 wlceventd: wlceventd_proc_event(469): eth7: Deauth_ind 56:A6:DC:1F:79:91, status: 0, reason: Deauthenticated because sending station is leaving (or has left) IBSS or ESS (3)
Jul  3 17:30:54 RT-AX88U-0B10 wlceventd: wlceventd_proc_event(486): eth7: Disassoc 56:A6:DC:1F:79:91, status: 0, reason: Disassociated because sending station is leaving (or has left) BSS (8)
Jul  3 20:15:01 RT-AX88U-0B10 wlceventd: wlceventd_proc_event(534): eth7: Assoc 56:A6:DC:1F:79:91, status: Successful (0)
Jul  4 08:15:02 RT-AX88U-0B10 wlceventd: wlceventd_proc_event(486): eth7: Disassoc 56:A6:DC:1F:79:91, status: 0, reason: Disassociated because sending station is leaving (or has left) BSS (8)
Jul  4 08:15:02 RT-AX88U-0B10 wlceventd: wlceventd_proc_event(486): eth7: Disassoc 56:A6:DC:1F:79:91, status: 0, reason: Disassociated because sending station is leaving (or has left) BSS (8)
Jul  4 08:15:04 RT-AX88U-0B10 wlceventd: wlceventd_proc_event(534): eth7: Assoc 56:A6:DC:1F:79:91, status: Successful (0)
You replied to me here.
But look at the picture you posted in this thread. Channel is 36/80. This means your router's 5G WiFi is also reduced to 80MHz when no 160MHz device is connected. This is what I call the 160MHz bug in 386.7.
In 386.5.2, 5G WiFi can work at 160MHz all the time, if I set 5G bandwidth to 160MHz.
 
Still no problem to report since 21 days with the 386.7 Firmware.
As I said before, I don't activate the 160 Mhz case for the 5 Ghz Wifi.
I leave this default setting on AUTO and so my wifi devices connect in 80 Mhz like on the screenshot of Makaveli.
However, I am very satisfied with the speed, even with several devices connected at the same time.
In any case I am very happy with this firmware which has not given me any problems so far.
For some people who have disconnection problems when activating the 160 Mhz, I think it will be necessary to wait for the 386.7_2 version.
 
Last edited:
You replied to me here.
But look at the picture you posted in this thread. Channel is 36/80. This means your router's 5G WiFi is also reduced to 80MHz when no 160MHz device is connected. This is what I call the 160MHz bug in 386.7.
In 386.5.2, 5G WiFi can work at 160MHz all the time, if I set 5G bandwidth to 160MHz.

no that post you are quoting is days older than the last one.

In that post I didn't have 160Mhz enabled.

In the follow up post I did. I don't normally use 160mhz but I enabled it to test after I saw your post.
 
Last edited:
Still no problem to report since 21 days with the 386.7 Firmware.
As I said before, I don't activate the 160 Mhz case for the 5 Ghz Wifi.
I leave this default setting on AUTO and so my wifi devices connect in 80 Mhz like on the screenshot of Makaveli.
However, I am very satisfied with the speed, even with several devices connected at the same time.
In any case I am very happy with this firmware which has not given me any problems so far.
For some people who have disconnection problems when activating the 160 Mhz, I think it will be necessary to wait for the 386.7_2 version.
I don’t use 160 mhz, but 386.7 (after 3 - 4 days) settled in with intermittent wifi disconnects.
As previously noted, I did a full reset, & reintroduced scripts I was running one at a time.

Go figure…..
 
It is going to be fixed guys. You just need to wait for Asuswrt-Merlin based on newer Asuswrt.
 
The Wizard has to get the newer code base first. With 388 coming, it may not worth the time fixing 386.
 
Seems to me if the vast majority of those having issues w/ 386.7 are NOT having them w/ 386.5_2, then it makes no sense to continue w/ 386.7.

In my experience, far too many ppl upgrade just for the sake of remaining current. Unless the new firmware addresses serious vulnerabilities or bugs that directly affect you, you should STOP chasing upgrades just because they are available. You need to appreciate the value of stable existing firmware before delving into the unknown of new firmware, esp. if its only known benefit is that it's NEW!

As far as I can tell, there's simply no compelling reason to embrace 386.7 that warrants all this trouble. Esp. if 388.x supposedly offers some relief.
 
Seems to me if the vast majority of those having issues w/ 386.7 are NOT having them w/ 386.5_2, then it makes no sense to continue w/ 386.7.

In my experience, far too many ppl upgrade just for the sake of remaining current. Unless the new firmware addresses serious vulnerabilities or bugs that directly affect you, you should STOP chasing upgrades just because they are available. You need to appreciate the value of stable existing firmware before delving into the unknown of new firmware, esp. if its only known benefit is that it's NEW!

As far as I can tell, there's simply no compelling reason to embrace 386.7 that warrants all this trouble. Esp. if 388.x supposedly offers some relief.
You are absolutely right. However, is it possible to keep the 386.7 version for now (which works perfectly for me) and not update the following versions (386.7_1, 386.7_2...) and only flash the 388 version when it will be released ?
This one will completely overwrite the 386.7 ? (provided you do a WPS reset after the 388 update to get the default settings of course)
 
I've also had WiFi issues on my network since upgrading to 386.7 however I am in what I suspect is a lucky position that my main router is an RT-AX88U with 2 x RT-AX86U ethernet backhaul AiMesh nodes which carry most of the traffic. I have upgraded both nodes to stock 3.0.0.4.386_49599, removed and re-added them to reset their configs, and my network is performing very well now. I think my Ring Cameras etc are the best I have ever known.

I know this won't be an option for many, however I wanted to provide some confidence that Asus appear to have a fix in the newer drivers and therefore RMerlin will almost certainly roll out this new code in due course.
 
Still no problem to report since 21 days with the 386.7 Firmware.
As I said before, I don't activate the 160 Mhz case for the 5 Ghz Wifi.
I leave this default setting on AUTO and so my wifi devices connect in 80 Mhz like on the screenshot of Makaveli.
However, I am very satisfied with the speed, even with several devices connected at the same time.
In any case I am very happy with this firmware which has not given me any problems so far.
For some people who have disconnection problems when activating the 160 Mhz, I think it will be necessary to wait for the 386.7_2 version.
I've never used the 160 MHz settings, but I still get the Wi-Fi dropouts, so it's not just limited to use of 160 MHz where the problems are occurring.
 
I've had major issues with my shield TV connecting since the upgrade. When forced to 5GHz it often wouldn't connect for 5 minutes (if at all) after a cold boot. Seemed to be a bit better after allowing it to use 2.4, but still not perfect.
It coincided with an OS update, so could just be a red herring mind you. I've rolled back to 386.5_2 and will have a play with it later to see if there's any improvement.

No issues aside from that, though.

/edit
Yeah, seems fine now after going back to 386.5_2 and forcing the Shield to use 5GHz only again.
 
Last edited:
As far as I can tell, there's simply no compelling reason to embrace 386.7 that warrants all this trouble. Esp. if 388.x supposedly offers some relief.
388 wont come for months, possibly not until next year for existing models.

I received an updated driver/SDK for the RT-AX86U, I haven't had time to test it yet.

As for the RT-AX88U, a new GPL is expected in the coming weeks to add support for a new SoC revision.
 
Same issues here on my GT-AX11000 on 386.7 (dirty flash from 386.5_2). I thought at first it was my piHole but finally realized that the radio itself reboots, doesn't seem to be the whole router. Most of the time it's the 5GHZ-2 which I have set to AX Only with 160 MHz enabled and I use that for my work laptops. I do know the other bands reboot as well because I have about 50 devices on the 2.4GHZ band and I often see notifications that multiple devices have lost connection recently. Once we are done working today I will redo a clean install to 386.5_0 and go from there.
 
388 wont come for months, possibly not until next year for existing models.

I received an updated driver/SDK for the RT-AX86U, I haven't had time to test it yet.

As for the RT-AX88U, a new GPL is expected in the coming weeks to add support for a new SoC revision.
Do you foresee having enough time to: Stuff the updated driver/SDK for the RT-AX86U into 386.7_2 ???
I'd love to retest 160MHz with the new drivers, as Tech9 seems to be having much improved WiFi since going stock.
Myself I can't easily go stock because I'll loose my USB-drive functionality & it's tied to my DIY home automation.
 
Last edited:

Similar threads

Latest threads

Sign Up For SNBForums Daily Digest

Get an update of what's new every day delivered to your mailbox. Sign up here!
Top