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

[happyshow]

Well, sorry to say that this new firmware doesn't play well with my Tablo DVR with the ZenWiFi in router mode. However, kept this firmware version and switched the ZenWiFi to AP mode. Using an RT-AX86U on latest RMerlin firmware as wired-only, main router, makes the Tablo happy and works fine with the ZenWifi in AP mode.

I'd love to find a replacement for the Tablo DVR that works as well. However, the only one that I've found, the HDhomerun, has other problems related to Silicon Dust's terrible HD apps, and the expensive Channels app that it needs due to the fact that the HD apps have such a bad user interface.

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

 

[mregister]

I have dirty flashed every firmware update to my mesh system since January 2021. No noticeable issues until this one. I have about 30 clients connected at any given time, the only one I noticed issues on is a Toshiba Fire TV which started having WiFi connectivity issues. I factory reset the TV and every time I initially connected to WiFi during the setup process it would almost immediately disconnect, and most times would result in my mesh system either rebooting or temporarily knocking everything off the network for about a minute. After a hard reset, everything seems to be good to go.

 

[garysteel]

updated from 42095 (have two xt8's backhaul hardwired) If I note anything odd will post. Had no issues updating, I updated from 42095 to offered update that everyone hates and then manually updated each unit to 46061.

G

So far no drama, (i didn't factory reset either upgrading from 42095) - with the ethernet backhaul I noted someone saying they disapled 160GHz - should I do this if using the wired backhaul and what does it give me?

Thanks
G

 

[OzarkEdge]

So far no drama, (i didn't factory reset either upgrading from 42095) - with the ethernet backhaul I noted someone saying they disapled 160GHz - should I do this if using the wired backhaul and what does it give me?

Thanks
G

Bandwidth is the 'capacity' of the WiFi connection... wider is a bigger 'pipe' in time. When I set 5.0 20/40/80/160 MHz bandwidth, my one AX client only connects at 80 MHz; when I set 160 MHz, my AX client connects at 160 MHz bandwidth... and the other AC/5.0 clients connect at their max supported bandwidth. So, I set the 5.0 bandwidth to 160 MHz and it automatically falls back for lessor bandwidth clients.

OE

 

[Ironlake]

Update: While playing a shooter game online connected to the node via wired connection. I get a total internet disconnection of less than 1 minute. Enough to kick me off the game. Quite annoying. Happens after 30 minutes today. I don't have this problem with 42095. I will try to see if I can do something to fix this, but does not look nice. This is one of the reasons I always end up flashing back.

 

[DaffyDuck]

Started from 42095, updated manually to 46061 both nodes. First couple hours flawless, then I started losing connection 1-2x every 10 minutes. Power-cycled both nodes, but did nothing to improve the situation. I then reset it all, the WPS way, and reconfigured the whole thing. Alas, while the system is more stable for me than any other version higher than 42095, it still breaks up sometimes without any evident pattern.

 

[Ironlake]

Update: REflashed the Node back to 42095. Tired of constant disconnections connected via wireless backhaul to wired connection via Lan ports. As stated before never had this problem with 42095. I will keep the main AP at 46061 for now and see what happens. Don't know if this will cause more problems running two devices on two different firmware. Will test it and post back. Only experienced problems on the node connections.

I wonder if a wired backhaul causes same problems, but for my current setup it does not make sense to use a wired backhaul. So would be nice if you can state as well if your node is on wired or wireless backhaul.

 

[bradbort]

Update: REflashed the Node back to 42095. Tired of constant disconnections connected via wireless backhaul to wired connection via Lan ports. As stated before never had this problem with 42095. I will keep the main AP at 46061 for now and see what happens. Don't know if this will cause more problems running two devices on two different firmware. Will test it and post back. Only experienced problems on the node connections.

I wonder if a wired backhaul causes same problems, but for my current setup it does not make sense to use a wired backhaul. So would be nice if you can state as well if your node is on wired or wireless backhaul.

I have wired backhaul, and am not having issues with a NAS I have hardwired to the node. I've been updated for a couple of days now, and it seem stable for me.

 

[Ironlake]

Can you detect with your NAS system logs any disconnection of less than 1 minute? So, are you 100% sure that there were no disconnections.

 

[bradbort]

Can you detect with your NAS system logs any disconnection of less than 1 minute? So, are you 100% sure that there were no disconnections.

Well that is interesting. I definitely can access the NAS whenever I want, no problem, but when I check the log file there are a bunch of dissacciation and association messages for ethernet port 6 and 4. I had not paid much attention to them, because I was not experiencing any issues in practice. I'm attaching a screen shot of the file. I believe ethernet 6 might be the NAS (its the last ethernet port on the node). I have no idea what 4 is.


Let me know what it looks like to you.

 

[Ironlake]

To be honest I am not sure you can relate this to a disconnection. In my case I read some of the logs of my server itself and saw that it disconnected. Furthermore my desktop itself was disconnecting as well, so basically no Youtube videos able to stream or disconnected from my online gaming. Maybe someone else can interpret this info better for you. You might want to check the log of your server itself, this short disconnection is hard to detect, but if you are doing something like playing a game which needs a constant ping, 1 short disconnection already kicks you out. When that happens I minimize the game fast and notice that my web browser is not working as well. Then on my server I see that there was a short disconnection and it reconnected. No local network access for a few seconds during this, so total short network connection loss.

Right now with the node at 42095 and the main device at 46061 no issues yet. Probably you have more stability with a wired backhaul, so don't worry much about it. Or you can try playing an online game on this node like I did and see if you can play for at least 45 min with no disconnection. Always the best test in my case. Instant disconnection if it is not stable.

I am curious what would have happened if I connected everything on the node only to wifi, but in my case not practicable because my server is wired. And it works with 42095.

 

[bradbort]

Thanks. I’m not a gamer, and don’t have a server, just the router/node giving access to my network clients. I have not seen any video/YouTube slow downs, and my video calls all seem to be good, at least today.

I am curious about what those ethernet disconnects/reconnnects in the log are though. If anyone else has any ideas, let me know!

 

[karma]

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...

 

[karma]

Thanks. I’m not a gamer, and don’t have a server, just the router/node giving access to my network clients. I have not seen any video/YouTube slow downs, and my video calls all seem to be good, at least today.

I am curious about what those ethernet disconnects/reconnnects in the log are though. If anyone else has any ideas, let me know!

• those are probably not actual ethernet disconnections but rather the name of the wifi band interface, eth* is a bit misleading. check the networkmap or ai mesh to see which device the mac address belongs to if you've named them, otherwise you'll have to check your devices for their mac addresses.
• it would be useful to see in the logs the reason the device was disconnected, that's cut off in your screenshot. i'm guessing it's roaming, disable the roaming assistant in the professional tab, adjust the value or pin the client to a specific node.
• pure speculation as i've never seen such a message: for the 'not mesh client, can't delete it' maybe you have a wired device connected to the WAN (blue) interface on the main router and/or node and it thinks you're trying to use wired backhaul

 

[kamil666]

It's not good. 42095 is stable, ping several hours, and 0 packet loss. 46061 keeps losing packets. The software 42095 connects to 5GHz only, the newer software including 46061 connects to 2.4Ghz and 5GHz simultaneously and that's probably a problem.

 

[Ironlake]

Ok, so now stable with main device at 46061 and node at 42095. No disconnections during gaming. I was reading through my system logs during use of 46061 on the node. One line that comes often is this one:

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

I have multiple of these message across the log during 46061 on the node. Today the log has none of these messages. So in my case scenario, I have wireless backhaul and two LAN devices on LAN 1 and LAN 2 port. Disconnection experienced on this LAN devices with 46061. I can not say for sure if WIFI clients were affected, did not test that properly because I rely on the LAN connection.

Your NAS is like a server as well, I had a Synology in the past, It should generate some logs.

Can you guys please check if you see these timeout messages in your Asus system log? You can save it as a txt file on your pc and use the "find" function in notepad CTRL+F. And please state if you have LAN devices connected to the Node.

 

[Ironlake]

It's not good. 42095 is stable, ping several hours, and 0 packet loss. 46061 keeps losing packets. The software 42095 connects to 5GHz only, the newer software including 46061 connects to 2.4Ghz and 5GHz simultaneously and that's probably a problem.

Did you do a WPS method hard reset? This may help with stability. Do reset on every asus device.

 

[kamil666]

Did you do a WPS method hard reset? This may help with stability. Do reset on every asus device.

No, too many settings and I don't have time for that. I have vpn clients / server etc.

 

[Ironlake]

No, too many settings and I don't have time for that. I have vpn clients / server etc.

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.

Regarding the wps method reset, in my case before I was having more disconnections on the wireless backhaul. When streaming locally, after the reset the streaming was stable again without disconnections. So when you have time maybe you can consider doing this.

 

[mbordere]

My experience with 46061 is more or less okay, running in AP-mode with ethernet backhaul. I get weird issues when enabling 160Mhz though, like some devices that are not pingable from some (not all) devices. Disabling 160Mhz seems to resolve this issue.

Anyone knows what's going on? I see a lot of posts where people just disable 160Mhz, but can someone tell me what's going on?