Release Asus ZenWiFi XT8 - New Firmware: 3.0.0.4.386_45898

[Lars]

My Asus zenwifi xt8 found new firmware today.

2021/10/06 55.65 MBytes
ASUS ZenWiFi AX (XT8) Firmware version 3.0.0.4.386.45898
- Improved system stability and fix GUI issue
- This version includes several vulnerability patches.
BusyBox
- CVE-2016-2148
- CVE-2016-6301
- CVE-2018- 1000517

cURL
- CVE-2020-8169
- CVE-2019-5481
- CVE-2019-5482
- CVE-2018-1000120
- CVE-2018- 1000300
- CVE-2018-16839

Lighttpd
- CVE-2018-19052

Linux
- CVE-2020-14305
- CVE-2020-25643
- CVE-2019-19052

lldpd
- CVE-2020-27827

Avahi
- CVE-2017-6519

hostapd
- CVE-2021-30004
- CVE-2019-16275

OpenVPN
- CVE-2020-11810
- CVE-2020-15078

wpa
- CVE-2021-30004
- CVE-2021-27803
- CVE-2019-11555
- CVE-2019-9499
- CVE-2019-9498
- CVE-2019-9497
- CVE-2019-9496
- CVE-2019-9495
- CVE-2019-9494
- CVE-2017-13086
- CVE-2017-13084
- CVE-2017-13082
- CVE-2016-4476
- CVE-2015-8041

- Fixed DoS vulnerability from spoofed sae authentication frame. Thanks to Efstratios Chatzoglou, University of the Aegean, Georgios Kambourakis, European Commission at the European Joint Research Centre, and Constantinos Kolias, University of Idaho.
- Fixed Stored XSS vulnerability.
- Fixed CVE-2021-41435, CVE-2021-41436.
Thanks to Efstratios Chatzoglou, University of the Aegean
Georgios Kambourakis, European Commission at the European Joint Research Centre
Constantinos Kolias, University of Idaho.
- Fixed Stack overflow vulnerability. Thanks to Jixing Wang (@chamd5) contribution.
- Fixed information disclosure vulnerability .Thanks to CataLpa from DBappSecurity Co.,Ltd Hatlab and 360 Alpha Lab contribution.

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

 

[s0x]

Hey Lars

Thank you for the heads-up!

https://dlcdnets.asus.com/pub/ASUS/wireless/ZenWiFi_XT8/FW_ZENWIFI_XT8_300438645898.zip

FW_ZENWIFI_XT8_300438645898.zip    MD5    FB4185925C88F55AA81A97327536FEA9
FW_ZENWIFI_XT8_300438645898.zip SHA-1 5DC4C2813628FFFCB496351CE412B824B82D9E87
FW_ZENWIFI_XT8_300438645898.zip SHA-256 14A886B051C87D5D23AB72EE9EC7B06A5B1ED4C4E4466DC4C4755DF36422E43D
FW_ZENWIFI_XT8_300438645898.zip    SHA-512    BE4D04960BEA19F54BC251EB040BCEFCF4945BB2C249F1B0AE2BA438CE19047B1D94F4D7211B57CEEF2F95668412C175776DDC5A4F39EC0EF6ADE437066C8313

FW_ZENWIFI_XT8_300438645898.w    MD5    95F2005A42B5FF93734352A9313B0757
FW_ZENWIFI_XT8_300438645898.w SHA-1 E29158A6BCDDB883866DBC8F3B0A6BD413B8DD02
FW_ZENWIFI_XT8_300438645898.w SHA-256 A86E06948E1E21E05CAEDF8F68A4D80DAC17A8C2D00A62F35B7DF36071C1CAEE
FW_ZENWIFI_XT8_300438645898.w SHA-512 2541C2D8909C9AB1FA1DA9A8A887B787712204DB528082B69BE7B9D2BD9C6515A9F8D86F7A63CA8F549F604F938BDDA35506634D66AEDBD021111CC737FB349E

 

[smaceda]

Installed it without issues for now...

 

[IcerJo]

Installed with no issues, and have noticed my RAM usage is lower than it used to be Sofar no issues or problems to report, uptime 4 hours and 30minutes.

 

[BrendonSF]

Installed here as well; so far so good.
Given the significant version number jump and the collective changelog amassed from other interim releases on other routers here, this seems to be a pretty major release. It also looks to jump from Asus WRT RC2 to RC3, as the option to automatically update firmware is now in there.

 

[Cheesehead]

installed as well.. still facing the issue on soem IoT devices not connecting - back to 2095

 

[RogerSC]

Installed tonight, may do a reset and reboot tomorrow...seems to be okay, but see this message, once so far, for a particular client;

"not mesh client, can't delete it"

Since the client that the message refers to is a mesh client (being a client of a mesh), this is a bit inscrutable. On the other hand, it's the only client that I have that's bound to a particular node...I'm inclined to ignore the message, since everything seems to be working, but I hate to see bogus messages.

Anyways, so far so good, it seems.

 

[BrendonSF]

installed as well.. still facing the issue on soem IoT devices not connecting - back to 2095

Curious if you can elaborate on this issue? I have a bunch of TP Link 2.4ghz IoT devices that are randomly disconnecting on the 2.4ghz channel. I've tried everything under the sun, including upgrading from an AX88U to the XT8, but the problem still exists.

 

[Cheesehead]

Curious if you can elaborate on this issue? I have a bunch of TP Link 2.4ghz IoT devices that are randomly disconnecting on the 2.4ghz channel. I've tried everything under the sun, including upgrading from an AX88U to the XT8, but the problem still exists.

I have a Hydrawise (Hunter) garden raon controler and soem garage door switches which fail to connect on all of the recent firmwares but on the 2095 release (the last where it worked) they connect without any problem. No specail setting done here.

 

[TMcC]

Curious if you can elaborate on this issue? I have a bunch of TP Link 2.4ghz IoT devices that are randomly disconnecting on the 2.4ghz channel. I've tried everything under the sun, including upgrading from an AX88U to the XT8, but the problem still exists.

Sorry if you’ve tried this but if not might be worth a go:

http://www.snbforums.com/threads/xt8-constant-disconnects.74905/post-715513

 

[RogerSC]

Also, I often see it recommended to put your IoT devices on an AP rather than on your main router. Then their peculiarities plague the AP instead of your main router *smile*. Seems to do the job for most.

 

[s0x]

Haven't yet upgrade, still on 43181, but regarding IoT devices (a dozen of Shelly's and other devices), I'm using the 1st Guest Network on 2.4GHz for them along with the below configurations.

I'll be upgrading and resetting all the 3 "nodes" (1 XT8 Router, 1 XT8 Node, 1 XD4 Node) on the weekend, and ideal or not, I'll be applying this configuration again (as in, configuring manually again, not importing configuration file).

Smart Connect: Triband
WIFI 6 mode: Enable
WiFi Agile Multiband: Enable
Target Wake Time: Disable
Authentication Method: WPA2-Personal
Protected Management Frames: Capable
Fixed channels for the 3 radios (CH4/40MHz, CH52/80MHz, CH100/160MHz)

Possible relevant configurations applied to the 2.4GHz radio:

Professional 2.4GHz:
Roaming Assistant: Disable
Modulation Scheme: Up to MCS 7
Airtime Fairness: Disable
OFDMA/MU-MIMO: Disable
Explicit Beamforming: Enable
Universal Beamforming: Disable

SmartConnect 2.4GHz:
STR:
Load Balance: No
RSSI: Greater -58dBm
PHY Rate Less: Disable
PHY Rate Greater: >110Mbps
VHT: All

STA SP:
RSSI: Greater -58dBm
PHY Rate LEss: Disable
PHY Rate Greater: >110Mbps
VHT: All

Also, I often see it recommended to put your IoT devices on an AP rather than on your main router. Then their peculiarities plague the AP instead of your main router *smile*. Seems to do the job for most.

On my end that probably wouldn't be feasible. Some of the IoT devices already have RRSI -70dBm most of the time, with the 3 nodes placed "around" the house. With only 1 AP (perhaps at the middle of the house) wouldn't be, probably, enough.

 

[allan_q]

Experiencing core dumps and reboots with this version. This was an upgrade from 3.0.0.4.386_43181.

kernel: Unable to handle kernel paging request at virtual address 00c00c5c
kernel: pgd = cfc64000
kernel: [00c00c5c] *pgd=00000000
kernel: Internal error: Oops: 80000005 [#1] PREEMPT SMP ARM
kernel: Modules linked in: ath3k init_addr(  (null) -   (null)), core_addr(bf157000 - bf157888)
kernel:  btusb init_addr(  (null) -   (null)), core_addr(bf260000 - bf263ff4)
kernel:  btintel init_addr(  (null) -   (null)), core_addr(bf005000 - bf005198)
kernel:  usblp init_addr(  (null) -   (null)), core_addr(bf13d000 - bf13ed50)
...

 

[RogerSC]

Experiencing core dumps and reboots with this version. This was an upgrade from 3.0.0.4.386_43181.

kernel: Unable to handle kernel paging request at virtual address 00c00c5c
kernel: pgd = cfc64000
kernel: [00c00c5c] *pgd=00000000
kernel: Internal error: Oops: 80000005 [#1] PREEMPT SMP ARM
kernel: Modules linked in: ath3k init_addr(  (null) -   (null)), core_addr(bf157000 - bf157888)
kernel:  btusb init_addr(  (null) -   (null)), core_addr(bf260000 - bf263ff4)
kernel:  btintel init_addr(  (null) -   (null)), core_addr(bf005000 - bf005198)
kernel:  usblp init_addr(  (null) -   (null)), core_addr(bf13d000 - bf13ed50)
...

Did you try a factory reset to defaults after flashing? I'd be apt to try the flash again, do a factory reset, and manually re-configure my ZenWiFi if I experienced this. Also do a power-cycle a while after manually reconfiguring.

 

[in2ndo]

Upgraded my XT8 today. One router, one node. Seems it all went well. And it appears to be using less ram. Went from 75% to 64%. Let’s see how it continues.

 

[gz2021]

XT8 3 pack in Access Point(AP) mode / AiMesh Router in AP mode, upgraded this afternoon.

Main wired access point is showing a red light

Both wireless nodes show white lights.

Internet is working and clients are talking so other than the red light things seem to be working fine.

I noticed that the 5 ghz-2 (wireless backbone) has seem to set the same wireless password as my 2.4 ghz/5ghz network. I have seen this before with previous upgrades. Gonna do a factory reset tomorrow (keeping the above firmware) when the SO is out of the house.

 

[IcerJo]

Upgraded my XT8 today. One router, one node. Seems it all went well. And it appears to be using less ram. Went from 75% to 64%. Let’s see how it continues.

I'm 4 Days in and It stays between 66% and 68% no issues or problems that I have noticed or seen.

 

[Dodgydrains]

I have 4x XT8 with what I would describe as basic setup. Each nodes connected via 5GHz-2 wireless backhaul. Currently have 51% RAM usage with 252MB free.

The only additional feature enabled is timed parental control on few devices. 51% RAM usage is the lowest I have had compared with previous firmware with the same setup.

 

[Raven76]

Before installing... Someone of you has still the backhaul disconnection (from 5Ghz to 2.4Ghz) as with the 43183 firmware?!

 

[s0x]

So, after upgrade and NVRAM reset on all 3 (2 XT8, 1 XD4) and reconfiguration:

- WAN detection not working
- NTP time sync not working, possibly due to not detecting that WAN is online and therefore not launching the NTP daemon (Internet works fine tho, both IPv4 and IPv6)
- 1st Guest network on 2.4GHz (192.168.101.0/24 network): can't talk with devices connected to main node on this network but devices connected on the other nodes can be "talked to" from the main network (192.168.50.0/24), it used to be possible to "talk to" devices on this guest network from the main one (hence why I've been using this one for the IoT, so they can be isolated but could be controlled from the main one)
- Memory usage is lower ~50% (after 9 hours), used to be closer to 70% (AiProtection disabled)
- LAN side IP addresses on WAN DNS are working again