ZenWiFi XT8 new firmware 3.0.0.4.386_25524

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

SloPoke

Occasional Visitor
I feel like that's a touch a false advertising if restrictions don't exist and you still don't have that feature enabled. is there a way to set the region to someplace else?

Possibly, but you'd have to telnet or ssh in to the router and mess around in the command line interface. It's been reported that the region is locked in to the router and can't be changed.

Since all the XT8 firmwares are on the ASUS site, when I get some time where I can bounce my WIFi up and down for a day, I will try all of them if I can, starting from the first, and see which ones give me the 160Mhz option and which one took it away. I'm starting to think I was hallucinating 160MHz when I first set up the XT8 a couple of months ago.
 

karma

Regular Contributor
heh, fun... today for the first time I saw my wireless backhaul at 160MHz.. looks like you need to have at least 8 channels not RADAR Sensitive, Passive, just Radar Sensitive. That can change though when it does it's periodic radar detection thingie I guess.

[edit, i wonder if something is causing false positives.... anyways, i turned off 160MHz and DFS channels now, 80Mhz is plenty and I'd rather have something which doesn't change over time based on stuff I can't control. updated the config i posted before in case anybody is interested. just to be clear, i wasn't having issues before. ]
 
Last edited:

RKG81

Occasional Visitor
Possibly, but you'd have to telnet or ssh in to the router and mess around in the command line interface. It's been reported that the region is locked in to the router and can't be changed.

Since all the XT8 firmwares are on the ASUS site, when I get some time where I can bounce my WIFi up and down for a day, I will try all of them if I can, starting from the first, and see which ones give me the 160Mhz option and which one took it away. I'm starting to think I was hallucinating 160MHz when I first set up the XT8 a couple of months ago.

I’m absolutely positive my XT8 showed a 160mhz checkbox option when I FIRST looked at the settings screen. That was the ONLY time I ever saw the setting, so as soon as the router connected to a time server it must have locked in to my region, because I never saw the option again. The exact same happened with my RT-AX92U the first time I ever powered it up. Only saw the 160mhz option one single time then it was gone forever. No firmware update brings it back either. Canada here, and to complicate things further I live about 2 miles from an international airport. Regardless, I get perfect performance from this system and couldn’t be happier. Even with 80mhz channels.


Sent from my iPhone using Tapatalk
 

SloPoke

Occasional Visitor
I’m absolutely positive my XT8 showed a 160mhz checkbox option when I FIRST looked at the settings screen. That was the ONLY time I ever saw the setting, so as soon as the router connected to a time server it must have locked in to my region, because I never saw the option again. The exact same happened with my RT-AX92U the first time I ever powered it up. Only saw the 160mhz option one single time then it was gone forever. No firmware update brings it back either. Canada here, and to complicate things further I live about 2 miles from an international airport. Regardless, I get perfect performance from this system and couldn’t be happier. Even with 80mhz channels.

Sent from my iPhone using Tapatalk

Actually I was using the 160MHz frequency for a week or two before it disappeared. It was used on the backhaul at initial setup, and when I wired the node up for ethernet backhaul, I made the SSID visible and was using it to connect my HP Spectre x360 laptop. The wireless backhaul had an excellent connection but I have to stick with ethernet now as without the 160Mhz frequency, the wireless connection to the node is poor. Then at some point in all my rebooting, resetting, fiddling with the settings, and updating the firmware, it disappeared.

I can't complain about the performance either. But I'd like to get a definitive answer on this. ASUS should really list the supported and unsupported regions on their product page instead of a vague "depends what region/country you're in"
 

samep

Occasional Visitor
Actually I was using the 160MHz frequency for a week or two before it disappeared. It was used on the backhaul at initial setup, and when I wired the node up for ethernet backhaul, I made the SSID visible and was using it to connect my HP Spectre x360 laptop. The wireless backhaul had an excellent connection but I have to stick with ethernet now as without the 160Mhz frequency, the wireless connection to the node is poor. Then at some point in all my rebooting, resetting, fiddling with the settings, and updating the firmware, it disappeared.

I can't complain about the performance either. But I'd like to get a definitive answer on this. ASUS should really list the supported and unsupported regions on their product page instead of a vague "depends what region/country you're in"
Seems if I use the Asus Android mobile app to adjust 5G-2 settings, the Ethernet backhaul tends to get kicked back to radio backhaul.

I have to go back into the web portal to prioritize the backhaul to Ethernet and reconfigure 5G-2.

And for whatever reason, I thought I read that the 5G-2 had to be hidden to use 160 MHz bandwidth. Can't find that now. But what the web portal actually says now is 5G-2 can be unhidden for other devices to connect to it. Maybe I read that wrong but thought it was also a suggestion. I repeated that suggestion so maybe I've been wrong from the beginning. But I also have no way to verify I'm getting 160 MHz bandwidth.

Sent from my Pixel 4 XL using Tapatalk
 

TBONE204

Regular Contributor
Seems if I use the Asus Android mobile app to adjust 5G-2 settings, the Ethernet backhaul tends to get kicked back to radio backhaul.

I have to go back into the web portal to prioritize the backhaul to Ethernet and reconfigure 5G-2.

And for whatever reason, I thought I read that the 5G-2 had to be hidden to use 160 MHz bandwidth. Can't find that now. But what the web portal actually says now is 5G-2 can be unhidden for other devices to connect to it. Maybe I read that wrong but thought it was also a suggestion. I repeated that suggestion so maybe I've been wrong from the beginning. But I also have no way to verify I'm getting 160 MHz bandwidth.

Sent from my Pixel 4 XL using Tapatalk
check your wireless log to confirm the connection bandwidth of your node to the router. Its the last thing in the wireless log
 

SloPoke

Occasional Visitor
Seems if I use the Asus Android mobile app to adjust 5G-2 settings, the Ethernet backhaul tends to get kicked back to radio backhaul.

I have to go back into the web portal to prioritize the backhaul to Ethernet and reconfigure 5G-2.

And for whatever reason, I thought I read that the 5G-2 had to be hidden to use 160 MHz bandwidth. Can't find that now. But what the web portal actually says now is 5G-2 can be unhidden for other devices to connect to it. Maybe I read that wrong but thought it was also a suggestion. I repeated that suggestion so maybe I've been wrong from the beginning. But I also have no way to verify I'm getting 160 MHz bandwidth.

Sent from my Pixel 4 XL using Tapatalk

The ASUS app is broken in that respect. It always shows dedicated wireless backhaul whether it is or isn't. And the router interface itself also says this on the System Status initial page. But if the 5GHz-2 SSID is not hidden, it's not being used as a backhaul as far as I know, and you can connect clients to it. Although I haven't tried unplugging the ethernet cable from it and having the SSID visible at the same time to see what would happen.
 

samep

Occasional Visitor
check your wireless log to confirm the connection bandwidth of your node to the router. Its the last thing in the wireless log
Thanks. I'm not at home right now. But your mean check wireless log in the web portal?

The connection to router from node should be wired Ethernet though. Right? I've had it my mind that wireless devices connected to the XT8 node are using 5G-1 or 5G-2 but once data gets to the node, uploaded over Ethernet to router node. Correct?

Sent from my Pixel 4 XL using Tapatalk
 

RKG81

Occasional Visitor
The ASUS app is broken in that respect. It always shows dedicated wireless backhaul whether it is or isn't. And the router interface itself also says this on the System Status initial page. But if the 5GHz-2 SSID is not hidden, it's not being used as a backhaul as far as I know, and you can connect clients to it. Although I haven't tried unplugging the ethernet cable from it and having the SSID visible at the same time to see what would happen.

That’s right. In the web UI it says the 5ghz-2 is currently used as a dedicated backhaul and to unhide the SSID to enable it for clients even though I have unhidden the band and set each node to Ethernet priority. It simply just ignores the fact that it’s being used as a normal band with its own separate SSID.

Also, I wish to set my 5ghz-2 band to AX Only. I wanted to dedicate this band to our iPhone 11’s and any future AX devices that come along. But even when enabling AX Only it still allows non-AX devices to connect. It’s very frustrating that 3 firmware updates later it’s still behaving this way. Performance has been perfect for me from day 1 but this bug just drives me crazy.



Sent from my iPhone using Tapatalk
 
Last edited:

GenericITGuy

Occasional Visitor
25524 is a bad firmware update along with the previous 25509 which was worse.

I think I agree. My main issue is with DHCP server and manual assignment. I have close to 40 devices on my network and I manually assign them so I can do additional firewalling upstream. I was able to add 36 devices with manual assignment on previous firmware. now on 25524, it won't let me add or even remove devices from the manual assignment. Has anyone else seen this issue? Any potential workaround? the only thing I have not done yet is factory reset and start over---but that is a bitch and takes way longer than I want to spend.
 

mohsha

Occasional Visitor
try setting the dhcp_staticlist using nvram command.

nvram get dhcp_staticlist > dhcp.txt
nvram set dhcp_staticlist=`cat dhcp.txt`

First get the existing list and manually add remaining devices by following the same format and set the nvram variable with the new list. You will need putty and winscp if you are using windows computer to make these changes.
 

GenericITGuy

Occasional Visitor
try setting the dhcp_staticlist using nvram command.

nvram get dhcp_staticlist > dhcp.txt
nvram set dhcp_staticlist=`cat dhcp.txt`

First get the existing list and manually add remaining devices by following the same format and set the nvram variable with the new list. You will need putty and winscp if you are using windows computer to make these changes.

First, this idea was great and I have not ever even enabled SSH previously, so that was a great new idea I liked.
Second, I learned that my drop back to firmware 25217 only took place on the primary device and AIMESH device was still running 25524 and I guess because of the mismatch I couldn't even enable SSH. It said it did it, but was never listening.
I updated primary back to 25524 and SSH was enabled.

I proceeded to follow your steps, but it failed----the write occurred without error, but again it didn't take. Below is full output (username REDACTED for privacy). The big note is original file was 1200 bytes, updated file was 1234 after adding one new MAC and IP. I looked in GUI and didn't see the add. So, I went back and pulled again to dhcp2.txt and noticed it truncated back down to 1200. Therefore, it seems ASUS plan to support 64 devices miss calculated the byte count.

[email protected]_XT8-DA50:/tmp/home/root# cat dhcp.txt

<9C:F3:87:CA:06:4A>192.168.50.80><D0:52:A8:00:5D:9B>192.168.50.60><04:52:F3:52:69:2E>192.168.50.83><D0:C5:F3:4A:31:0A>192.168.50.102><64:76:BA:91:8A:7A>192.168.50.100><4C:EF:C0:3B:F8:88>192.168.50.76><34:D2:70:9D:9D:E5>192.168.50.63><C4:1C:FF:B3:C2:AA>192.168.50.78><CC:88:26:0D:A1:7D>192.168.50.99><54:13:79:0B:5F:75>192.168.50.101><50:F5:DA:88:24:D0>192.168.50.62><DC:A9:04:2C:EC:DA>192.168.50.82><00:05:CD:90:6D:27>192.168.50.73><00:5B:94:9C:E7:48>192.168.50.107><D8:BB:2C:83:12:29>192.168.50.125><14:0A:C5:83:69:F8>192.168.50.71><60:8C:4A:D8:02:5F>192.168.50.124><78:88:6D:74:FA:0C>192.168.50.121><5C:41:5A:59:85:BC>192.168.50.79><38:F7:3D:3C:50:8F>192.168.50.77><DC:A6:32:06:32:F8>192.168.50.22><5C:F6:DC:17:BE:E6>192.168.50.65><00:24:BE:F3:0F:D7>192.168.50.68><5C:52:1E:61:1E:73>192.168.50.126><2C:6F:C9:16:94:96>192.168.50.21><38:F7:3D:93:13:B0>192.168.50.81><00:12:FB:CE:99:EC>192.168.50.67><90:B9:31:94:2A:53>192.168.50.103><FC:A6:67:C0:4E:2A>192.168.50.74><B4:7C:9C:B8:6B:77>192.168.50.64><6C:56:97:EE:76:8E>192.168.50.75><CC:B0:DA:B1:38:43>192.168.50.120><FC:A1:83:F3:7F:85>192.168.50.69><50:D4:F7:E6:8A:F7>192.168.50.66><38:F9:D3:99:21:F3>192.168.50.110><68:64:4B:14:B2:D2>192.168.50.70><70:66:55:7F:8E:55>192.168.50.127>

[email protected]_XT8-DA50:/tmp/home/root# nvram set dhcp_staticlist=`cat dhcp.txt`

[email protected]_XT8-DA50:/tmp/home/root# ls -al

drwx------ 3 MYUSER root 80 Jul 7 17:08 .

drwxr-xr-x 3 MYUSER root 60 Dec 31 1969 ..

drwx------ 2 MYUSER root 60 May 5 2018 .ssh

-rw-rw-rw- 1 MYUSER root 1234 Jul 7 17:18 dhcp.txt

[email protected]_XT8-DA50:/tmp/home/root# nvram get dhcp_staticlist > dhcp2.txt

[email protected]_XT8-DA50:/tmp/home/root# ls -al

drwx------ 3 MYUSER root 100 Jul 7 17:21 .

drwxr-xr-x 3 MYUSER root 60 Dec 31 1969 ..

drwx------ 2 MYUSER root 60 May 5 2018 .ssh

-rw-rw-rw- 1 MYUSER root 1234 Jul 7 17:18 dhcp.txt

-rw-rw-rw- 1 MYUSER root 1200 Jul 7 17:21 dhcp2.txt

[email protected]_XT8-DA50:/tmp/home/root#
 

GenericITGuy

Occasional Visitor
First, this idea was great and I have not ever even enabled SSH previously, so that was a great new idea I liked.
Second, I learned that my drop back to firmware 25217 only took place on the primary device and AIMESH device was still running 25524 and I guess because of the mismatch I couldn't even enable SSH. It said it did it, but was never listening.
I updated primary back to 25524 and SSH was enabled.

I proceeded to follow your steps, but it failed----the write occurred without error, but again it didn't take. Below is full output (username REDACTED for privacy). The big note is original file was 1200 bytes, updated file was 1234 after adding one new MAC and IP. I looked in GUI and didn't see the add. So, I went back and pulled again to dhcp2.txt and noticed it truncated back down to 1200. Therefore, it seems ASUS plan to support 64 devices miss calculated the byte count.

[email protected]_XT8-DA50:/tmp/home/root# cat dhcp.txt

<9C:F3:87:CA:06:4A>192.168.50.80><D0:52:A8:00:5D:9B>192.168.50.60><04:52:F3:52:69:2E>192.168.50.83><D0:C5:F3:4A:31:0A>192.168.50.102><64:76:BA:91:8A:7A>192.168.50.100><4C:EF:C0:3B:F8:88>192.168.50.76><34:D2:70:9D:9D:E5>192.168.50.63><C4:1C:FF:B3:C2:AA>192.168.50.78><CC:88:26:0D:A1:7D>192.168.50.99><54:13:79:0B:5F:75>192.168.50.101><50:F5:DA:88:24:D0>192.168.50.62><DC:A9:04:2C:EC:DA>192.168.50.82><00:05:CD:90:6D:27>192.168.50.73><00:5B:94:9C:E7:48>192.168.50.107><D8:BB:2C:83:12:29>192.168.50.125><14:0A:C5:83:69:F8>192.168.50.71><60:8C:4A:D8:02:5F>192.168.50.124><78:88:6D:74:FA:0C>192.168.50.121><5C:41:5A:59:85:BC>192.168.50.79><38:F7:3D:3C:50:8F>192.168.50.77><DC:A6:32:06:32:F8>192.168.50.22><5C:F6:DC:17:BE:E6>192.168.50.65><00:24:BE:F3:0F:D7>192.168.50.68><5C:52:1E:61:1E:73>192.168.50.126><2C:6F:C9:16:94:96>192.168.50.21><38:F7:3D:93:13:B0>192.168.50.81><00:12:FB:CE:99:EC>192.168.50.67><90:B9:31:94:2A:53>192.168.50.103><FC:A6:67:C0:4E:2A>192.168.50.74><B4:7C:9C:B8:6B:77>192.168.50.64><6C:56:97:EE:76:8E>192.168.50.75><CC:B0:DA:B1:38:43>192.168.50.120><FC:A1:83:F3:7F:85>192.168.50.69><50:D4:F7:E6:8A:F7>192.168.50.66><38:F9:D3:99:21:F3>192.168.50.110><68:64:4B:14:B2:D2>192.168.50.70><70:66:55:7F:8E:55>192.168.50.127>

[email protected]_XT8-DA50:/tmp/home/root# nvram set dhcp_staticlist=`cat dhcp.txt`

[email protected]_XT8-DA50:/tmp/home/root# ls -al

drwx------ 3 MYUSER root 80 Jul 7 17:08 .

drwxr-xr-x 3 MYUSER root 60 Dec 31 1969 ..

drwx------ 2 MYUSER root 60 May 5 2018 .ssh

-rw-rw-rw- 1 MYUSER root 1234 Jul 7 17:18 dhcp.txt

[email protected]_XT8-DA50:/tmp/home/root# nvram get dhcp_staticlist > dhcp2.txt

[email protected]_XT8-DA50:/tmp/home/root# ls -al

drwx------ 3 MYUSER root 100 Jul 7 17:21 .

drwxr-xr-x 3 MYUSER root 60 Dec 31 1969 ..

drwx------ 2 MYUSER root 60 May 5 2018 .ssh

-rw-rw-rw- 1 MYUSER root 1234 Jul 7 17:18 dhcp.txt

-rw-rw-rw- 1 MYUSER root 1200 Jul 7 17:21 dhcp2.txt

[email protected]_XT8-DA50:/tmp/home/root#

Also, just did a quick calulation and they would need to support at least 2400 bytes, but I didn't account for all the variations on IP scheme. For example, someone not using default 192.168.50.X subnet and using 192.168.100.X and then also using top /25 meaning last octet is always 3 digits would require higher byte count than someone using 192.168.1.X and using bottom half of /25 where 3rd octet is 1 or 2 digits would require less.
So, they just need to calculate for 3 digits in both 3rd and 4th octet to fix it.
 

GenericITGuy

Occasional Visitor
Also, just did a quick calulation and they would need to support at least 2400 bytes, but I didn't account for all the variations on IP scheme. For example, someone not using default 192.168.50.X subnet and using 192.168.100.X and then also using top /25 meaning last octet is always 3 digits would require higher byte count than someone using 192.168.1.X and using bottom half of /25 where 3rd octet is 1 or 2 digits would require less.
So, they just need to calculate for 3 digits in both 3rd and 4th octet to fix it.
Ok, another update. The list is getting stored/saved/writen from some where else. I just deleted about 5 entries and did the nvram set dhcp_staticlist thing and none of my deletions were removed
GUI also won't let me delete.
 

digits n bits

Regular Contributor
I’m happy to report that after rolling back to firmware 25224 my XT8 is finally running like it should. Three days without an issue.
 

SloPoke

Occasional Visitor
...
Since all the XT8 firmwares are on the ASUS site, when I get some time where I can bounce my WIFi up and down for a day, I will try all of them if I can, starting from the first, and see which ones give me the 160Mhz option and which one took it away. I'm starting to think I was hallucinating 160MHz when I first set up the XT8 a couple of months ago.

I needed another node, so I bought another XT8. Out of the box, the firmware was 3.0.0.4.386_24926-g3b4fcd0. The 5GHz-2 "Enable 160 Mhz" checkbox was there and enabled by default. Awesome. Also I see in SmartConnect "Tri-Band Smart Connect (2.4GHz, 5GHz-1, 5GHz-2). If I upgrade to any more recent firmware, the Tri-Band Smart Connect is still there, probably because I haven't added any mesh nodes yet, but the "Enable 160 MHz" checkbox disappears. So the 160MHz frequency disappearing isn't a regional restriction, but a firmware problem?
 

SloPoke

Occasional Visitor
I needed another node, so I bought another XT8. Out of the box, the firmware was 3.0.0.4.386_24926-g3b4fcd0. The 5GHz-2 "Enable 160 Mhz" checkbox was there and enabled by default. Awesome. Also I see in SmartConnect "Tri-Band Smart Connect (2.4GHz, 5GHz-1, 5GHz-2). If I upgrade to any more recent firmware, the Tri-Band Smart Connect is still there, probably because I haven't added any mesh nodes yet, but the "Enable 160 MHz" checkbox disappears. So the 160MHz frequency disappearing isn't a regional restriction, but a firmware problem?

As soon as you add another mesh node, the "Enable 160 Mhz" disappears. Also, the ""Tri-Band Smart Connect (2.4GHz, 5GHz-1, 5GHz-2)" goes away and gets replaced with "Dual-Band". There doesn't appear that there's anything that can be done to enable 160 MHz, or Tri-band Smart Connect again short of a factory reset. Not setting it to ethernet backhaul, or trying to change the SSID of the 5GHz-2 band to the same as the as the 2.4/5-1 band (which can;t be done). Interesting.
 

RKG81

Occasional Visitor
I’m literally going through hell with this system since the last update. Two of my nodes refuse to even show up anymore. Speed has been crappy. Wifi calling has been terrible. I get a red light almost once a day now and my iPhone always drops internet connection but stays connected to wifi. It’s just a big bag of hurt. Starting to really hate this system now. It was working SO PERFECTLY until the last update. What gives?


Sent from my iPhone using Tapatalk
 

JoWa

Regular Contributor
I have the XT8 system since a few days back, a really good looking system. But having issues with the connection between router and nod. Everything is fine for a while, GREAT connection at 5ghz.. then from nowhere it drops to 2,4ghz and a weak signal... When I check wifi with any analyzer app my dBm is -40 to -55 witch is really good. So I dont understand the drop... Now I tried the RC2 build.. it gave me hope for 2hours (best connection so far..) then the drop came back again and weak signal. I rip my hair off soon or my family will kill me...
 

Similar threads

Sign Up For SNBForums Daily Digest

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