Beta RT-AX88U 9.0.0.4.386.41994

  • ATTENTION! As of November 1, 2020, you are not able to reply to threads 6 months after the thread is opened if there are more than 500 posts in the thread.
    Threads will not be locked, so posts may still be edited by their authors.
    Just start a new thread on the topic to post if you get an error message when trying to reply to a thread.

nvarga

New Around Here

ASUS RT-AX88U Firmware version 9.0.0.4.386.41994 (Beta Version)
Security Fixed:
Fixed CVE-2020-25681, CVE-2020-25682, CVE-2020-25683, CVE-2020-25687, CVE-2020-25684, CVE-2020-25685, CVE-2020-25686

Please be noted this is a quick fix beta version for DNSmasq vulnerabilities. Refer to "Method 2: Update Manually" in https://www.asus.com/support/FAQ/1008000 to update this firmware.

Please unzip the firmware file first then check the MD5 code.
MD5: d5820a7b1eb43b2d7f049b44d5d584e5
 

neil0311

Senior Member
Does a “quick fix beta” mean that it addresses and targets those CVEs but the rest of the firmware is essentially unchanged from 41700?
 

L&LD

Part of the Furniture
Please be noted this is a quick fix beta version for DNSmasq vulnerabilities.

I tend to accept what is communicated unless proven otherwise. :)
 

brummygit

Very Senior Member
Does a “quick fix beta” mean that it addresses and targets those CVEs but the rest of the firmware is essentially unchanged from 41700?
Not necessarily - I think this means that it has been issued quickly as Asus consider the vulnerabilities to require immediate attention. There are already observations that some GUI icons are different from 386_41700, and anecdotal information that WIFI performance is improved on some models, so it appears that the fixes were applied to the current development version and issued as a beta.
 

neil0311

Senior Member
I updated to the beta and all seems OK so far. Only issue I’ve noticed is that 2.4GHz wifi speeds seem to be a lot slower. 5GHz was blazing to almost 1.2Gbps as normal.

My phone (ax client) typically gets around 150 Mbps with the 2.4 GHz network set to 20 MHz. Upload is usually close to the provisioned 35Mbps Internet upload speed.

After updating the firmware, my 2.4 downloads are topping out around 90Mbps, and uploads are struggling to hit 20Mbps. There are no issues with 5GHz clients getting full bandwidth, so can’t be the connection.
 

L&LD

Part of the Furniture
@neil0311 care to compare your results to after a full reset is performed?
 

NSNE

Regular Contributor
First performed a "dirty" upgrade to this beta over 3.0.0.4.386_41700 late last night. It was awful. Regardless of wired/wireless, DNS resolution took forever. Websites would load eventually but was getting DDNS and NTP errors left and right. Some clients (Sonos, etc.) couldn't seem to get a stable WAN connection at all. Thought it was my Pi-hole setup, but disabling that didn't help. Local connections were perfectly fine.

So I factory reset this morning. DNS resolution is faster, but upload/download speeds are appalling. I'm seeing 100Mbps down on a 1Gig connection, 10Mbps up where it should be 40.

Once the kids' distance learning sessions are done for the day, I'll try disabling WAN aggregation and LAG to see if it improves things. It's so bad, though, that I'm considering going back to the standard firmware, DNSmasq issues be damned.
 

neil0311

Senior Member
Looks like the 2.4GHz clients are seeing correct speeds now. So don’t know why they were slow this morning. Maybe just an unrelated correlation, or maybe something on the router that was temporary.
 

NSNE

Regular Contributor
Well, there seems to be something up with how the AX88U interacts with Pi-hole on this beta. Despite the factory reset, pointing the router's DNS server to that local IP address makes website resolution infuriatingly slow, even if Pi-hole is disabled. There were zero issues with the same configuration on 3.0.0.4.386_41700.

After pointing the AX88U's DNS settings to Cloudflare (1.1.1.3, 1.0.0.3 & their IPv6 counterparts) instead of automatic DNS assignment via Xfinity, upload and download speed tests are a little better with WAN aggregation still enabled. But I'm still looking at roughly half (500Mbps) of my expected and typical download speeds.
 

brentil

Occasional Visitor
Well, there seems to be something up with how the AX88U interacts with Pi-hole on this beta. Despite the factory reset, pointing the router's DNS server to that local IP address makes website resolution infuriatingly slow, even if Pi-hole is disabled. There were zero issues with the same configuration on 3.0.0.4.386_41700.

After pointing the AX88U's DNS settings to Cloudflare (1.1.1.3, 1.0.0.3 & their IPv6 counterparts) instead of automatic DNS assignment via Xfinity, upload and download speed tests are a little better with WAN aggregation still enabled. But I'm still looking at roughly half (500Mbps) of my expected and typical download speeds.
I'm having the same issue on an AC86U as well. I have dual PiHoles inside my network and both fail to make outbound DNS calls after updating to the beta, everything just came to a complete stop since they couldn't resolve any DNS. I had to shift to my ISP for DNS on the router itself and DHCP config to get everything back online to start figuring out what was going on.
 

bbunge

Very Senior Member
Well, there seems to be something up with how the AX88U interacts with Pi-hole on this beta. Despite the factory reset, pointing the router's DNS server to that local IP address makes website resolution infuriatingly slow, even if Pi-hole is disabled. There were zero issues with the same configuration on 3.0.0.4.386_41700.

After pointing the AX88U's DNS settings to Cloudflare (1.1.1.3, 1.0.0.3 & their IPv6 counterparts) instead of automatic DNS assignment via Xfinity, upload and download speed tests are a little better with WAN aggregation still enabled. But I'm still looking at roughly half (500Mbps) of my expected and typical download speeds.
The router should have the WAN - Internet Connection - DNS Server 1 and 2 set to an upstream resolver. Not a Pi-Hole inside the LAN. When it boots the router needs to set its time and it does this by resolving the time server via upstream DNS.
 

brentil

Occasional Visitor
From my testing there is clearly something else going wrong with DNS lookups than this upstream DNS configuration.
 

NSNE

Regular Contributor
The router should have the WAN - Internet Connection - DNS Server 1 and 2 set to an upstream resolver. Not a Pi-Hole inside the LAN. When it boots the router needs to set its time and it does this by resolving the time server via upstream DNS.
Theoretically, it should be perfectly fine to enter the local Pi-Hole IP in the router's WAN DNS settings. This is the recommended method in several guides. It's a bit heavy handed, but it means that static IP LAN clients will still have their DNS lookups passed through the Pi-Hole. The only drawback is that Pi-Hole only sees a single client (i.e., the router) because conditional IP forwarding won't work. As I mentioned, this config was working perfectly fine until the beta update.
 

Gregory Phillips

Senior Member
I'm glad that I found this thread before I updated my router. I think I"m going to wait and let you guys be the guinea pigs on this one.:p
 

neil0311

Senior Member
Debating if I should update to the beta, has anyone else found it ok?

I’ve had no issues. But I’m not using AIMesh, QoS, VPN, or any advanced features other than WAN aggregation, and that’s been working well.

I use WiFi on both spectrums with a mix of clients, with IPv6 and firewall. My use case is firewall/router.
 

Gregory Phillips

Senior Member
I updated just for the security fix and will report if I see any issues.
 

Latest threads

Sign Up For SNBForums Daily Digest

Get an update of what's new every day delivered to your mailbox. Sign up here!
Top