Release ASUS ZenWiFi XT8 Firmware version 3.0.0.4.386.46061 (2022/01/14)

[karma]

If you log into the router, go to administration--> restore/save/upload settings, you should be able to save and upload them later. Never tried this yet, so maybe someone else can confirm. Did notice this later on.

afaik that hasn't been recommended when moving from one firmware to another since it will apply all the settings as well as old crap from the previous firmware.

 

[Ironlake]

afaik that hasn't been recommended when moving from one firmware to another since it will apply all the settings as well as old crap from the previous firmware.

You gave me an idea. I saved the settings and reflashed the node from 42095 again to 46061 and only on the node did not do any wps reset. The plan was to upload the settings from the old config of main device 46061 and node 42095. But I did not do a reset so I think it should be the same. Anyhow, been gaming now for 1 hour no disconnection on any LAN client. Monitoring the logs as well, no unnecessary timeouts detected. Is too soon to say, but looks stable. This is weird. The wps reset was needed in the beginning with the main device for stability. Zero disconnection so far. One more detail, this time I downloaded the firmware 46061 from the router page instead of manual upload (this is valid only for the node). This should not be relevant because the file supposed to be the same. Anyways, just experimenting here. I will keep testing. I will report back any unplanned timeouts.

Main device now fw 46061
Node fw 46061 wireless backhaul LAN 1 and LAn2 in use.

 

[IcerJo]

I updated to this Firmware on Monday, was Solid for a little under 2 days. Not sure if my Issue was related to some Professional Changes I made or if it was the firmware itself, my System crashed/rebooted twice in the span of 5 hours last night while I was sleep. I reverted back to the November build which had/has been solid for me. I Manually reboot when I have issues, which is rare, so reboots for me are usually months apart unless there is a power outage/blip in my area.

 

[CPngN]

I run a single XT8, and 46061 was a disaster for me. My Remote Desktop connection dropped twice in the first hour, when it had been stable for weeks between PC reboots on 45898. I also have a couple of mapped network drives, and simply opening Windows Explorer to "This PC" took 10+ seconds the first time in both my main machine and a VM I run on it. Restoring 45898 restored normalcy. WRT to dropping Remote Desktop, 46061 reminds me of when I was running two XT8's in mesh back in June 2021, with the remote computer wired to the mesh node, except it was even worse. Again, I'm only running a single XT8 now. I am using the second 5 GHz channel in AX mode and the 160 MHz channel for my remote PC, and I didn't bother doing any troubleshooting. I just moved back to 45898, which has been rock solid for months.

ETA: After reinstalling 46061 a second time and observing the same delays and more, as detailed in a follow-up post, power-cycling the router seems to have cleared it all up. Going on six hours without issue so far.

Did you wipe and re-setup or just dirty flash (ie: normal upgrade)? I was on the RC2 and RC3 for my ET8 and they were great, now I'm back to this new build (for ET8). I'm thinking I should probably clear and re-setup to wipe out any cruft since they store and restore values in a strange way. My TV disconnected 3 times last night, so so-far this new non-beta release is no better than the previous for me.

 

[crawfish]

Did you wipe and re-setup or just dirty flash (ie: normal upgrade)? I was on the RC2 and RC3 for my ET8 and they were great, now I'm back to this new build (for ET8). I'm thinking I should probably clear and re-setup to wipe out any cruft since they store and restore values in a strange way. My TV disconnected 3 times last night, so so-far this new non-beta release is no better than the previous for me.

No, but I did power-cycle the router after applying the firmware the second time, and that cleared up the weird delays I was observing in Windows programs like Explorer and Outlook. No issues in two days, except I have two Lenovo google smart clocks that continue to litter the log with entries as below, but they were doing this with earlier firmware. Note that I'm running only one XT8 and no AIMesh.

Jan 19 10:04:00 wlceventd: wlceventd_proc_event(491): eth4: Deauth_ind xx:xx:xx:xx:xx:xx, status: 0, reason: Deauthenticated because sending station is leaving (or has left) IBSS or ESS (3), rssi:0
Jan 19 10:04:06 wlceventd: wlceventd_proc_event(527): eth4: Auth xx:xx:xx:xx:xx:xx, status: Successful (0), rssi:0
Jan 19 10:04:06 wlceventd: wlceventd_proc_event(556): eth4: Assoc xx:xx:xx:xx:xx:xx, status: Successful (0), rssi:-51

They do this several times an hour. I've tried all the troubleshooting I found on the web by googling the first line, and I've moved them from 5 to 2.4 GHz as well. Nothing helps. I'm getting tired of these clocks anyway, because the auto-dim is essential, and it's too damn dark most of the time. Stepping in front of them can make them too dim to read, and adjusting the brightness turns off auto-brightness.

 

[bradbort]

No, but I did power-cycle the router after applying the firmware the second time, and that cleared up the weird delays I was observing in Windows programs like Explorer and Outlook. No issues in two days, except I have two Lenovo google smart clocks that continue to litter the log with entries as below, but they were doing this with earlier firmware. Note that I'm running only one XT8 and no AIMesh.

Jan 19 10:04:00 wlceventd: wlceventd_proc_event(491): eth4: Deauth_ind xx:xx:xx:xx:xx:xx, status: 0, reason: Deauthenticated because sending station is leaving (or has left) IBSS or ESS (3), rssi:0
Jan 19 10:04:06 wlceventd: wlceventd_proc_event(527): eth4: Auth xx:xx:xx:xx:xx:xx, status: Successful (0), rssi:0
Jan 19 10:04:06 wlceventd: wlceventd_proc_event(556): eth4: Assoc xx:xx:xx:xx:xx:xx, status: Successful (0), rssi:-51

They do this several times an hour. I've tried all the troubleshooting I found on the web by googling the first line, and I've moved them from 5 to 2.4 GHz as well. Nothing helps. I'm getting tired of these clocks anyway, because the auto-dim is essential, and it's too damn dark most of the time. Stepping in front of them can make them too dim to read, and adjusting the brightness turns off auto-brightness.

I'm seeing the same ethernet log issues for eth 4 and 5, but it does not seem to have any effect on my actual network. Nothing is dropping. I wonder if it is a bug in the debug code

 

[bradbort]

It might be a good idea if those people having issues send feedback to Asus via the router (administration -> feedback) before downgrading.

I'm currently giving 46061 a go, I'm in AP mode with wireless backhaul and haven't noticed any issues.. we'll see.. i also have some settings disabled on all bands like WiFi Agile Multiband, Target Wake Time....

i'll usually know after a week or so if things are ok for my set up because other than 42095 a couple of clients will lose their connection...

Good idea. I just gave ASUS feedback that way about the weird log messages saying ethernet ports are disassociating and reassociating. I'm not noticing any network related instability though.

 

[Saveliy410]

For me, the only issue stopping me from using anything above 42095 still exists in 46061. Wireless backhaul traffic loss each GTK re-keying interval Tested with and without full reset after upgrade.

That's good that at least we have beta firmware (9.0.0.4.386_57317) which doesn't have the issue.

 

[RogerSC]

I'm using the XT8 in router mode and my Tablo is working great.

Well, decided it was time, so finally tried using WPS button resets instead of using "reset" button. Now everything looks good, including the Tablo. And the DoT DNS "Preset servers" list is back as well. So I guess that the reset button wasn't doing a complete reset...live and learn *smile*.

We'll see if it holds up, but things are looking a lot better at this point than they did when I first tried this firmware.

 

[PeterZ]

For me, the only issue stopping me from using anything above 42095 still exists in 46061. Wireless backhaul traffic loss each GTK re-keying interval Tested with and without full reset after upgrade.

That's good that at least we have beta firmware (9.0.0.4.386_57317) which doesn't have the issue.

where can I download the beta firmware?

 

[Thirteen]

kernel: wl0: set timeout 5 secs to wait dev reg finish
kernel: Flushing net_device wds0.0.1.

That's the same message I was getting back in May on 43169 when the node was restarting every couple of minutes.

 

[PeterZ]

Well, decided it was time, so finally tried using WPS button resets instead of using "reset" button. Now everything looks good, including the Tablo. And the DoT DNS "Preset servers" list is back as well. So I guess that the reset button wasn't doing a complete reset...live and learn *smile*.

We'll see if it holds up, but things are looking a lot better at this point than they did when I first tried this firmware.

Hmm... I did the WPS reset as well, but I don't see DNS presets, what am I missing?

 

[Ironlake]

That's the same message I was getting back in May on 43169 when the node was restarting every couple of minutes.

I can confirm that after my last post, I have not received any timeout messages. Regarding the assoc and deassoc messages, I see them most of the time after a "client weak signal strength" "remove client" message. Probably the client is reconnecting to another node while moving with the device around in the house. So this should be "normal", it is the device doing its work. Saw these same messages after leaving the house with my phone linked to my phones mac adress as well and after switching from one node to the other. So basically when I walked out of the living room, then connected to the other node (weak signal strenghth from the previous one) then again while going outside. So got a whole list of deassoc and assoc linked to my phone mac adress for this scenario.

I did some testing yesterday while gaming, it was not flawless. No time anymore to test this thorougly again. The other LAN device which is a server has not generated any disconnection logs. The fact I don't see the timeout message should be an improvement. But had a disconnection after 1 hour of gaming, normally happens faster. And with the 42095, I was playing onine before that without any event. I will keep both devices on the 46061 fw for now and monitor for now.

Check if you see any excessive timeout messages in the log, if experiencing problems. For now, my problems were linked to the node with wireless backhaul. Never tried ethernet backhaul.

 

[RogerSC]

where can I download the beta firmware?

From the first sticky thread in this forum (Asuswrt - Official), on the Asus Beta RC3-3 firmware:

https://drive.google.com/drive/folders/1zbP67c9LM-je_w3PEc36ybc_VFddJPPe?usp=sharing

 

[Bobdobolina]

Lessons this far:
+ Cache speed for streaming services (NF, YT, HBO etc) greatly improved over 45934.
= UP/DWN speed, jitter and latency as on 45934.
- System crashes daily w reboot + optimization causing everything to drop. Logs state "acsd: eth4 received event: tx pkt delay suddently jump" before crash. Seen other have had the issue in the past.
- Cisco VPN client (outbound tunnel), connected via Guest network, disconnects during Teams-calls unless QoS is enabled.
- Kicks 5GHz VPN client, connected via Guest network, off 5Ghz-1 onto 2.4. -57db when client is dropped to 2.4.

Issue logged w Asus.

Have tried to reapply the FW + power toggle w/o success. Will revert to 45934 through factory reset.

 

[Daylight_Invader]

Initially did a dirty upgrade which I really should have thought twice about as I was already having so many mDNS issues after my last dirty upgrade. Those of you how want to use the auto-upgrade firmware feature really should think twice before enabling this as Asus simply don't have this side of things sorted.

So far this is looking half decent as a new firmware, but WPS method and then manual setup appears the only way to make things stable. In my case stability for IoT on 2.4 is critical so I am also forced to switch off most of the magic in 'Professional' in order to make sure my IoT devices don't disassociate.

 

[kildare]

I noticed that there are 2 different 42095 firmware files:

the original one downloaded from Asus web site just the day it was released, which has the file name
ZENWIFI_XT8_3.0.0.4_386_42095-gcd938f7_cferom_pureubi.w
with filedate February 13 2021

and the currently downloadable file from the Asus web site which has the filename:
FW_ZENWIFI_XT8_300438642095.w
with filedate August 5 2021

These 2 files don't have the same binary content!

Which one are/were you using?

 

[Daylight_Invader]

I personally initially did a dirty update so the file that was downloaded was via the updater tool. That said, I reverted to WPS reset method when mDNS issues continued to appear. Reverting solved those issues which for IoT is important in our house.

I can only see one firmware file listed on the Asus site for the 14th of Jan 2022, so I am not sure how you are seeing multiple files, and dates that correspond to many months ago. Whilst it's not unusual for a file to have a date of a month or two before a release, Feb and August 2021 simply don't make much sense. Are you looking via their FTP site or via the website (I go via the website or via the updater tool)?

 

[kildare]

I'm actually referring to the old v. 42095 firmware file, the one that apparently is the most reliable XT8 firmware till today.

 

[Ironlake]

I noticed that there are 2 different 42095 firmware files:

the original one downloaded from Asus web site just the day it was released, which has the file name
ZENWIFI_XT8_3.0.0.4_386_42095-gcd938f7_cferom_pureubi.w
with filedate February 13 2021

and the currently downloadable file from the Asus web site which has the filename:
FW_ZENWIFI_XT8_300438642095.w
with filedate August 5 2021

These 2 files don't have the same binary content!

Which one are/were you using?

In my case during testing I used the one from asus website regarding 42095. No issues found with this one from the website, that was a few days ago.

Update: Still monitoring logs for both devices on 46061, no timeouts detected. And no complaints about internet from the family. For me the ultimate test will be playing online, but no time for that these days. So for now no specials to report. I checked the logs every day now to see what is happening just for this. I will keep monitoring the situation.