Beta RT-AX88U 9.0.0.4.386.41994

[nvarga]

https://dlcdnets.asus.com/pub/ASUS/wireless/RT-AX88U/FW_RT-AX88U_900438641994.zip

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]

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]

Please be noted this is a quick fix beta version for DNSmasq vulnerabilities.

I tend to accept what is communicated unless proven otherwise.

 

[brummygit]

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]

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]

@neil0311 care to compare your results to after a full reset is performed?

 

[neil0311]

@neil0311 care to compare your results to after a full reset is performed?

Can’t take that kind of downtime right now, but will probably do a reset when the next release comes out.

 

[NSNE]

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]

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]

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]

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]

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]

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

 

[NSNE]

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.

 

[dosborne]

When it boots the router needs to set its time and it does this by resolving the time server via upstream DNS.

I use ip addresses instead to avoid this being an issue.

 

[Gregory Phillips]

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.

 

[bpwats]

Is AirPrint working for you guys on this firmware?

 

[ryan806]

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

 

[neil0311]

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]

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