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

[capncybo]

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.

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):

Also, 160 wide requires DFS and this means the 5-Ghz channel must listen before transmitting.

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.

 

[Ripshod]

The way DFS should work for 160 is by immediately assigning an 80Mhz while the PRE-ISM Channel Availability Check runs a scan for an available 160Mhz space - this takes 10 minutes because radar is an intermittent signal. Once this check is finished a 160Mhz channel is set, only if there is space. No space no 160.
By users forcing 160 when it shouldn't be available they are very likely to suffer interference and poor performance and cause interference to other users.
By defeating DFS In Service Monitoring by forcing 160 you are defeating a function that enables a router to pass certification.
So either the drivers and hardware are faulty, or the drivers and hardware are doing what they need to do to get that certification in the first place.

 

[Log]

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.

my AX86U (Vietnam) has been acting flaky for 5 months after 18months of use since 2020 and I gave up last week and RMA'd it waiting for a return, had tried everything including 100's of resets, and other suggestions here. Merlin or equivalent 386.5 and 386.5_2 were the most stable in my tests. I don't utilize 160 MHz, AiMesh or any of Ai features, Gaming Features and even disabled VPN Servers but do have some IOT bulbs and older sockets. my doubt its 100% on FW and it will likely be reported in future but for now its a sucks going back to a backup AC87U and be vulnerable.

 

[RMerlin]

Check runs a scan for an available 160Mhz space - this takes 10 minutes because radar is an intermittent signal

The Pre-ISM scanning only takes 60 secs. After that, it goes into ISM mode, which means the channel is immediately fully available, but the router will actively monitor for any radar signal appearing, at which point it will vacate the channel for a given period of time (I forgot how long).

 

[capncybo]

@Ripshod I guess what I'm struggling with most is... (How something should work -VS- What is actually going on)
In my case the following still functions within my house (but according to everything I've read) wouldn't the LEFT portion of my 160MHz be in uncharted frequency territory???

 

[capncybo]

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

 

[capncybo]

The Pre-ISM scanning only takes 60 secs. After that, it goes into ISM mode, which means the channel is immediately fully available, but the router will actively monitor for any radar signal appearing, at which point it will vacate the channel for a given period of time (I forgot how long).

Thanks for the clarification @RMerlin & I'm fairly certain I read that it has to vacate for 30Mins

 

[Ripshod]

The Pre-ISM scanning only takes 60 secs. After that, it goes into ISM mode, which means the channel is immediately fully available, but the router will actively monitor for any radar signal appearing, at which point it will vacate the channel for a given period of time (I forgot how long).

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

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

 

[ColinTaylor]

The way DFS should work for 160 is by immediately assigning an 80Mhz while the PRE-ISM Channel Availability Check runs a scan...

This is incorrect.

 

[ColinTaylor]

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

That's because we're in the UK and we have to wait 10 minutes if the bandwidth includes the weather channels (120-128).

 

[Ripshod]

Okay, that's a uk thing then.
Under what circumstances would ISM be reported as "idle" when it's required for the correct control of dfs channels? If it's not doing anything it won't detect a change in the band and move the channel or switch 80/160?

 

[capncybo]

Okay, that's a uk thing then.
Under what circumstances would ISM be reported as "idle" when it's required for the correct control of dfs channels? If it's not doing anything it won't detect a change in the band and move the channel or switch 80/160?

Perhaps it displays "idle" after it gets booted from any detected radar, & stays as such until successfully completing a timeout condition?

 

[Ripshod]

I'm still learning, and this is all great info. Thanks everyone for tolerating me.
I'll only ever see DFS go Idle or my channel change if I move then - the beauty of the sticks.
I'll let this thread get back on track.

 

[ColinTaylor]

Under what circumstances would ISM be reported as "idle" ...

Never. "In-Service Monitoring(ISM)" is a state, "IDLE" is a different state. AFAIK the only time you'd see an IDLE state was when you weren't using DFS channels.

 

[capncybo]

Never. "In-Service Monitoring(ISM)" is a state, "IDLE" is a different state. AFAIK the only time you'd see an IDLE state was when you weren't using DFS channels.

Hence I'm at work (With My Pixel-7) so... my only AX-device is no-longer connected to my Home router.
I just connected (remotely) into our RT-AX86U via Open VPN
AND...

 

[capncybo]

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?

 

[ColinTaylor]

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?

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".

 

[Tech9]

but my initial conclusion is that we will need to wait for the latest code to be included in a future Merlin release

This was my final conclusion 2 weeks back.

 

[RMerlin]

Thanks for the clarification @RMerlin & I'm fairly certain I read that it has to vacate for 30Mins

I think that's correct, it's something around 30 minutes indeed.

Perhaps for EU/UK certification?

It's possible that it might be region-specific indeed. Here in North America it's 60 secs for the pre-scan.

 

[brummygit]

This was my final conclusion 2 weeks back.

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.