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

[Morris]

Sadly I have set my 2 AX86Us up as an AP and AiMesh node pair tonight running the latest stock firmware. I can get the clients to initially connect, but after a few minutes they migrate to the AP and dislike the mesh node. Therefore I now think we still need to wait for ASUS to fix the issues in the stock firmware before even considering whether RMerlin can merge them into his own code.

Next step is to run both as APs and prove that they work fine individually, but that means relying on roaming assistant.

It is the clints decision where to connect. Many clients will attempt to the last AP they connected to before checking if there is a stronger signal. This is true even if the client is power cycled.

 

[Tech9]

@Tech9 Common bro play nice, It's X-Mas ;-)

Yes, I have deleted my post. I have different findings where the issue is. Go on with your conversation. Merry Christmas!

it seems this is ssue a carryover from the stock firmware

Run stock firmware and report issues, if you have any. There is feedback form available in stock Asuswrt. This is what I do.

 

[Morris]

FWIW I really doubt the classic 5ghz drop/crash on the AX86U is related to 160mhz/DFS stuff.

I have an AX86U and GT-AX6000. Both on 388.1. Am in a large apartment complex across from another large complex, on a road with different types of emergency vehicle traffic, and also have some aircraft that go over the area.

GT-AX6000 is set to auto select channels (auto select DFS on, 160mhz enabled etc), never has a single WiFi drop out.

In the process of troubleshooting the 5ghz crashing on the AX86U I disabled the 160mhz/DFS stuff and would still experience drops.

Both routers factory reset with initialize previously, default settings.

Dose your GT-AX6000 change channels and/ot go to 80 wide when aircraft go over?

 

[Morris]

I would assume (if we disable: __ Auto select channel including DFS channels)... we should NEVER actually see... DFS State: Channel Switching Announcement(CSA)
+
Perhaps I missed seeing the "POST-ISM Channel Availability Check"... I'll take a closer look.
Thanks for the info... I'm learning.
Merry Christmas!!!

If you do not enable DFS channels then there is no check for radar

 

[Kingp1n]

AiMesh is not a good "mesh" - my other final conclusion. Much better "mesh" product out there.



No, clients rely on themselves in both cases - AiMesh or AP Mode. The "roaming" is exactly the same. Tested already.

I tried Asus plus other "mesh" prodcuts/systems out there and unless you have a hardwired mesh system all around, they are all NOT so great overall, at least in my experience/environment...can't speak for all.

 

[brummygit]

It is the clints decision where to connect. Many clients will attempt to the last AP they connected to before checking if there is a stronger signal. This is true even if the client is power cycled.

Yes, I agree in general and especially with IOT devices on 2.4Ghz. In a mesh setup it is possible to steer devices to specific nodes - think how binding clients works on AiMesh. However my clients usually distribute evenly over a relatively short space of time (a couple of hours) with the exception of a few older ones which are more sticky, but for some reason with the latest AX86U firmware many clients that would normally connect fine will avoid the mesh node. I have proven this over the last 24 hours by running both AX86Us as standalone APs and the clients have spread themselves correctly.

There is something wrong with how the AX86U gets configured as a mesh node - the 5Ghz networks show a config mismatch between main router and node when looking with a WiFi analyser (InSSIDer in this case) but both configured as APs there is no warning.

I'm having to regress the firmware on my network anyway as even running as a wires only AX88U router on 388.1 plus 2x AX86U nodes on 388_220068, I'm seeing some intermittent connectivity problems on wireless devices.

 

[chadleysutoff]

Dose your GT-AX6000 change channels and/ot go to 80 wide when aircraft go over?

I haven’t checked for that specifically, but I can.

 

[kernol]

There is something wrong with how the AX86U gets configured as a mesh node - the 5Ghz networks show a config mismatch between main router and node when looking with a WiFi analyser (InSSIDer in this case) but both configured as APs there is no warning.

I'm having to regress the firmware on my network anyway as even running as a wires only AX88U router on 388.1 plus 2x AX86U nodes on 388_220068, I'm seeing some intermittent connectivity problems on wireless devices.

Fully appreciate all your testing efforts and posts on this troublesome RT-AX86U on 388.1
A few folk "seem" not to experience any issues - but then again with that recent Asus stock firmware fiasco on this router a while back - some upgraded successfully - while others had their RT-AX86U's bricked and later replaced by Asus. Not all RT-AX86U's are equal??

@Tech9 has spent a LOT of time evaluating the issues and identified at the outset that there were driver and AiMesh issues with this RT-AX86U router on 388.1 - I hit the same brick wall ... and have posted at some length on my own experiences.

Forgive the repeated BOLD characters for the router model - but several folk using entirely different router models keep chiming in that they don't have these issues .

Best wishes to everyone for Christmas and the New Year.

 

[Tech9]

were driver and AiMesh issues with this RT-AX86U router on 388.1

Not sure about the Wi-Fi driver, but AiMesh issues are there in all 386 Asuswrt-Merlin releases and now in first 388 release. The same Wi-Fi tests I did with 388.1 were repeated with stock 388_20566 and 388_21709 and both Asuswrt pass with no issues. 388.1 is based on 388_21224 GPL though.

 

[RMerlin]

I would assume (if we disable: __ Auto select channel including DFS channels)... we should NEVER actually see... DFS State: Channel Switching Announcement(CSA)

Unless you manually picked a DFS channel, or you enabled 160 MHz channel support.

 

[Morris]

Yes, I agree in general and especially with IOT devices on 2.4Ghz. In a mesh setup it is possible to steer devices to specific nodes - think how binding clients works on AiMesh. However my clients usually distribute evenly over a relatively short space of time (a couple of hours) with the exception of a few older ones which are more sticky, but for some reason with the latest AX86U firmware many clients that would normally connect fine will avoid the mesh node. I have proven this over the last 24 hours by running both AX86Us as standalone APs and the clients have spread themselves correctly.

There is something wrong with how the AX86U gets configured as a mesh node - the 5Ghz networks show a config mismatch between main router and node when looking with a WiFi analyser (InSSIDer in this case) but both configured as APs there is no warning.

I'm having to regress the firmware on my network anyway as even running as a wires only AX88U router on 388.1 plus 2x AX86U nodes on 388_220068, I'm seeing some intermittent connectivity problems on wireless devices.

Having fewer clients on the router is not necessarily a bad thing as it's tasked with many processes that the nodes don't run. It the clients are seriously under performing then there is an issue. I've seen nodes and router with different WiFi features enabled yet again what matters is that the clients get good performance. By backing out you bring back security risks that were corrected in the latest code. Did you analyze those risks to decided if it's a good idea to accept them?

To put it simply, if you did not look so close, would you be aware of any problems with the latest code?

 

[Morris]

Fully appreciate all your testing efforts and posts on this troublesome RT-AX86U on 388.1
A few folk "seem" not to experience any issues - but then again with that recent Asus stock firmware fiasco on this router a while back - some upgraded successfully - while others had their RT-AX86U's bricked and later replaced by Asus. Not all RT-AX86U's are equal??

@Tech9 has spent a LOT of time evaluating the issues and identified at the outset that there were driver and AiMesh issues with this RT-AX86U router on 388.1 - I hit the same brick wall ... and have posted at some length on my own experiences.

Forgive the repeated BOLD characters for the router model - but several folk using entirely different router models keep chiming in that they don't have these issues .

Best wishes to everyone for Christmas and the New Year.

The RT-AX86U that bricked are the same as per withing spec as the ones that did not. Timing, random unutilized memory references, settings and environmental conditions are the differentiators. The fact that there were problems that were corrected has noting to do with the issues you are facing. Please provide a bulleted list of the issues you are facing.

 

[Morris]

Not sure about the Wi-Fi driver, but AiMesh issues are there in all 386 Asuswrt-Merlin releases and now in first 388 release. The same Wi-Fi tests I did with 388.1 were repeated with stock 388_20566 and 388_21709 and both Asuswrt pass with no issues. 388.1 is based on 388_21224 GPL though.

Please provide a bulleted list of AI Mesh issues you are experiencing

 

[L&LD]

He'd have to be actually using an Asus AiMesh capable router/node to have issues first.

 

[brummygit]

Fully appreciate all your testing efforts and posts on this troublesome RT-AX86U on 388.1
A few folk "seem" not to experience any issues - but then again with that recent Asus stock firmware fiasco on this router a while back - some upgraded successfully - while others had their RT-AX86U's bricked and later replaced by Asus. Not all RT-AX86U's are equal??

@Tech9 has spent a LOT of time evaluating the issues and identified at the outset that there were driver and AiMesh issues with this RT-AX86U router on 388.1 - I hit the same brick wall ... and have posted at some length on my own experiences.

Forgive the repeated BOLD characters for the router model - but several folk using entirely different router models keep chiming in that they don't have these issues .

Best wishes to everyone for Christmas and the New Year.

Thanks for your comments. In addition to not all RT-AX86Us being equal, there are obviously differences in people's configurations which seem to influence whether people experience issues or not.

I have now been running back on 386 code as a mesh for approx 12 hours and so far it is rock solid. I've drawn the following conclusions about problems that are recently introduced:

• On all 388 code the RT-AX86U suffers issues running as a mesh node - it drops offline and back online frequently causing latency problems and clients to roam to other nodes. This is general instability that is new on 388 but also masking some other problems.
• Running Merlin 388 code the RT-AX86U node shows as offline on the topology diagrams
• The most recent stock firmware 388_22068 is buggy causing connectivity issues

These are the big ones for me:

• Running the RT-AX86U as a mesh node against either another RT-AX86U or my RT-AX88U as main routers - on all versions of AX86U firmware (386 and 388) generates a mismatch between the main router and mesh node 5Ghz networks as reported in InSSIDer - this is not seen when to are set as basic APs. The mesh node is misconfigured. This is a long standing issue and on both bands I see things like differences in the basic rates offered, country settings, and disabling "b" mode is not carried over to the nodes.
  
• Running the RT-AX86U as a mesh node against either another RT-AX86U or my RT-AX88U as main routers - on all versions of AX86U firmware (386 and 388) causes some of my 2.4Ghz clients to not connect to the RT-AX86U mesh node (they are happy on the main router) and even if forced there they soon leave again.
  I can "fix" this issue by simply changing my WPA setting from WPA2 PSK to WPA2 / WPA3 PSK mode, however some future change to wireless settings can cause this "fix" to lost and I have to change again. Also changing to WPA / WPA2 PSK works - don't ask me why, but I think it's about pushing the right changes to the node rather than my clients compatibility with the WiFi Authentication Mode used as they are using WPA2.

People keep trying to tell me that clients are simply reconnecting to their previous radio etc etc but the behaviour is clear to see and only takes a few mins for them to redistribute - either as shown below when the world is in a happy place with a relatively even spread, or when it's not working I have approx 50 clients on the AX88U and a few mainly 5Ghz clients on the AX86U nodes and some devices remain offline.

Interestingly, people with long memories may recall that early in the RT-AX88U lifecycle there were similar problems affecting the 2.4Ghz band - again myself and some others reported that devices would avoid connecting to the main router and instead chose the mesh nodes which were different models. Those were back before I invested in the RT-AX86Us but I think that maybe Asus fixed it in the RT-AX88U code quite a long time ago, but the RT-AX86U suffers the same issue only when working as a mesh node - probably due to a wifi parameter missing on the node.

Unfortunately it's clearly a RT_AX86U issue that Asus need to fix, and RMerlin can only use the GPL and drivers her receives from them.

 

[brummygit]

Please provide a bulleted list of AI Mesh issues you are experiencing

See above for mine

Having fewer clients on the router is not necessarily a bad thing as it's tasked with many processes that the nodes don't run. It the clients are seriously under performing then there is an issue. I've seen nodes and router with different WiFi features enabled yet again what matters is that the clients get good performance. By backing out you bring back security risks that were corrected in the latest code. Did you analyze those risks to decided if it's a good idea to accept them?

To put it simply, if you did not look so close, would you be aware of any problems with the latest code?

In general, yes offloading workload to the nodes is a good thing - this is what I prefer but turning off the wifi on the main router causes problems with the mesh nodes. However in my case I end up with the clients all clinging to the central main router which is in a cellar with foil backed insulation everywhere, when the mesh nodes are at the outer perimeter of my home.

I end up with some 2.4Ghz clients simply disconnected, and CCTV cameras etc not getting enough bandwidth to operate properly.

 

[Morris]

Thanks for your comments. In addition to not all RT-AX86Us being equal, there are obviously differences in people's configurations which seem to influence whether people experience issues or not.

I have now been running back on 386 code as a mesh for approx 12 hours and so far it is rock solid. I've drawn the following conclusions about problems that are recently introduced:

• On all 388 code the RT-AX86U suffers issues running as a mesh node - it drops offline and back online frequently causing latency problems and clients to roam to other nodes. This is general instability that is new on 388 but also masking some other problems.
• Running Merlin 388 code the RT-AX86U node shows as offline on the topology diagrams

Why are you running Merlin on the nodes? This makes your upgrades more complicated and you are not getting the latest bug fixes. Try the stock firmware

• The most recent stock firmware 388_22068 is buggy causing connectivity issues

These are the big ones for me:

• Running the RT-AX86U as a mesh node against either another RT-AX86U or my RT-AX88U as main routers - on all versions of AX86U firmware (386 and 388) generates a mismatch between the main router and mesh node 5Ghz networks as reported in InSSIDer - this is not seen when to are set as basic APs.

WiFi clients are more than capable of moving between APs with different WiFi features. This is not an issue. What matters is how your clients preform

• The mesh node is misconfigured. This is a long standing issue and on both bands I see things like differences in the basic rates offered, country settings, and disabling "b" mode is not carried over to the nodes.View attachment 46612
  

This message is contrary to the WiFi Standards. I don't know why Asus displays this as WiFi clients are more than capable of moving between APs with different WiFi features. This is not an issue. What matters is how your clients preform

• Running the RT-AX86U as a mesh node against either another RT-AX86U or my RT-AX88U as main routers - on all versions of AX86U firmware (386 and 388) causes some of my 2.4Ghz clients to not connect to the RT-AX86U mesh node (they are happy on the main router) and even if forced there they soon leave again.
  I can "fix" this issue by simply changing my WPA setting from WPA2 PSK to WPA2 / WPA3 PSK mode, however some future change to wireless settings can cause this "fix" to lost and I have to change again. Also changing to WPA / WPA2 PSK works - don't ask me why, but I think it's about pushing the right changes to the node rather than my clients compatibility with the WiFi Authentication Mode used as they are using WPA2.

It dose not matter what node a client connects to. What matters is how it preforms

People keep trying to tell me that clients are simply reconnecting to their previous radio etc etc but the behaviour is clear to see and only takes a few mins for them to redistribute - either as shown below when the world is in a happy place with a relatively even spread, or when it's not working I have approx 50 clients on the AX88U and a few mainly 5Ghz clients on the AX86U nodes and some devices remain offline.

Yep, if your clients are connecting and working well there is no issue no matter where they connect

View attachment 46611

A disconnected node is an issue. This is with older code. Upgrade!

Interestingly, people with long memories may recall that early in the RT-AX88U lifecycle there were similar problems affecting the 2.4Ghz band - again myself and some others reported that devices would avoid connecting to the main router and instead chose the mesh nodes which were different models. Those were back before I invested in the RT-AX86Us but I think that maybe Asus fixed it in the RT-AX88U code quite a long time ago, but the RT-AX86U suffers the same issue only when working as a mesh node - probably due to a wifi parameter missing on the node.

Unfortunately it's clearly a RT_AX86U issue that Asus need to fix, and RMerlin can only use the GPL and drivers her receives from them.

The history is irrelevant. What matters is the hear and now. You don't appear to have any issues.

 

[Morris]

See above for mine


In general, yes offloading workload to the nodes is a good thing - this is what I prefer but turning off the wifi on the main router causes problems with the mesh nodes. However in my case I end up with the clients all clinging to the central main router which is in a cellar with foil backed insulation everywhere, when the mesh nodes are at the outer perimeter of my home.

I end up with some 2.4Ghz clients simply disconnected, and CCTV cameras etc not getting enough bandwidth to operate properly.

Is the foil backed insolation on the cellar between floors or just on the walls? You don't need the foil between floors. It it is between floors then your are trying to operate WiFi in a Faraday Cage and that is an adventure. WiFi works best when the AP is higher than the nodes or at least level with them. Your router is not ideally located. Are your nodes wired? This would help yet I agree you will see 2.4 GHz clients want to connect to the router. If you can move it as close to the joists in the cellar as possible or better to a central or upper floor. Wire your backhaul if possible.

You have design issues.

 

[Tech9]

Please provide a bulleted list of AI Mesh issues you are experiencing

One major issue in wireless AiMesh configuration - wireless node discovery doesn't work. This makes the setup procedure different than described by Asus. The nodes must be wired first and then they fail back to wireless after dosconnection. If AiMesh stops working (and it does from time to time) the procedure has to be done again. Tested on 386 base with all popular models AC68U, AC86U, AX58U, AC86U, AX88U and later on 388 base with AC86U and AX86U. Perhaps related issue is lost node and unable to reconnect. Observed with AC68U and AC86U as nodes - one of the reasons I don't recommend mixed generations AiMesh setup. Wired AiMesh with all the same routers works well with Asuswrt or Asuswrt-Merlin on main and node, excerption 388.1 with GUI bug. I've spend hours playing with different configurations and have reported my findings in 2-3 release threads, but nothing can be done because AiMesh is a black box. Some of the changes in Asuswrt-Merlin breaks it. There were reports WPS is broken too and perhaps related to the issue.

I'm also getting constant worse Wi-Fi stability/compatibility from Asuswrt-Merlin, but can't say if the changes on top are the reason or the GPL used. Almost always the GPL number is different than stock Asuswrt official firmware release number and this is the case with 388.1 release. I know for sure the driver had an issue in 386.7 because 386_49447 had the same issue at the time. Asus fixed it quickly with 386_49599, the driver was reversed to something else in 386.7_2, performance still worse than 386_49599 and older 386_46061 though. Over time I found some more quirky wireless clients to test Wi-Fi with and use them for stability/compatibility testing. They all work in Asuswrt releases with exception 386_49447, but fail in Asuswrt-Merlin above 386.5_2 release. I see differences in Asuswrt releases as well - best one with no Wi-Fi issues whatsoever including connecting to the network time is 386_49599.

I'm using the advantage of not having the routers as part of my main network and can do whatever with no harmful effects. There were days my currently available AC86U and AX86U were reset multiple times and run few different firmwares for testing purposes. I usually try 2-3 times and if something fails I move on. All routers start fresh and all clients are associated with new connections after boot for cleaner results. I did find many complaints in release threads user created and know how to fix, but the questions are repeated so often that I need to hire an assistant to answer them all 101 times. No intentions to waste my time testing current 388_22068 due to multiple user complaints in first few pages of the release thread. AX86U can relax a bit.

Merry Christmas @Morris!

 

[capncybo]

@Tech9 Thank you (once again) for sharing your findings. Most of us cannot compete with your quality of testing because the routers/nodes are in active use within our homes (&/or) small businesses.
Very much appreciated.