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

[Morris]

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.

This is a well known nuisance issue yet an addition to the Merlin readme and/or a message when tying to join a node would address it for those that are new to Merlin code.

I have not seen the WPS issue reports yet this dose not mean there not real. I wonder if that problem follows certain devices?

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.

Device compatibility has been an issue since the early days of WiFi. The WiFi consortium has mostly made this a non issue via compatibility testing. For the problem devices, are the WiFi consortium tested and approved?

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.

I just spend some time with two of the more frequent people reporting issues. In once case the issue is that he is unhappy with with witch AP devices are connecting. The devices are connecting and working and the best I could tell fine. This is not an issue

The other person has serious issues. Those issues are caused by a combination of a very difficult environment and a WiFi design that makes the situation worse. This is not a code issue

I agree the amount of effort to resolve everyone's issues is large and I agree with Merlin that most WiFi related issues are environmental and/or client issues. Forum members can help these people yet they get advice from both experts and others and this can be confusing for them. Add to the fact that a lot of people don't want to go through the through iterative testing that you and I do and they get no ware. One of the things I like about the Asus routers is how configurable they are yet this leads to more issues, particularly for the less experienced.

Merry Christmas @Morris!

Happy Holidays Tech9

Morris

 

[Tech9]

This is a well known nuisance issue yet an addition to the Merlin readme and/or a message when tying to join a node would address it for those that are new to Merlin code.

The Wiki page says Asuswrt-Merlin has full AiMesh support. It wasn't edited from 2019 and this doesn't apply to AiMesh 2.0 in 386/388 code.

For the problem devices, are the WiFi consortium tested and approved?

No idea, but they work in stock Asuswrt. One is a Linksys E5400 router in wireless bridge mode, second is Apple iPhone 6s, third is LG washer.

Most of us cannot compete with your quality of testing because the routers/nodes are in active use within our homes (&/or) small businesses.

I know and this is not everything. Different Wi-Fi environments, different regions and regulations, even differences between the same model examples change the results and if the user doesn't have any knowledge how to diagnose the issue - this is a problem. Asus made their routers with too many exposed settings. The default settings are a bit too aggressive as well. This same Linksys E5400 router mentioned above in router mode has minimal settings available and has ho issues with any client I have tried it with. I believe it once even connected to my dog at 54Mbps.

 

[capncybo]

... This same Linksys E5400 router mentioned above in router mode has minimal settings available and has no issues with any client I have tried it with. I believe it once even connected to my dog at 54Mbps.

Maybe... but that throughput sounds a little "RUFF"... Suddenly I find myself picturing the Grinch's Dog with that one Antler tied to his Head... looking for a better WiFi signal, LOL

 

[Tech9]

but that throughput sounds a little "RUFF"

I don't know. The dog was making modem/fax connection negotiation sounds.

 

[RMerlin]

This is a well known nuisance issue yet an addition to the Merlin readme and/or a message when tying to join a node would address it for those that are new to Merlin code.

And again, for the 10000th time, when I tested adding a Wireless node that was running Asuswrt-Merlin to a router that was also running Asuswrt-Merlin, both on 388.1, it worked fine for me.

His single datapoint does not confirm his constant claim that "it's broken for everyone, you need to document that it does not work". I have first hand proof that in at least my own test, it worked fine for the two models that I used, and it worked first time, with nothing special involved. If it truly didn't work, then it wouldn't work for anyone at all.

People need to stop with this generalization based on limited datapoints. I'm sick of this. Same crap with this "Wifi is completely broken in 388.1, go back to a 6 months old version" mantra when there are also a significant (i.e. higher than 1) number of people here and beyond this forum who have it working fine, or who fixed their issue by using the settings I have been recommending for years, which is to use a fixed channel on a non-DFS band if you experience stability issues. The 386.7_2 feedback on this specific model was also that it was working fine following the driver update that I applied after the 386.7 release, which did have issues.

Enough. I'm done dealing with this.

 

[Morris]

The Wiki page says Asuswrt-Merlin has full AiMesh support. It wasn't edited from 2019 and this doesn't apply to AiMesh 2.0 in 386/388 code.



No idea, but they work in stock Asuswrt. One is a Linksys E5400 router in wireless bridge mode, second is Apple iPhone 6s, third is LG washer.

You can check for WiFi Alliance Certification here:

https://www.wi-fi.org/ja/product-finder-results

Apple started getting there phones certified with the iPhone 5 so the six is as well. They were terrible before this. There were still some compatibility issues with the 6 and Cisco WiFi networks yet when the iPhone 6 was updated it worked fine
Linksys E5400 Yes- they are a founding member of the WiFi Alliance
LG washer - need model number to check. IOT devices are suspect though LG has a lot of certified devices

I know and this is not everything. Different Wi-Fi environments, different regions and regulations, even differences between the same model examples change the results and if the user doesn't have any knowledge how to diagnose the issue - this is a problem. Asus made their routers with too many exposed settings. The default settings are a bit too aggressive as well. This same Linksys E5400 router mentioned above in router mode has minimal settings available and has ho issues with any client I have tried it with. I believe it once even connected to my dog at 54Mbps.

Your dog is electrifying

 

[Tech9]

People need to stop with this generalization based on limited datapoints.

So tested once and worked is a valid data point, but tested with multiple releases and routers is a limited data point... okay. You seem to ignore for 10000th time all the threads related to the issue. It's not just my findings. I started testing only after I read about people having issues with AiMesh.

Enough. I'm done dealing with this.

Me too in release threads. I will continue providing workaround solutions for people who actually see/have the issues though. The fact is your recent builds for ever increasing number of models supported are actually released with zero testing on your end even for the most popular models around.

 

[kernol]

Enough. I'm done dealing with this.

There is nothing for YOU to deal with - and no one has suggested there is!
Drivers and AiMesh are beyond your control - save that you may at least insist that Asus provides you with released and stable stock before you spend hours, days and weeks building your exceptional Merlinware which we all love and fully enjoy.
Happy Christmas {Jingle-Bells}

 

[Morris]

And again, for the 10000th time, when I tested adding a Wireless node that was running Asuswrt-Merlin to a router that was also running Asuswrt-Merlin, both on 388.1, it worked fine for me.

His single datapoint does not confirm his constant claim that "it's broken for everyone, you need to document that it does not work". I have first hand proof that in at least my own test, it worked fine for the two models that I used, and it worked first time, with nothing special involved. If it truly didn't work, then it wouldn't work for anyone at all.

People need to stop with this generalization based on limited datapoints. I'm sick of this. Same crap with this "Wifi is completely broken in 388.1, go back to a 6 months old version" mantra when there are also a significant (i.e. higher than 1) number of people here and beyond this forum who have it working fine, or who fixed their issue by using the settings I have been recommending for years, which is to use a fixed channel on a non-DFS band if you experience stability issues. The 386.7_2 feedback on this specific model was also that it was working fine following the driver update that I applied after the 386.7 release, which did have issues.

Enough. I'm done dealing with this.

Hi Merlin,

You probably saw that I agree with you regarding WiFi issues and found two of the most consistent people reporting issues do not have issues related Asus router related bugs. One has environmental issues and a bad design that compounds the issue. The other simply disappointed that the clients don't connect to the AP he would expect them to. The clients work fine so I don't consider this an issue.

As far as initial setup of a node, using my RT-AX86U as the router, Another RT-AX86U would not join the mesh when 1 meter away from the router. It joined immediately when I connected via an ethernet jumper. The same happened with my XD6. This was reputable when I set them up in May of 2022. I have not retested with the latest code yet if you would like I can test again.

Happy Holidays and thank you for all you do

Morris

 

[Tech9]

at least insist that Asus provides you with released and stable stock

It's convenient to blame Asus all the time. We are in car with aftermarket parts situation.

 

[John Fitzgerald]

So tested once and worked is a valid data point, but tested with multiple releases and routers is a limited data point... okay. You seem to ignore for 10000th time all the threads related to the issue. It's not just my findings. I started testing only after I read about people having issues with AiMesh.



Me too in release threads. I will continue providing workaround solutions for people who actually see/have the issues though. The fact is your recent builds for ever increasing number of models supported are actually released with zero testing on your end even for the most popular models around.

This negative conversation is not a fruitful one.

The one man doing the work needs a break.

I'm running OK with 388.1 on 2 AX86U's and 2 AX58U's.

I don't do anything to the same degree that many others here do. I'm much closer to stock and a simple setup.

There is no promise of a working system for those that tinker beyond stock function. And yes, sometimes you need to start over from scratch. (I hear moaning from all those that have complicated setups.)
Last go around 386.7 and .7_2, I had to reset fresh. This time I didn't.

The recent Entware update has caused some additional issues including me today updating the 2nd AX58U, Skynet not Updating properly (forced) "jffs/curl name not found/updated" until I rebooted the router. I'm using the AX58 as a Standalone right now.


I wish everyone a Happy Holiday in whatever form you celebrate the season.

 

[Tech9]

This negative conversation is not a fruitful one.

I have wasted days/weeks in testing and the end result was called "single datapoint" and workaround solutions "crap". As I said before reporting issues turns me into the bad guy. Tried couple of times and it didn't work - okay, no problem here. No more testing and reporting is the best solution for me.

Merry Christmas everyone and stay healthy in 2023!

 

[Morris]

It's convenient to blame Asus all the time. We are in car with aftermarket parts situation.

No! We are getting some transparency into the team and opensource development process. Some of the code is close source and there are at least 3 for profit components mixed in with the open source code.

Furthermore, your comment is rather disrespectful

 

[Morris]

I have wasted days/weeks in testing and the end result was called "single datapoint" and workaround solutions "crap". As I said before reporting issues turns me into the bad guy. Tried couple of times and it didn't work - okay, no problem here. No more testing and reporting is the best solution for me.

Merry Christmas everyone and stay healthy in 2023!

View attachment 46636

It might just be your constant aggressive methods results in your not being listened to

 

[John Fitzgerald]

I have wasted days/weeks in testing and the end result was called "single datapoint" and workaround solutions "crap". As I said before reporting issues turns me into the bad guy. Tried couple of times and it didn't work - okay, no problem here. No more testing and reporting is the best solution for me.

Merry Christmas everyone and stay healthy in 2023!

View attachment 46636

Did any of the testing result in a solution or just showing that a problem exists.

If someone said "here's the fix", that would get attention.

I don't disagree with what you find but so many that are on this site have such vastly different world setups and don't fully report all their modifications that trying to fix anything is almost a non-starter for anyone trying to help.
Work-arounds are always helpful and practical solutions. Keep providing them.

I do find it hard to be polite at times with answers to basics that can be readily found, so I just don't bother. The time it takes to write about the problem could have been found by oneself, but people are lazy.

So many don't read the first post. The same trend repeats itself after every release cycle. So I do understand the frustration.

You can only help some of the people some of the time. Tell a smoker that it's bad for them and why and they will say they know, but keep smoking.

I hope you don't take any of this personally.

Have a wonderful holiday.

 

[hancox]

Did any of the testing result in a solution or just showing that a problem exists.

If someone said "here's the fix", that would get attention.

Wishful thinking. Perfect example is QoS and flowcache on the AX86. Unless someone has proof otherwise, it's broken for everyone (the only people it's "working" for don't hit the bandwidth threshold to make it relevant). Disabling fc resolves the issue, but caps throughput. Been broken for months. Communicated all over the forum for months. Sent to ASUS by at least a few. "Attention" would be an improvement.

I feel for you, @RMerlin. You're putting lipstick on a pig that is getting uglier by the day. I'd be annoyed, too.

 

[Tech9]

Did any of the testing result in a solution or just showing that a problem exists.

Yes! On the user side only , down to the details and according to hardware and firmware version used. I have posted some “crap” hundreds of times for both AiMesh issues and tested/verified more compatible Wi-Fi settings. I can’t fix what’s not working in firmware, but I found many workarounds applicable in some, but not all cases. For other issues too in specific firmware versions. I have workarounds for “non existing” issues basically and because the issues are not officially recognized we have hundreds of repetitive questions and answers going on in a loop for months. No, the usual "fix" reboot and reset doesn't fix firmware issues. The final conclusion is either Asus base is in fault or the users have no idea what they are doing. I know what I'm doing.

 

[L&LD]

None of the issues are present over a wide range of Asus/RMerlin powered models (main router and nodes both running RMerlin, BTW) for myself and many customers who would have called me immediately if their setup was flakey.

RMerlin doesn't have a single data point. He has everyone else's input too. Because they'd be here complaining too. Instead of a handful of people that are most vocal about it.

The models I'm referring to above entail combinations of everything from RT-AC66U_B1s, RT-AX58Us, RT-AX68Us, RT-AX88Us, and RT-AX86Us, to GT-AX6000s. With a smattering of RT-AC68Us, and even a few RT-AC3100s and RT-AC56Us too (the latter mostly used for Media Bridge duties).

If there were issues, I would have reported them first.

For some, a simple reboot (after about 24 hrs.) made the network stable and reliable again. For others, a single WPS button reset and manual configuration was enough to achieve stability. For a handful of routers (as always), multiple resets and re-flashing of the 388.1 (or, their current code base) was needed. But not one router was lost or given up on.

Personally, I have been running my main RT-AX86U for over two years now with only 'dirty' upgrades, even to the latest 388.1 final. No issues, but of course, I don't go fiddling with the router 'just to see what happens' either.

Not saying there are no issues for some. But previous posters above have stated valid reasons why they may be seeing those issues already too.

Wishing everyone and their families a Very Merry Christmas with Health, Happiness and Prosperity for all.

 

[brummygit]

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

As a test - I usually run stock on the nodes, however there is a difference with Merlin on the nodes

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

.....and you keep ignoring my point - my clients do not perform because they either attach to my main router which is effectively in a faraday cage, or attach to the wrong node which has very weak signal (and therefore slow speeds) or no signal and do not associate at all. My nodes are placed to achieve the required coverage.

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

I disagree - the fact that differences in identical main router and node WiFi configuration can be observed using a wireless analyser indicates that Asus are node configuring the nodes the same as the main router. My problem is that the clients differentiate as well when they are selecting the station to associate with. Asus have a software error that needs to be fixed and is a good indicator where the issues lie.

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



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

Correct - and if I upgrade to the newer 388 firmware, I have issues. If I don't frig the config on the most recent version of the 386 code base, I have issues.

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

I have disconnected nodes unless I frig the config to make it work. I can trace this issue back to early 386 firmware on the RT-AX86U when running as mesh nodes. It still exists on the latest 388 release, but is further complicated/obscured by the current mesh instability issues in the 388 code.

I have repeatedly said I can't upgrade as problems are worse on 388 - you seem to be ignoring what is posted.
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 history is irrelevant. What matters is the hear and now. You don't appear to have any issues.

I don't have any issue currently because I am running an outdated firmware at a specific point in time, and learned how to frig the configuration process of my router to overcome an Asus bug. But this stops me progressing to the 388 code currently and also doesn't help others who hit the same issue and haven't worked out how to overcome it. My posted should assist someone researching the same issue themselves in the forums. I am not the only one

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.

My main router, along with other services, is centrally located in an unheated cellar which is below ground level. This is insulated to keep the occupied areas of the home warm. This is a necessity due to the design of my home which dates back to 1880 and the delivery of services such as internet and phone.

My main router is not needed to deliver any Wi-Fi connectivity except for IOT devices inside the cellar area. All connections to outside of this area are on Cat 5e switched ethernet. I have previously tried to disable WiFi on this router - if it is the master in AiMesh, the node WiFi connectivity falls apart very quickly as nodes need the main router to be active for DFS and it appears 2.4Ghz channel selection. I can also run AiMesh on one of my two "node" routers instead but this creates a single point of failure and trombones traffic on my ethernet so again not ideal. Now I have IOT devices in my cellar this is fine when using ethernet backhaul.

I have 2 x RT-AX86U nodes - each has Gb ethernet connectivity and their placement is better suited to the location of most devices. However unless I frig my configuration my WiFi clients still attempt to connect to the main router resulting is poor, unreliable and slow connectivity.

You have design issues.

Not at all - I am an IT Infrastructure Architect (formerly Engineer) of 30+ years experience. This has been designed.

You have trust issues

 

[brummygit]

I'm sick of this. Same crap with this "Wifi is completely broken in 388.1, go back to a 6 months old version" mantra when there are also a significant (i.e. higher than 1) number of people here and beyond this forum who have it working fine, or who fixed their issue by using the settings I have been recommending for years, which is to use a fixed channel on a non-DFS band if you experience stability issues. The 386.7_2 feedback on this specific model was also that it was working fine following the driver update that I applied after the 386.7 release, which did have issues.

Enough. I'm done dealing with this.

As @kernol stated, I believe there is no issue for you to fix. I have been trying to present testing results that demonstrate that Asus have an issue with their RT-AX86U code/drivers in specific use cases. For some the router will perform very well, but in some cases it won't.

Thank you for your hard work.