Asus rt-ax86u 5ghz band crashing with new firmware when downloading

[SteelSteve]

Like everyone else my AX86U and AX86S don't seem to be playing nice with 388. My 5GHZ band drops periodically (though admittedly less since resetting), no 160MHZ, and my connection speeds with my ISP are much lower than previous routers (Verizon Gigabyte). I'm assuming 386.5_2 will help at least with my 5ghz issues. I don't however see a 386.5_2 version on ASUS's web site. Can you provide the full ASUS version number or a link to this recommended firmware?

 

[John Fitzgerald]

Like everyone else my AX86U and AX86S don't seem to be playing nice with 388. My 5GHZ band drops periodically (though admittedly less since resetting), no 160MHZ, and my connection speeds with my ISP are much lower than previous routers (Verizon Gigabyte). I'm assuming 386.5_2 will help at least with my 5ghz issues. I don't however see a 386.5_2 version on ASUS's web site. Can you provide the full ASUS version number or a link to this recommended firmware?

If you want stock firmware stay on the ASUS site.

 

[SteelSteve]

If you want stock firmware stay on the ASUS site.

So is the 386.5_2 a Merlin firmware?

 

[John Fitzgerald]

So is the 386.5_2 a Merlin firmware?

Yes

 

[SteelSteve]

Yes

Thanks

 

[capncybo]

@capncybo - if you indeed have WiFi 6 devices - then backup your buggy 388.1 system [save settings and save JFFS] - then load 386.5_2, reset and experience the speed rush you will get on those devices and more importantly enjoy the awesome stability and quiet system logs that firmware brings. .
Alternatively - keep your RT-AX86U's on 388.1 - ignore your logs and put up with intermittent drops of your WiFi clients.

I'm not so certain we currently have any WiFi-6 devices in our household (I had one but It's definitely broken), although I'm in the process of upgrading my phone.
But at one time (on the older firmware) I thought I did observe160MHz working properly.
However, It just seemed rather illogical to me to occupy that much bandwidth for only one device when the rest of my family of 5 could not even benefit.

USER=74388]@MrBeer[/USER]
Drop your system log into pastebin and I'll introduce you to all the glitches you are not recognizing

Can I take you up on the offer you made to MrBeer, as I don't seem to be experiencing (any/many) WiFi Dropouts but I may be missing some of the glitches?
With my (admittingly limited skill-set) I've occasionally glanced through the log inside the GUI & didn't see much.
But since you suggest a much closer look...
Can't I just:
cat /tmp/syslog.log |grep something_problematic

Would you please be kind enough to pass me some (problematic/re-occurring) parameters I should be looking for?
Note: my current uptime on 388.1 is 17 days 2 hour(s) 35 minute(s) 39 seconds so I'm definitely not being plagued by reboots.
And perhaps I should be looking elsewhere?
Thanks @kernol

 

[octopus]

No. We can count how many people reversed the firmware and now many are new forum members. Not so difficult.

We can't believe that all new forum members have knowledge about asus routers.
Those of us who have been around a long time have known how it works.

Hence so many reports of it not working.

 

[BobbyFlobby]

So I updated to the new firmware and have been going nuts figuring this out. I can only assume it’s the new firmware at this point. It crashes whenever I torrent/FaceTime/download large files/mega sync, basically anything data intensive. It’s so frustrating. The 2.4ghz band works fine though.

what are your settings for both 5ghz sections?
Im finding 388.1 super stable on both channels with 2 x AX86U in mesh, where the last few firmwares i wasnt.

 

[RMerlin]

The most common fix reported by multiple RT-AX86U users so far was switching to a fixed channel instead of sticking to automatic channel selection. A few fixed it by doing a factory default reset, but it`s possible that they simply configured channel selection differently when they did their reconfiguration. A few also fixed it by disabling 160 MHz support, which leads me to believe that their issue might have been DFS-related, as both auto channel and using 160 MHz might have been moving them into DFS channels.

I also remember multiple RT-AX86U users who were having issues with 386.7 and it was fixed for them with 386.7_2 when I merged a newer radio firmware from upstream. So, I see no reason for people to go back to a 6+ month firmware version.

 

[brummygit]

I've been doing further testing with my setup over the last 24 hours. I am not sure that it is any specific WiFi setting that is affecting me although I do see vast improvements with the number of 2.4Ghz IoT clients that will choose to use the AX86U nodes rather than the AX88U main router when I do the following:

• Turn off WiFi 6 mode
• Change to WPA/WPA2
• Use AES + TKIP for WPA encryption
• Turn on Ethernet Backhaul Mode

I always use fixed channels with my WiFi networks.

Irrespective of these I am seeing some strange things on 5Ghz. Using InSSIDer I can see that my 5Ghz networks show a configuration mismatch. The only thing I can see is that the AX88U shows a country code of DE (I am in the UK and think that German coded routers ship in Europe) whereas the AX86U nodes have no country code displayed on either 2.4Ghz or 5Ghz. I have also see that sometimes (when config has been changed but not in the following screenshots) my 5Ghz network is missing the 12mbps rate in the basic rates available.



My observations are that it doesn't seem to be specific settings that make or break my network, but that there is a side effect of making config changes. I'm starting to wonder if some main routers are not passing all of the parameters to the AX86U nodes correctly and they are essentially misconfigured in some way?

 

[Tech9]

Those of us who have been around a long time have known how it works.

I know how it works already. Not testing nor reporting anything works best.
Why do you run stock Asuswrt on your node, by the way? Asuswrt-Merlin has full AiMesh support.

 

[capncybo]

The most common fix reported by multiple RT-AX86U users so far was switching to a fixed channel instead of sticking to automatic channel selection. A few fixed it by doing a factory default reset, but it`s possible that they simply configured channel selection differently when they did their reconfiguration. A few also fixed it by disabling 160 MHz support, which leads me to believe that their issue might have been DFS-related, as both auto channel and using 160 MHz might have been moving them into DFS channels.

I also remember multiple RT-AX86U users who were having issues with 386.7 and it was fixed for them with 386.7_2 when I merged a newer radio firmware from upstream. So, I see no reason for people to go back to a 6+ month firmware version.

Not sure if you caught all of my theories but I was really starting to suspect DFS as well. However with @kernol & his certainty of the possibility of functional 160MHz... I just enabled the 160MHz Checkbox & selected: 20/40/80/160MHz Channel Bandwidth, Control Channel=Auto(Currently on 36), BUT I removed the check-mark from: __ Auto select channel including DFS channels.

I did this because I have a new phone (a pixel-7)... & 160MHz is working, so far...

EDIT: almost forgot, my BIG surprise was under system log -> Wireless log it does actually say:
Channel: 36/160
DFS State: In-service Monitoring (ISM)
So why @kernol yours does not is the big question ???

Understanding of course that my router could actually start to glitch... but so far so good

 

[Mogsy]

The most common fix reported by multiple RT-AX86U users so far was switching to a fixed channel instead of sticking to automatic channel selection. A few fixed it by doing a factory default reset, but it`s possible that they simply configured channel selection differently when they did their reconfiguration. A few also fixed it by disabling 160 MHz support, which leads me to believe that their issue might have been DFS-related, as both auto channel and using 160 MHz might have been moving them into DFS channels.

I also remember multiple RT-AX86U users who were having issues with 386.7 and it was fixed for them with 386.7_2 when I merged a newer radio firmware from upstream. So, I see no reason for people to go back to a 6+ month firmware version.

This sticky and WiFi Analyzer on Windows. My 2.4 works with channel 13

 

[Morris]

Reading this thread makes it very clear that most on here are not network engineers. This is advice for those of you that are not network engineers:

- Manufactures spend considerable time determining the default settings they ship a product with. Furthermore, every time there is a firmware update, the QA team will test using the default settings and some other ones that the support team has found to be commonly used.
- When you change a setting, it should be done because something is not working well. Furthermore, you should understand what the setting dose and why changing it will correct the problem.
- Any time you make a setting change you should document this change in your device notes with a time stamp and comment why you made the change
- Don't make any changes till you are confident that the change you made has corrected the problem and you are confident that there are not unwanted side effects
- If the problem is not corrected or there are side effects back the change out and make a note in your device notes
- Making a device run a little faster is cool yet if it takes moving away from the defaults, you are exposing your network to a possibly untested configuration
- 160 wide channels sound twice as fast as 80 wide, even under the best conditions throughput will not reach double that of 80 wide and in fact is more likely to be 10 to 20% faster and there is a good chance that it will be slower! This is because you are increasing the chance of interference. Also, 160 wide requires DFS and this means the 5-Ghz channel must listen before transmitting. Furthermore, should the AP (router) or client hear weather radar or aircraft weather radar it must stop transmitting on that channel. This frequently causes drops.
- Auto channel will help avoid your AP sharing a busy channel. Fixed channels will avoid client drops when the channel changes. Not all clients will drop if the AP changes the channel. Chose your pain point.

WiFi is complicated and there are a huge number of possible configurations made even larger because this is true for both the AP (router) and the client. The further you move from the default settings, the more likely you will have problems.

My router is the same RT-AX86U that others are having issues with. I run 80 wide as I'm near an airport. I use auto channel and while my channel sometimes changes, none of my clients drop there connection.

Be smart, defaults are your friend.

 

[Dedel66]

Or did you manually select & force 160MHz ( I would expect you selected the Range)
& what about your control channel ?

Release - Asuswrt-Merlin 388.1 is now available for all supported Wifi 6 models

RE: WireGuard I can confirm what RMerlin stated about WG from his Post #1. Without Flow Cache Enabled a significant speed deficit is experienced. Still looking for a Griswald Easy step-by-step OpenVPN tutorial with a QR code for The Family to quickly setup on their devices ;)

www.snbforums.com

Works fine for me, also on the nodes.
Good luck!

 

[brummygit]

Reading this thread makes it very clear that most on here are not network engineers. This is advice for those of you that are not network engineers:

<SNIP>

Be smart, defaults are your friend.

As an IT infrastructure engineer and now architect for over 30 years I agree with your sentiments in general. There are a few exceptions such as Universal Beamforming which is known to cause issues with some devices, but in general I agree.

I am not in the search for 160Mhz bandwidth - 80Mhz will do me fine. I use fixed channels because I have many neighbours and on 2.4Ghz the Asus will use antisocial choices, on 5Ghz I have found channel 100 to be empty and work just fine for me.

I am seeing that when I build my network using defaults, my AX88U main router holds the connections for most of my IOT devices on 2.4Ghz even when they are struggling for signal due to extended range. If I make some changes to my config I see an improvement on devices which will use my AX86U nodes.

However I think that some of my config changes are snake oil and it's the push of parameters to the nodes that's relevant rather than the actual settings. As an example, during my tests I switched from WPA2 to WPA/WPA2 and instantly many of my devices connected to nodes. However later a config change (I don't recall exactly what) caused them to revert to the AX88U. Switching back to WPA2/WPA3 improved the situation. I have also seen that turning on Ethernet Backhaul Mode (which asks you to confirm the WPA passkey) suddenly caused an even split of devices across my nodes. Nothing makes sense for individual settings, but I think it's the way settings are pushed from the main router to the nodes. Maybe the AX88U and AX86U have slightly different parameter names internally or something in code??

I would be interested to know if people who are having trouble are using the RT-AX86U as a mesh node, and if so which main router they have. I plan to rebuild my network using one of my AX86Us as the main router and see if it makes a difference.

 

[Tech9]

As an example, during my tests I switched from WPA2 to WPA/WPA2 and instantly many of my devices connected to nodes.

Happens on Wi-Fi restart for any reason. If you wait long enough the devices will connect back to where they usually connect.

 

[hancox]

Reading this thread makes it very clear that most on here are not network engineers. This is advice for those of you that are not network engineers:

- Manufactures spend considerable time determining the default settings they ship a product with. Furthermore, every time there is a firmware update, the QA team will test using the default settings and some other ones that the support team has found to be commonly used.
- When you change a setting, it should be done because something is not working well. Furthermore, you should understand what the setting dose and why changing it will correct the problem.
- Any time you make a setting change you should document this change in your device notes with a time stamp and comment why you made the change
- Don't make any changes till you are confident that the change you made has corrected the problem and you are confident that there are not unwanted side effects
- If the problem is not corrected or there are side effects back the change out and make a note in your device notes
- Making a device run a little faster is cool yet if it takes moving away from the defaults, you are exposing your network to a possibly untested configuration
- 160 wide channels sound twice as fast as 80 wide, even under the best conditions throughput will not reach double that of 80 wide and in fact is more likely to be 10 to 20% faster and there is a good chance that it will be slower! This is because you are increasing the chance of interference. Also, 160 wide requires DFS and this means the 5-Ghz channel must listen before transmitting. Furthermore, should the AP (router) or client hear weather radar or aircraft weather radar it must stop transmitting on that channel. This frequently causes drops.
- Auto channel will help avoid your AP sharing a busy channel. Fixed channels will avoid client drops when the channel changes. Not all clients will drop if the AP changes the channel. Chose your pain point.

WiFi is complicated and there are a huge number of possible configurations made even larger because this is true for both the AP (router) and the client. The further you move from the default settings, the more likely you will have problems.

My router is the same RT-AX86U that others are having issues with. I run 80 wide as I'm near an airport. I use auto channel and while my channel sometimes changes, none of my clients drop there connection.

Be smart, defaults are your friend.

This is fair, but most of the issues raised are related to, if not caused by, the ASUS defaults. Auto/160/DFS is asking for trouble, IMHO, and always has been. It would also be helpful if the DFS scan wasn't achingly slow, and that the router at least tried to place on an empty, non-DFS channel first, then scan, then assign.

I'm almost at the point where everyone should switch to Fixed channel/no 160/non-DFS channel, and see what happens.

 

[brummygit]

Happens on Wi-Fi restart for any reason. If you wait long enough the devices will connect back to where they usually connect.

They don't - even if they are bound to a particular node. Even over 24 hours they simply don't like to connect. This is the whole point that there is something wrong. In fact in the test I have done below I have removed my RT-AX88U entirely and some of my 2.4Ghz devices are staying disconnected rather than connecting to the AiMesh node AX86U which is in range.

I've just built one AX86U as primary and added the second as a node. Both running Merlin 388.1 after a full reset and then just setting fixed channels and disabling Universal Beamforming. I have the usual report that the node is disconnected when it actually working, however InSSIDer reports that there is a WiFi configuration mismatch between the two identical routers - this should not be the case.

Main Router:



Mesh Node:


EDIT: Interestingly my IOT devices are happy to connect to the main AX86U, just not the mesh node one. It's the same with the mesh node running stock 388_22068.
EDIT2: More interestingly I added the AX88U as a node running Merlin 388.1 which also seems reluctant to receive IOT clients, but I can bind them and they move happily. The very strange thing is that turning on Ethernet Backhaul immediately redistributed all clients as I would normally expect to give an even coverage. It's as though turning on Ethernet Backhaul pushes some extra config to the nodes.

I'm about to perform the same tests using the latest Asus stock firmware released this week, and if the same will report to Asus

 

[brummygit]

A further update my previous post.

I have now rebuilt using the latest stock firmware 388_22068 - 1 x RT-AX86U as main router, 1 x RT-AX86U as AiMesh node. All as defaults except fixed channels. I can confirm that my IOT devices are now connecting correctly to the mesh node after an hour.

This leads me to believe that earlier AX code / WiFi drivers have an issue affecting how the AX86U mesh node is configured off the main router. I plan to add my RT-AX88U as another node running the latest stock for that model and see how it goes for a few days, but my initial conclusion is that we will need to wait for the latest code to be included in a future Merlin release - in my testing this seems to need both AX86U and the main router (AX88U in my scenario).