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

[Tech9]

but after a few minutes they migrate to the AP and dislike the mesh node.

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

but that means relying on roaming assistant

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

 

[chadleysutoff]

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.

 

[capncybo]

In my experience it takes about 11 seconds after the initial connection to switch from 80 to 160MHz. There's no need to wait for 60 seconds provided that the channels are still "cleared for radar".

Just to clarify for the group...
I think this statement is correct when there are at least (one or more) AX devices still connected.
But if you are the 1st AX-device to try & connect at 160MHz...
-the router will display:
DFS State: PRE-ISM Channel Availability Check (CAC)
-for 60 seconds
+
What appears to be the additional 11-seconds to switch from 80 to 160MHz

 

[capncybo]

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.

The consensus regarding the WiFi drops was...
-It's most likely occurring when the router switches channels.
If experiencing WiFi drops...
Manually assign a control channel
OR:
Lately, I tried Control Channel=Auto (BUT removed the check-mark) from:
__ Auto select channel including DFS channels

Note: I've been trying 160MHz while looking for issues, but it has been rather stable

 

[ColinTaylor]

Just to clarify for the group...
I think this statement is correct when there are at least (one or more) AX devices still connected.
But if you are the 1st AX-device to try & connect at 160MHz...
-the router will display:
DFS State: PRE-ISM Channel Availability Check (CAC)
-for 60 seconds
+
What appears to be the additional 11-seconds to switch from 80 to 160MHz

No, that's not what I was describing. I was replying to your speculation as to what will happen when you get home. Your experience may be different to mine so it will be interesting to see what you discover in your tests.

 

[capncybo]

No, that's not what I was describing. I was replying to your speculation as to what will happen when you get home. Your experience may be different to mine so it will be interesting to see what you discover in your tests.

OK... then, Let me try to rephrase it. I did return home &
During my recent testing, on my RT-AX86U with ONLY one AX-device (Pixel-7) about to reconnect...
the router's DFS State is originally...
DFS State: Idle
But after WiFi is enabled... (within 10 seconds)... The router changes into:
DFS State: PRE-ISM Channel Availability Check (CAC) for EXACTLY 60 seconds
And shortly afterward (about 5 seconds)... the router displays
DFS State: In-Service Monitoring (ISM) and the (Pixel-7) Streams finally become 2(ax) 160MHz

Note: My Regional/Location is Canada

 

[hancox]

This was my final conclusion 2 weeks back.

I'm even more specific.

Given both this set of issues, which seems concentrated towards the AX86U, and issues around QoS/flow cache, which is seemingly exclusive to the AX86U, I would avoid this router altogether, if given the choice, until ASUS fixes any of these issues.

 

[ColinTaylor]

OK... then, Let me try to rephrase it. I did return home &
During my recent testing, on my RT-AX86U with ONLY one AX-device (Pixel-7) about to reconnect...
the router's DFS State is originally...
DFS State: Idle
But after WiFi is enabled... (within 10 seconds)... The router changes into:
DFS State: PRE-ISM Channel Availability Check (CAC) for EXACTLY 60 seconds
And shortly afterward (about 5 seconds)... the router displays
DFS State: In-Service Monitoring (ISM) and the (Pixel-7) Streams finally become 2(ax) 160MHz

Note: My Regional/Location is Canada

Ah, OK. That makes more sense. In my experience the CAC only happens when the "Channel cleared for radar:" is currently "None".

 

[RMerlin]

For reference, here are the possible DFS states:

                        "IDLE",
                        "PRE-ISM Channel Availability Check(CAC)",
                        "In-Service Monitoring(ISM)",
                        "Channel Switching Announcement(CSA)",
                        "POST-ISM Channel Availability Check",
                        "PRE-ISM Ouf Of Channels(OOC)",
                        "POST-ISM Out Of Channels(OOC)"

 

[capncybo]

For reference, here are the possible DFS states:

                        "IDLE",
                        "PRE-ISM Channel Availability Check(CAC)",
                        "In-Service Monitoring(ISM)",
                        "Channel Switching Announcement(CSA)",
                        "POST-ISM Channel Availability Check",
                        "PRE-ISM Ouf Of Channels(OOC)",
                        "POST-ISM Out Of Channels(OOC)"

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!!!

 

[Morris]

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.

I also disable universal beam forming. The problem with it is that the AP sends a stronger signal to a client it can just hear and then the client has no way to improve the signal as it can't beam form back so we get a connection with way too many retries. This is not only bad for the client at the edge of reception, if the network is busy it can kill performance for all clients.

 

[Morris]

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.
View attachment 46542
Main Router:

View attachment 46543View attachment 46544

Mesh Node:
View attachment 46545 View attachment 46546

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

Your IOT devices are probably 2.4 GHz so they get about the same signal from both node and router. Furthermore, when the router comes up the nodes are not up so the IOT devices will go there and many will stick there are they will attempt to connect to the last known good AP

 

[Morris]

100% agree with @hancox & MOST of what @Morris suggested above rings true (Excellent networking tips BTW).
Morris's description of 160 wide channels is how I thought 160MHz should work & fairly consistent with almost everything I had researched & read.
Except after reading these forums & now, through my own testing... I'm questioning the portion (in bold):

I say this because...
Currently my RT-AX86U router's: Control Channel=Auto
BUT
__ Auto select channel including DFS channels
Is NOT Selected

Soooo am I not using 160MHz but instructing the router NOT to use DFS ???

Many times Last Night & this morning I could see my (newly purchased Pixel-7) stay connected to the Main RT-AX86U router @ 160MHz
I could see this in the wireless log + I was also using the WiFi-App.
On the same phone & I could see the Bandwidth/Frequencies-Used being double the width...
AND
When I walked closer to my older RT-AC68U Node...
I could see the Bandwidth/Frequencies-Used revert back (To Half the width [AKA 80MHz])

Note: I've disabled DFS deliberately as some of us have suspected the DFS portion is actually what is causing the most trouble.
To be honest...
I'm rather shocked the router is still working this well.
But I do not have a SECOND RT-AX86U to connect as a Node.
Perhaps the node functionality is actually contributing to the problems.

At least in North America, one can not use 160 wide without overlaying a DFS channel.

https://help.keenetic.com/hc/en-us/articles/360012060379-Available-channels-on-the-5-GHz-Wireless-network

When I first got my RT-AX86U, it would incorrectly retreat to channel 36/160 and my Intel clients would move to 2.4 GHz. This has been corrected.

 

[capncybo]

@Morris I laughed when you pointed out that WiFi was complicated because it definitely is... & there are so many different combinations of variables including all the different software & hardware.
IMO the biggest sin that I've seen with most Mesh is that, most no longer reduce the nodes TX power. (With AiMesh I think the same power is applied for all)
So... instead of having a neighbor with one "centralized" router sitting in the middle of their house & property...
People set out additional nodes (usually at full TX power) which are often @the (edge/perimeter) of their houses & property...
Net result= push out even more radio frequencies... further onto their neighbour's property.
And then we wonder why there is so much noise.

 

[Morris]

Or perhaps maybe what is most commonly misunderstood is...
We actually can have 160MHz wide AC = WiFi-5 without DFS
Perhaps it is the 160MHz wide AX = WiFi-6 that requires DFS
???
Man my Head Hurts, I need a Strong Drink...
Merry Christmas Everyone

PS... And despite these recent settings (being insanely greedy) & not technically wise from a networking interference standpoint.
It is still working... But not very neighborly, LOL

Not in North America

https://help.keenetic.com/hc/en-us/articles/360012060379-Available-channels-on-the-5-GHz-Wireless-network

 

[Morris]

@Morris I laughed when you pointed out that WiFi was complicated because it definitely is... & there are so many different combinations of variables including all the different software & hardware.
IMO the biggest sin that I've seen with most Mesh is that, most no longer reduce the nodes TX power. (With AiMesh I think the same power is applied for all)
So... instead of having a neighbor with one "centralized" router sitting in the middle of their house & property...
People set out additional nodes (usually at full TX power) which are often @the (edge/perimeter) of their houses & property...
Net result= push out even more radio frequencies... further onto their neighbour's property.
And then we wonder why there is so much noise.

My big issue with AI Mesh is that the nodes use the same channel as the router causing cross channel interference reducing throughput. That's going to hurt on a busy network

 

[Morris]

Maybe there's something interesting in my area but CAC is definitely taking 10 minutes for me

View attachment 46551

View attachment 46552

It's so repeatable I knew that first would be a great screenie. Perhaps for EU/UK certification?

In the US, the FCC wants 10 minutes

 

[Kingp1n]

This firmware doesn't hold some devices at 80MHz as well. I won't be sharing any observations in Asuswrt-Merlin release threads anymore though because I turn into the bad guy every time. Some of the releases I gave up testing on day one. Wi-Fi and AiMesh are core functions on Asus wireless routers.

@Tech9 from my own findings here....it seems this is ssue a carryover from the stock firmware & seems specific to a couple of model routers and you combine that with different setups from different environment/setups can get messy fast. The feedback from all users (using stock fw with issues) should definitely be going directly to Asus. I doubt this is being provided to them but I may be wrong. I don't think you're being called out as the "bad guy" but all testing provided by all is definitely helpful (for both stock & asuswrt-merlin). I hope you're not taking this too personal.

 

[Morris]

I am VERY-MUCH looking forward to seeing (if/when/how-quickly) my phone will re-establish a 160MHz connection when I arrive home after-work...
EDIT: if I'm understanding correctly & I can remember to TURN-OFF my WiFi or PUT my phone into airplane mode BEFORE I approach my house.
I would expect... (After re-connecting my phones WiFi)
A temporary 80MHz wide connection to become established on 5G... but (@-around) the 60second point...
The RT-AX86U should activate 160MHz for the Pixel-7 (if NO-Radar has been detected).

Correct?

if you phone sees a 160 wide advertisement, it is permitted to connect to it. It must monitor for radar and immediately move no matter what the AP dose. If the AP is on 36, then your phone could go to 36/80 or 2.4 GHz.

 

[capncybo]

@Tech9 Common bro play nice, It's X-Mas ;-) keeping all these facts straight is indeed VERY difficult to do & retaining all the info at all times... Forget about it.
Me... I'm a humble electronic engineering technologist who found employment working with healthcare devices.
But I definately DO NOT KNOW everything about electronics nor medical equipment.
+
I did want to go on record & say that I do think BOTH yourself & @kernol are correct in saying...
There does seem to be some-things wrong (Likely related to the closed source binaries/drivers)
But if I'm not being plagued by disconnects & issues...
I'd like to stay with the more recent firmware(s).