Release ASUS RT-AX86 Series(RT-AX86U/RT-AX86S) Firmware version 3.0.0.4.388.20566

[Robinbb]

Is that what you had set it to before the update?
Default is 20 minutes.

Quite frankly, I don’t know! I had only just bought the router the day before the current release….and had only just set it up with the beta. The only settings that I had touched were the user and provider login, plus the wifi. It was a clean slate setup.

 

[kernol]

And as before…I’m not the only one experiencing it, and back reving firmware fixes the problem.

Glad you’re not having the issue, but please stop gaslighting me. There is a problem that can be reproduced at will, and is not confined to my router.

Anyone else have actual feedback???

This issue has been debated a LOT on these forums as I'm sure you are aware. Don't want to hijack this thread - but it is relevant in determining whether the wireless drivers in Version 3.0.0.4.388.20566 behave as per stock firmware Version 3.0.0.4.386.46061 for the RT-AX86U [drivers Jan 25 2022 01:00:37 version 17.10.157.2803] [included in Merlinware 386.5.2] or behave as per the newer drivers embedded in stock Version 3.0.0.4.386.49599 released July 2022 [included in Merlinware 386.7.2]. These are the 388.20566 drivers ...

My own view on the matter is that the Jan 25 2022 drivers [and probably all the ones prior to that date] were likely NOT behaving correctly when it comes to 160MHz. Clients were able to hold on to their 160MHz connections while other less capable clients connected at 80MHz. At no stage were the 160MHz clients forced down to 80MHz. This is why I reverted to Merlinware 386.5.2 which has the Jan 2022 drivers.

That said - a review of the WLAN Channels listed on Wikipedia [which may not be up to date?] - for my region [South Africa] - clearly shows that not a single grouping of channels can provide a clear path to uninterrupted / stable 160MHz - without tripping over DFS or other issues. See enclosed shortened version of the wiki page.

So the more recent WiFi drivers [from July 2022] have, I believe, been brought into stricter compliance with available spectrum in the various geographic regions. I have replicated @bbunge 's wifi settings as best I can but [with all drivers from July 2022 onwards] get kicked down to 80MHz within 24 hrs every time [and probably rightly so .]

 

[Tech9]

I also believe DFS range use was fixed in later firmware updates, not broken.

 

[bbunge]

Guest network, WPA2, intranet access disabled.

PFFT posted (in a few posts) info about this here:

DNS over TLS support

My Wyze doorbell camera will not connect to the internet if my router is setup to use DNS over TLS (DoT). Please add support to the Wyze doorbell camera for DoT

forums.wyzecam.com

some of what he posted




click that link to that thread on Wyze's forum above for more

There is a work around if you want most of your clients to use DoT:
Under LAN - DHCP Server - Manually Assigned IP around the DHCP list - add the problem clients to this list and give them a specific DNS Server.
For this to work the clients will have to be on the main LAN or Guest network 2 or 3.
I just tested this with my DoT set to Cloudflare and the client tested, a Pi4, with a manually assigned IP address and Google DNS. DNS Leak Test sites showed the Pi using Google DNS. The rest of my LAN use the router, and its DoT, as a DNS server.

 

[neil0311]

My own view on the matter is that the Jan 25 2022 drivers [and probably all the ones prior to that date] were likely NOT behaving correctly when it comes to 160MHz. Clients were able to hold on to their 160MHz connections while other less capable clients connected at 80MHz. At no stage were the 160MHz clients forced down to 80MHz. This is why I reverted to Merlinware 386.5.2 which has the Jan 2022 drivers.

That said - a review of the WLAN Channels listed on Wikipedia [which may not be up to date?] - for my region [South Africa] - clearly shows that not a single grouping of channels can provide a clear path to uninterrupted / stable 160MHz - without tripping over DFS or other issues. See enclosed shortened version of the wiki page.

So the more recent WiFi drivers [from July 2022] have, I believe, been brought into stricter compliance with available spectrum in the various geographic regions. I have replicated @bbunge 's wifi settings as best I can but [with all drivers from July 2022 onwards] get kicked down to 80MHz within 24 hrs every time [and probably rightly so .]

I think we’re saying mostly the same thing. The firmware from Jan 2022 works. When set for 160MHz the router maintains 160MHz. Newer firmware (with the newer driver) doesn’t.

If there was interference, then 160MHz shouldn’t be allowed…period. But the newer versions allow it for a period. And if the router was merely dropping down to 80MHz when no WiFi 6 clients are connected, that would be fine.

But then when 160MHz capable clients connect, the router should upscale again to 160MHz. That has not worked for me since the Jan version which I’m on now. Once the router drops to 80MHz it never goes back to 160MHz. And I do not live near an airport or a missile silo or any other direct source of radar interference.

 

[DroidST]

There is a work around if you want most of your clients to use DoT:
Under LAN - DHCP Server - Manually Assigned IP around the DHCP list - add the problem clients to this list and give them a specific DNS Server.
For this to work the clients will have to be on the main LAN or Guest network 2 or 3.
I just tested this with my DoT set to Cloudflare and the client tested, a Pi4, with a manually assigned IP address and Google DNS. DNS Leak Test sites showed the Pi using Google DNS. The rest of my LAN use the router, and its DoT, as a DNS server.

Interesting... I'll look into this. Sounds a little like RMerlin's DNS Filter which was in use on my AC86U... EDIT: I never even bothered to see/pay attention to that DNS Server (Optional) field in the DHCP manual setting, and my AC86U had many manual assignments. I had been moving away from manually assigning on my AX86U but may have to add those problem devices if this works.

I think I've been out of the loop too long, found a f/w version that worked for a long time on my AC86U and AC68U hadn't been back until recently.

My Guest network(s) are setup in Guest Index 1. I do see on my AX86U, Guest Network 3 states Default setting by Alexa.

Apologies in advance, I didn't search the forum or the answer.
Besides the default settings for Alexa in 3, what makes Guest network 1 different from 2 and 3.

EDIT: Is this the only difference?

ASUSWRT 386 new guest network IP space and DHCP static IPs

We were talking about this in the RT-AC86U 386 firmware but saw people with RT-AC68U devices starting to have the same issue and wanted to pop it out into it's own thread. There is a new behavior with the 386 firmware that Guest Network 1 uses a different IP space from what you have defined on...

www.snbforums.com

Did you assign an IP address to your Pi4 in the same subnet of the router's IP address? eg. Router 192.168.1.1 - Pi4 192.168.1.86

 

[bbunge]

Interesting... I'll look into this. Sounds a little like RMerlin's DNS Filter which was in use on my AC86U... EDIT: I never even bothered to see/pay attention to that DNS Server (Optional) field in the DHCP manual setting, and my AC86U had many manual assignments. I had been moving away from manually assigning on my AX86U but may have to add those problem devices if this works.

I think I've been out of the loop too long, found a f/w version that worked for a long time on my AC86U and AC68U hadn't been back until recently.

My Guest network(s) are setup in Guest Index 1. I do see on my AX86U, Guest Network 3 states Default setting by Alexa.

Apologies in advance, I didn't search the forum or the answer.
Besides the default settings for Alexa in 3, what makes Guest network 1 different from 2 and 3.

EDIT: Is this the only difference?

ASUSWRT 386 new guest network IP space and DHCP static IPs

We were talking about this in the RT-AC86U 386 firmware but saw people with RT-AC68U devices starting to have the same issue and wanted to pop it out into it's own thread. There is a new behavior with the 386 firmware that Guest Network 1 uses a different IP space from what you have defined on...

www.snbforums.com

Did you assign an IP address to your Pi4 in the same subnet of the router's IP address? eg. Router 192.168.1.1 - Pi4 192.168.1.86

Guest network 1 on 2.4 GHz assigns 192.168.101.0/24 and 5 GHz assigns 192.168.102.0/24. This is to allow VLAN tagging to propagate the guest to AiMesh nodes. Trying to add a manual reservation to clients on Guest 1 will result in an error message.

Guest network 2 and 3 will use the same subnet as the LAN, 192.168.50/24 by default. These will not propagate to AiMesh nodes. My Pi was on the LAN subnet.

 

[DroidST]

Guest network 1 on 2.4 GHz assigns 192.168.101.0/24 and 5 GHz assigns 192.168.102.0/24. This is to allow VLAN tagging to propagate the guest to AiMesh nodes. Trying to add a manual reservation to clients on Guest 1 will result in an error message.

Guest network 2 and 3 will use the same subnet as the LAN, 192.168.50/24 by default. These will not propagate to AiMesh nodes. My Pi was on the LAN subnet.

So, if a client is on GN2 or GN3, do they still get restricted from the local network? I just want those clients to have WAN access.

This time around, I'm going to setup AiMesh nodes on the AC86U and AC68U and have the guess network on AiMesh (I guess it will be GN1 only clients). If GN2 and GN3 are still isolated from the local network, I'll setup another 2.4GHz SSID on GN2 for these Wyze devices with DoT issues.

 

[OzarkEdge]

This time around, I'm going to setup AiMesh nodes on the AC86U and AC68U and have the guess network on AiMesh (I guess it will be GN1 only clients). If GN2 and GN3 are still isolated from the local network, I'll setup another 2.4GHz SSID on GN2 for these Wyze devices with DoT issues.

This thread is for discussing the new AX86U firmware release. May I suggest that you start your own separate discussion for the issue you are having with your Wyze products, which you are currently spreading across multiple other threads/discussions.

OE

 

[BobbyFlobby]

This is the first firmware since the Merlins 386.5_2 that now seems to work nicely across devices and mesh.

 

[bbunge]

So, if a client is on GN2 or GN3, do they still get restricted from the local network? I just want those clients to have WAN access.

This time around, I'm going to setup AiMesh nodes on the AC86U and AC68U and have the guess network on AiMesh (I guess it will be GN1 only clients). If GN2 and GN3 are still isolated from the local network, I'll setup another 2.4GHz SSID on GN2 for these Wyze devices with DoT issues.

Guest 2 and 3 can have intranet access enabled.
However, AiMesh only uses guest 1 which means your troubled clients will not work off of an AiMesh node.

 

[Tech9]

I'm sorry Asus, but my router uses 2.5GbE port for WAN...
Another GUI error in this ugly ports map. It looks like copy/paste from another router GUI.

 

[Marcus Yansen]

I was wondering, with those of us on Merlin’s latest FW, it’ll be some time before it is updated to this version pending GPL release by Asus and such. Given that this official update has vulnerability fixes, unless we know we will be targeted, there is no reason to update to official version right? So one can wait until Merlin releases the update while remaining on current Merlin even though there is a vulnerability?

 

[Paliv]

I'm sorry Asus, but my router uses 2.5GbE port for WAN...
Another GUI error in this ugly ports map. It looks like copy/paste from another router GUI.

View attachment 44559

View attachment 44558

I noticed this same issue as well. Figured I just won’t look at that part of the GUI again.

 

[Tech9]

Given that this official update has vulnerability fixes, unless we know we will be targeted, there is no reason to update to official version right?

It depends on what Asuswrt-Merlin features do you need. If you run advanced VPN configuration or custom scripts, you have no choice but wait for the next Asuswrt-Merlin release.

 

[Tech9]

I noticed this same issue as well. Figured I just won’t look at that part of the GUI again.

It's very annoying indeed. You open the GUI for the first time and see a bug right away. Asus fixed the USB icons and missed the 2.5GbE port. Makes you wonder what else is missed there under the hood.

 

[bbunge]

It's very annoying indeed. You open the GUI for the first time and see a bug right away. Asus fixed the USB icons and missed the 2.5GbE port. Makes you wonder what else is missed there under the hood.

Well, they still seem to think there is something wrong with a 100 MB Ethernet connection. True, it is not 1 GB but there are still a lot of 100 MB devices out there which do not need to have to be "fixed" or warned about.

 

[Tech9]

One more GUI bug, Tx power slider misalignment. The same as in Beta:

 

[Marcus Yansen]

It depends on what Asuswrt-Merlin features do you need. If you run advanced VPN configuration or custom scripts, you have no choice but wait for the next Asuswrt-Merlin release.

Thanks @Tech9. I don't run any VPN configurations or custom scripts. Looking around at the vulnerabilities fixed (CVE-2018-1160, status page HTML vulnerability, cfg_server security issue) I guess maybe it's a good idea of update, although I probably won't get to it until next week or week after anyway.

 

[Tech9]

This 388 code base firmware contains almost everything else most folks used to install Asuswrt-Merlin for. There is VPN Fusion for simple selective routing, DDNS with external IP detection, more settings in WAN/LAN pages, DNS-over-TLS, even form of DNSFilter in App. Take a look and decide.