Release ASUS RT-AX86U Firmware version 3.0.0.4.386_49447 (2022/06/20)

[Paliv]

Interesting the folder name for the newer version is:

FW_RT_AX86U_AX86S_v300438649447.zip

Then it is zipped, possibly explaining the zip.zip

The folder name also has v in front of the firmware version 300438649447, which wasn't the case in the download on yesterdays file.

Also note windows shows the files size as 87,681KB for both. So it seems it is the same firmware with some odd file management occurring on the backend.

And as mentioned they have identical MD5 hashes, which match the website.

 

[dflaer]

The logging level in this firmware is high - too many messages: kernel: CONSOLE:, acsd: acs_candidate_score_txop, acsd: acs_candidate_score_busy, acsd: acs_candidate_score_intf and so on. If these are not bugs, then this level of logging is not acceptable for a release. What if it's all mistakes? Strange firmware...

 

[OzarkEdge]

Interesting the folder name for the newer version is:

FW_RT_AX86U_AX86S_v300438649447.zip

Then it is zipped, possibly explaining the zip.zip

The folder name also has v in front of the firmware version 300438649447, which wasn't the case in the download on yesterdays file.

Also note windows shows the files size as 87,681KB for both. So it seems it is the same firmware with some odd file management occurring on the backend.

And as mentioned they have identical MD5 hashes, which match the website.

They changed the zip name, the file name, and the date. Given they did not change the checksum, can we assume the firmware was not changed? I'm not going to bother uploading the 6/21 file until determined otherwise.

Maybe the 6/21 file turns down the logging that is in the 6/20 file(?).

OE

 

[Paliv]

They changed the zip name, the file name, and the date. Given they did not change the checksum, can we assume the firmware was not changed? I'm not going to bother uploading the 'new' file until determined otherwise.

OE

Only the folder name changed, the actual file name when unzipped is the same. I agree, checksum = is good in my book.

Edit: By the way the Firmware download page works again.

 

[RMinNJ]

The logging level in this firmware is high - too many messages: kernel: CONSOLE:, acsd: acs_candidate_score_txop, acsd: acs_candidate_score_busy, acsd: acs_candidate_score_intf and so on. If these are not bugs, then this level of logging is not acceptable for a release. What if it's all mistakes? Strange firmware...

Anyway to turn down the log level? I did not see a place.

 

[dflaer]

Anyway to turn down the log level? I did not see a place.

There is no such possibility in the official ASUS firmware.

 

[OzarkEdge]

Only the folder name changed, the actual file name when unzipped is the same. I agree, checksum = is good in my book.

Edit: By the way the Firmware download page works again.

Downloads from US site:

1/11 filespec: FW_RT_AX86U_300438646061.w
6/20 filespec: FW_RT_AX86U_AX86S_300438649447.w 89,784,340 bytes
6/21 filespec: FW_RT_AX86U_300438649447.w 89,784,340 bytes

Maybe it's all about the filename change.

OE

 

[Paliv]

Downloads from US site:

1/11 filespec: FW_RT_AX86U_300438646061.w
6/20 filespec: FW_RT_AX86U_AX86S_300438649447.w 89,784,340 bytes
6/21 filespec: FW_RT_AX86U_300438649447.w 89,784,340 bytes

Maybe it's all about the filespec change.

OE

Ah, the AX86S was taken out. Missed that, asleep at the wheel.

 

[OzarkEdge]

Ah, the AX86S was taken out. Missed that, asleep at the wheel.

So it now conforms to the 1/11 filenaming scheme. They must be human!

OE

 

[BobD]

I downloaded the original offering at 76.94GB and I always validate the file against the checksum and it was valid.
I just did the same against the zip.zip offering. It was also valid using the checksum from the original download. It looks like it was just a bit of finger trouble on the DL website.
All looks and runs OK here but I haven't yet checked the logging.
It's 0700 here in the middle of winter and I got things to do. I'll look later.

 

[KevTech]

Anyway to turn down the log level? I did not see a place.

Use putty or another terminal.
nvram set log_level=some number
nvram commit
Default level on stock is 6 so could try 5.

To check log level
nvram get log_level

 

[neil0311]

Just went back to 46061.

The new firmware 49447 would not do 160 MHz for AX. I’ve been using 160 MHz for years on my AX88U and for a month on the AX86U. There’s no issue at my house.

Suddenly the AX86U with the new firmware would only do 80MHz. 160MHz works fine on 46061.

 

[Tech9]

Uploading the custom_clientlist and dhcp_staticlist is a lot faster than typing them all in after a reset.

What about nvram get for both and then nvram set after reset? I agree WinSCP is easier, but there is a workaround.

 

[SAL9K]

Any speculations on why Asus chose to leave out Cloudflare from the new WAN DNS preset server list (still manually configurable to Cloudflare)? It's still a preset option for DNS-over-TLS (DoT), however.

 

[bbunge]

Just went back to 46061.

The new firmware 49447 would not do 160 MHz for AX. I’ve been using 160 MHz for years on my AX88U and for a month on the AX86U. There’s no issue at my house.

Suddenly the AX86U with the new firmware would only do 80MHz. 160MHz works fine on 46061.

160 MHz working fine here. I use Auto channel at 20, 40, 80, 160 MHz with use DFS channels enabled.
Most of the time the 5 GHz is at 80 MHz on channel 52 or 116. When a client that is 160 MHz capable (I have one AC and two AX) connects it will go to 160 MHz. With this new firmware is is more reliable than 46061.
I also use WPA2/WPA3-Personal.

 

[SAL9K]

160 MHz working fine here. I use Auto channel at 20, 40, 80, 160 MHz with use DFS channels enabled.
Most of the time the 5 GHz is at 80 MHz on channel 52 or 116. When a client that is 160 MHz capable (I have one AC and two AX) connects it will go to 160 MHz. With this new firmware is is more reliable than 46061.
I also use WPA2/WPA3-Personal.

ch44/160MHz auto-selected for me as well, at least for a little while before reverting down to 80MHz. Same config as @bbunge but without DFS control channels (Roku's don't work with DFS control channels).

After flashing this 49447 and hard-reset, I did notice the 160MHz was enabled by default; I thought that it was disabled by default on 46061(?). If so, maybe Asus's WiFi updates made it more reliable?

 

[KevTech]

What about nvram get for both and then nvram set after reset? I agree WinSCP is easier, but there is a workaround.

What I used to use before I started using WinSCP.
nvram set dhcp_staticlist
nvram set custom_clientlist
nvram commit

 

[Tech9]

dhcp_staticlist - OK
custom_clientlist - OK
custom_usericon - what about this one?

 

[neil0311]

160 MHz working fine here. I use Auto channel at 20, 40, 80, 160 MHz with use DFS channels enabled.
Most of the time the 5 GHz is at 80 MHz on channel 52 or 116. When a client that is 160 MHz capable (I have one AC and two AX) connects it will go to 160 MHz. With this new firmware is is more reliable than 46061.
I also use WPA2/WPA3-Personal.

I have channel bandwidth set at 160MHz with channel 36 as the control channel. Same config I used with my AX88U that worked for years, and then worked fine with the AX86U until updating to the new version today. Could not get the new one work.

Going back to 46061 brought back reliability. Maybe I can try a full reset after upgrade and see if that works. But not sure I need to at this point.

 

[bbunge]

I have channel bandwidth set at 160MHz with channel 36 as the control channel. Same config I used with my AX88U that worked for years, and then worked fine with the AX86U until updating to the new version today. Could not get the new one work.

Going back to 46061 brought back reliability. Maybe I can try a full reset after upgrade and see if that works. But not sure I need to at this point.

The router needs to clear for RADAR and that takes time. Try 20,40,80,160. It does wprk