Since upgrading the firmware to 3.0.0.4.388.21099 on my AX8 (2x). I am having issues where sometimes the AX8 node (not the one acting as a router), has a blue light flashing constantly. When I factory reset both the router and node, they will connect to each other again using the 5GHZ-2 backhaul. However it will eventually go back and stick with using the 2.4ghz as the backhaul. The routers are not a massive distance between each other. One down stairs, one upstairs in a wooden framed house. This issue only seems to have started happening after upgrading to 3.0.0.4.388.21099. Anyone else experiencing the same?
Release ASUS ZenWiFi XT8 Firmware version 3.0.0.4.388.21099 (2022/10/03 )
- Thread starter karma
- Start date
Dodgydrains
Regular Contributor
I think the bug in 388.21099 is with multiple node setups like my 4 x XT8's. I also experienced different problems with the 'beta' 488.21268, now back to 386.49873 which is working fine again.
Dodgydrains
Regular Contributor
I am not sure, but your issue may be be that you are experiencing radar interference where you live.
had the same issue just happen to me with one of my nodes, downgrading back to 46061 since that was unfortunately the last most stable FW I have used
Is there any way to tell this from the logs? I didn't see anything obvious.
Dodgydrains
Regular Contributor
Hopefully someone on the forum can show you what to looks for as I have no idea. For me, the uplink type on the nodes change to 2.4GHz and then 30 minutes later reconnect to a a different 5GHz channel. Mine is usually stable on channel 100 on the 5GHz-2 channel.
My understanding on radar interference is not good at all.
I have 3 XT8s (1 router, 2 nodes) currently on 388.21099. They are Ethernet connected. I would like to go back to 386.49873. I have a backup of the 386.49873 configuration. What is the best sequence of downgrading the units, reloading the saved database etc?
Thanks in advance.
Thanks in advance.
I've not tried 21099, but IME with previous firmware versions, there are very obvious mentions of "radar" and/or "DFS" in the system log if the thing is detecting radar conflicts. Check in the System Log/General Log tab to see if anything got logged around the time of trouble. There is also a "DFS status" bit in the Wireless Log tab, but I don't offhand know what that will say if you've got trouble.
(Actually, if you can find any log entries that match up timewise with the problems, it'd be worth posting those whether or not you can interpret them.)
I have the following entries are in the general log matching "Radar" in the logs around the 19th, but nothing from the 20th, or 21st (so far). However the issue seems to be persistent. Nothing matching "DFS".
Code:
Oct 19 14:12:05 amas_adtbw: [ADTBW]Radar detected, wait for radar timeout
Oct 19 14:37:05 amas_adtbw: [ADTBW]Radar timeout
Oct 19 14:37:05 amas_adtbw: [ADTBW]Try to extend bw to 160
Oct 19 14:37:05 amas_adtbw: [ADTBW]ret 0
Oct 19 21:51:19 wlceventd: wlceventd_proc_event(657): eth6: Radar detected
Oct 19 21:58:12 amas_adtbw: [ADTBW]Radar detected, wait for radar timeout
Oct 19 22:23:12 amas_adtbw: [ADTBW]Radar timeout
Oct 19 22:23:12 amas_adtbw: [ADTBW]Try to extend bw to 160
Oct 19 22:23:12 amas_adtbw: [ADTBW]ret 1And the Wireless log:
Code:
SSID: "(truncated)"
noise: -93 dBm Channel: 5
BSSID: 04:42:1A:72:45:30 Capability: ESS ShortSlot RRM
Supported Rates: [ 1(b) 2(b) 5.5(b) 6 9 11(b) 12 18 24 36 48 54 ]
HE Capable:
Chanspec: 2.4GHz channel 5 20MHz (0x1005)
Primary channel: 5
HT Capabilities: 40Mhz SGI20 SGI40
Supported HT MCS : 0-15
Supported VHT MCS:
NSS1 Tx: 0-11 Rx: 0-11
NSS2 Tx: 0-11 Rx: 0-11
Supported HE MCS:
80 Mhz:
NSS1 Tx: 0-11 Rx: 0-11
NSS2 Tx: 0-11 Rx: 0-11
Interference Level: Acceptable
Mode : AP Only
Stations List
----------------------------------------
idx MAC Associated Authorized RSSI PHY PSM SGI STBC MUBF NSS BW Tx rate Rx rate Connect Time
(truncated) Yes Yes -58dBm ax No Yes Yes No 2 20M 286.8M 258.1M 35:03:26
SSID: "(truncated)"
noise: -88 dBm Channel: 60/80
BSSID: 04:42:1A:72:45:34 Capability: ESS RRM
Supported Rates: [ 6(b) 9 12 18 24(b) 36 48 54 ]
HE Capable:
Chanspec: 5GHz channel 58 80MHz (0xe23a)
Primary channel: 60
HT Capabilities: 40Mhz SGI20 SGI40
Supported HT MCS : 0-15
Supported VHT MCS:
NSS1 Tx: 0-11 Rx: 0-11
NSS2 Tx: 0-11 Rx: 0-11
Supported HE MCS:
80 Mhz:
NSS1 Tx: 0-11 Rx: 0-11
NSS2 Tx: 0-11 Rx: 0-11
Interference Level: Acceptable
Mode : AP Only
DFS status: state In-Service Monitoring(ISM) time elapsed 124154700ms radar channel cleared by DFS channel 60/80 (0xE23A)
Channel Information
----------------------------------------
Channel 36 A Band
Channel 40 A Band
Channel 44 A Band
Channel 48 A Band
Channel 52 A Band, RADAR Sensitive
Channel 56 A Band, RADAR Sensitive
Channel 60 A Band, RADAR Sensitive
Channel 64 A Band, RADAR Sensitive
Stations List
----------------------------------------
idx MAC Associated Authorized RSSI PHY PSM SGI STBC MUBF NSS BW Tx rate Rx rate Connect Time
(truncated) Yes Yes -66dBm ac No Yes Yes No 1 80M 292.5M 325M 06:05:07
SSID: "(truncated)_dwb"
noise: -87 dBm Channel: 116/80
BSSID: (truncated) Capability: ESS RRM
Supported Rates: [ 6(b) 9 12(b) 18 24(b) 36 48 54 ]
HE Capable:
Chanspec: 5GHz channel 122 80MHz (0xe07a)
Primary channel: 116
HT Capabilities: 40Mhz SGI20 SGI40
Supported HT MCS : 0-31
Supported VHT MCS:
NSS1 Tx: 0-11 Rx: 0-11
NSS2 Tx: 0-11 Rx: 0-11
NSS3 Tx: 0-11 Rx: 0-11
NSS4 Tx: 0-11 Rx: 0-11
Supported HE MCS:
80 Mhz:
NSS1 Tx: 0-11 Rx: 0-11
NSS2 Tx: 0-11 Rx: 0-11
NSS3 Tx: 0-11 Rx: 0-11
NSS4 Tx: 0-11 Rx: 0-11
160 Mhz:
NSS1 Tx: 0-11 Rx: 0-11
NSS2 Tx: 0-11 Rx: 0-11
NSS3 Tx: 0-11 Rx: 0-11
NSS4 Tx: 0-11 Rx: 0-11
Interference Level: Acceptable
Mode : AP Only
DFS status: state In-Service Monitoring(ISM) time elapsed 124414200ms radar channel cleared by DFS channel 116/80 (0xE07A)
Channel Information
----------------------------------------
Channel 100 A Band, RADAR Sensitive
Channel 104 A Band, RADAR Sensitive
Channel 108 A Band, RADAR Sensitive
Channel 112 A Band, RADAR Sensitive
Channel 116 A Band, RADAR Sensitive
Channel 120 A Band, RADAR Sensitive
Channel 124 A Band, RADAR Sensitive
Channel 128 A Band, RADAR Sensitive
Channel 132 A Band, RADAR Sensitive, Passive
Channel 136 A Band, RADAR Sensitive, Passive
Channel 140 A Band, RADAR Sensitive, Passive
Stations List
----------------------------------------
idx MAC Associated Authorized RSSI PHY PSM SGI STBC MUBF NSS BW Tx rate Rx rate Connect TimeOuch ... that is a classic case of poor configuration. The log entries show that you do live in an area that has occasional radar interference. You have chosen primary channels, on both radios, that are in the DFS range. I believe the effect of that is that when radar is detected, you lose service entirely until the regulations-mandated timeout (~20 min) has passed with no further radar detection.
The right way to make use of the available 5GHz bandwidth is to choose a primary channel that is DFS-free -- in the USA, your options are 36, 40, 44, 48 in the lower band and 149, 153, 157, 161 in the upper one. These are adjacent to channels that are available for use but fall under DFS regs. Each of these channels is 20MHz wide, so the router can aggregate four adjacent channels to provide 80MHz bandwidth (without using any DFS channels) or eight adjacent channels to provide 160MHz bandwidth (which requires pulling some DFS channels into the group). What that means is that when the router detects radar, it will fall back from 160MHz to 80MHz (or less) channel width, but not lose service entirely. Or at least that's the theory. If you still have problems with radar-related service glitches, you might prefer to just disable use of 160MHz bandwith altogether, so that the router never tries to use DFS channels.
The right way to make use of the available 5GHz bandwidth is to choose a primary channel that is DFS-free -- in the USA, your options are 36, 40, 44, 48 in the lower band and 149, 153, 157, 161 in the upper one. These are adjacent to channels that are available for use but fall under DFS regs. Each of these channels is 20MHz wide, so the router can aggregate four adjacent channels to provide 80MHz bandwidth (without using any DFS channels) or eight adjacent channels to provide 160MHz bandwidth (which requires pulling some DFS channels into the group). What that means is that when the router detects radar, it will fall back from 160MHz to 80MHz (or less) channel width, but not lose service entirely. Or at least that's the theory. If you still have problems with radar-related service glitches, you might prefer to just disable use of 160MHz bandwith altogether, so that the router never tries to use DFS channels.
Hmm it seems to have been configured this way out of the box, or at least maybe this is what its "Optimisation" feature picked. However the backhaul seems to be permanently on 2.4ghz with a "weak". If I reset the routers, it will link up again with the 5ghz-2 backhaul and a "great" signal.
I'm not sure what configuration(s) I should change to do what you suggested? Would this involve only disabling 160MHZ?
A few people in the linked thread here had success with un-sticking the 2.4ghz backhaul issue by disabling the "roaming assistant".
So it appears I have a few options:
- move the router and node closer together (although they are not too far apart)
- disable "roaming assistant" on the back haul
- downgrade to 49873
- throw the whole lot in the bin
Since buying the AX8, Google announced their Nest Wifi Pro (Wifi-6E), that I regret not holding out for. Seems to many people are having issues with this router and nodes.
By the way, if I am reading this correctly. USA can also use
36, 40, 44, 48, 52, 56, 60, 64, 100, 104, 108, 112, 116, 132, 136, 140, 149, 153, 157, 161, 165
I am based in Ireland, which I am assuming follows similar to the other European countries listed there, so should have these available:
36, 40, 44, 48, 52, 56, 60, 64, 100, 104, 108, 112, 116, 120, 124, 128, 132, 136, 140
I'm not sure what configuration(s) I should change to do what you suggested? Would this involve only disabling 160MHZ?
A few people in the linked thread here had success with un-sticking the 2.4ghz backhaul issue by disabling the "roaming assistant".
So it appears I have a few options:
- move the router and node closer together (although they are not too far apart)
- disable "roaming assistant" on the back haul
- downgrade to 49873
- throw the whole lot in the bin
Since buying the AX8, Google announced their Nest Wifi Pro (Wifi-6E), that I regret not holding out for. Seems to many people are having issues with this router and nodes.
By the way, if I am reading this correctly. USA can also use
36, 40, 44, 48, 52, 56, 60, 64, 100, 104, 108, 112, 116, 132, 136, 140, 149, 153, 157, 161, 165
I am based in Ireland, which I am assuming follows similar to the other European countries listed there, so should have these available:
36, 40, 44, 48, 52, 56, 60, 64, 100, 104, 108, 112, 116, 120, 124, 128, 132, 136, 140
Last edited:
Never had any major problems since 42095. Each updates went pretty smoothly so far. Felt like I was the lucky one. Until this one 21099.
Very bad connection across the board. Connexion drop, slow down, random events,…
Downgraded back to 48966 (I was previously on 48706 which worked like a charm). That was even worse. Factory reset for the first time hoping it would solve it. Nope. Decided to upgrade again to 21099 (you never know) and still some issues. Before going back to 48706, thought I’d do another factory reset. And to my surprise things are back to normal with firmware 21099!
that was a rough couple of days troubleshooting this mess! Still quite early, only time will tell but so far I feel like I have a functioning router again now I hope I’ve not jinxed it haha
Very bad connection across the board. Connexion drop, slow down, random events,…
Downgraded back to 48966 (I was previously on 48706 which worked like a charm). That was even worse. Factory reset for the first time hoping it would solve it. Nope. Decided to upgrade again to 21099 (you never know) and still some issues. Before going back to 48706, thought I’d do another factory reset. And to my surprise things are back to normal with firmware 21099!
that was a rough couple of days troubleshooting this mess! Still quite early, only time will tell but so far I feel like I have a functioning router again now I hope I’ve not jinxed it haha
Well, yeah, but the point is that the rest of those channels are subject to the DFS regulations, which say that WiFi devices have to drop off the channel if they detect any radar pulses on it.
Ah. I'm not sure if Ireland follows UK or EU regs, but I suppose it's one or the other. According to wikipedia's list, only 32-48 are available in a reasonably unobstructed way there; the others you mention have DFS restrictions. 149-161 are available under "SRD" (short range device) rules, which impose a pretty draconian transmit power limit under EU rules and an only somewhat less draconian limit under UK rules. I wouldn't be surprised if ASUS just disallowed those channels in their Irish configuration rather than deal with complaints about how crappy the signal is. In any case, it's quite clear from your wireless log that 60 and 116 are both radar-sensitive channels according to your router, and that is not what you want for the radio's primary channel.
Looking at this table, I kind of wonder why ASUS is even selling this kit in Europe. There isn't any part of the spectrum that the 5GHz-2 radio can reach that isn't covered by DFS regs there. Basically your only hope for reliable service (except far away from any airport or weather radar, as you evidently aren't) is to run wired backhaul, turn off the 5GHz-2 radio, and be sure to use 32-48 for 5GHz-1. Maybe you'd be best advised to send it back and get a device with only 2 radios not 3, because the 5GHz-2 radio is a waste of money for you.
I'm wondering if your nodes revert to 2.4GHz. backhaul because they're too far apart? When you use the Asus Router app on your smart phone, and tap the remote node, what strength does it have at the top of the page that you go to? For example, at the top of the page for the remote node for me, it says "Great", and between about -60 to -55dBm signal strength. I've never had my ZenWiFi revert to 2.4GHz., it stays on 5GHz. for backhaul. If you need to have the nodes further apart than is solid with 5GHz. backhaul, your easy choices are either ethernet cable or MoCA between the nodes as wired backhaul.
By the way, 49873 also worked well for me, so that might indeed may be something to try. As well as disabling 160MHz. backhaul channel width. I've had better results not using "smart connect", and picking channels and channel widths that work for me. Letting the ZenWiFi set the control channels automatically hasn't worked well for me, either.
I'm assuming that you've done a full factory reset after flashing 21099, and re-entered your configuration settings manually. That does help get you to a known state.
It might have been best I went for a 6E router, I don't think the 6GHz has such restrictions? One annoying thing is that in Ireland and/or Europe the Google Nest Wifi Pro only comes with a 1 or 3 pack, where as in US, it comes with a 1, 2 and 3 pack. I would only need two nodes. I just hope Amazon are understandable and take the return.
It seems to fluxuate between -60 to -63dBm and shown as "Weak". However initially after a factory reset it shows somewhere in the range of -58dBm and shown as "Great" and uses the 5Ghz-2 backhaul. I'm planing to move them closer together though. They won't be in an ideal location but might have no choice. Running an ethernet or MoCA cable is not really an option at the minute, at least without some intrusive work on the house. This is why I was hoping to use the 5GHZ-2 backhaul!
Last edited:
The XT8's here are about 40' and a couple of walls apart, but how far apart you can have them is really dependent on house construction, furniture placement, etc. I guess that our house is flimsy enough to allow this to work well *smile*. No concrete, metal studs, or lathe and plaster, etc. Or much of anything in the walls, apparently. Not looking forward to the next big earthquake here.
Sorry that this has been so frustrating for you...after wrestling with the eero pro 6's for some time, the ZenWiFi has been a breath of fresh air for me. All the things that should have worked with the eero do work with this one.
RouterTimeExcellent
New Around Here
Does anyone know if there's a more verbose mode for the system log? I'm trying to troubleshoot my PS5's (Play Station 5's on 5GHz) disconnecting from the XT8. My setup is 3.0.0.4.388_21099/hard factory reset/backhaul to ethernet/everything else default.
It only seems to happen to PS5s (from what I can tell, our Fire TV's hasn't dropped). How I fix it is to go into my PS5 settings -> network -> connection status -> test internet connection. Then everything starts working again. I've been able to reproduce this many times.
The mac address of the PS5's don't show up in the logs, but I do see that the DHCP lease is renewed so there's definitely some handshake happening. I've tried binding the PS5's to the mesh nodes but that doesn't seem to help.
My next set of troubleshooting is:
It only seems to happen to PS5s (from what I can tell, our Fire TV's hasn't dropped). How I fix it is to go into my PS5 settings -> network -> connection status -> test internet connection. Then everything starts working again. I've been able to reproduce this many times.
The mac address of the PS5's don't show up in the logs, but I do see that the DHCP lease is renewed so there's definitely some handshake happening. I've tried binding the PS5's to the mesh nodes but that doesn't seem to help.
My next set of troubleshooting is:
- Moving one of the PS5's to hardwired ethernet to see if it's more stable (which is likely as the PS5's worked fine on my old shaw router setup before I upgraded to the XT8)
- Trying access point mode to see if there's something funky w/ the mesh side of things
- ???
Maybe, but don't jump to conclusions quite yet. We've got multiple active theories here: DFS problems, signal too weak, or firmware issue. Using 6E would fix DFS problems, but if it's really signal-too-weak you'd likely find that 6E makes it worse: 6GHz is going to have even worse penetration than 5GHz. You'd better narrow down the actual cause before thinking about switching routers.
Even just a temporary relocation would help you figure out what's what. If it's radar interference then moving them closer won't help, but if it's signal-too-weak then moving them close enough to get say 5dBm better signal should make a difference. You should also try to identify the times that the dropouts happen and see if they correlate with system log entries about radar.
I don't know of any setting that makes the System Log GUI page more verbose, but if you can turn on rsyslog logging to a nearby Linux or BSD server, you'll find that that's significantly more verbose than the GUI log. On the ASUS itself that's just a matter of putting the server's IP address into the "Remote Log Server" field. You'll probably have to do some configuration work on the Linux machine though, first to poke a hole in the firewall and second to teach the syslog daemon where you want the log data stored.
Yes, you can increase logging information by changing the log_level on your router. Its 6 by default, you could try setting it to 7 and see if you get what you're looking for. First, turn on ssh for the LAN only in the router web admin interface, and then use ssh to log into your router. The following router "shell" commands are what I recall from changing log_level:
Code:
nvram get log_level [verify the current level, should be 6 the first time]
nvram set log_level=7 [set the log level to more verbose]
nvram get log_level [make sure your change worked]
nvram commit [make your changes permanent, effective after the next router reboot]
rebootYou can go up to 10 for log_level, I think. Not sure though that you won't be overwhelmed by the sheer volume of the log at the higher log_level settings. You can always send the log to a text editor like vi or "TextEdit" on a mac, where you can search it to help deal with the volume of logged output.
Similar threads
Similar threads
Similar threads
-
Release ASUS ZenWiFi XT8 Firmware version 3.0.0.4.388_24684
- Started by Dodgydrains
- Replies: 17
-
Release ASUS ZenWiFi XT8 Firmware version 3.0.0.4.388_24668 (2024/09/24)
- Started by naitkris
- Replies: 16
-
Release ASUS ZenWIFI XT8 Firmware version 3.0.0.4.388_24621
- Started by Dodgydrains
- Replies: 39
-
Release ASUS ZenWiFi AX (XT8) Firmware version 3.0.0.4.388.24609
- Started by Dodgydrains
- Replies: 46
-
Asus AX89X + ZenWiFi XT8 + Ethernet backhaul => Unencrypted network!
- Started by slrt
- Replies: 7
-
Release ASUS ZenWiFi BQ16 Firmware version 3.0.0.6.102_36801 (26/11/2024)
- Started by Stepalex
- Replies: 5
-
Release ASUS ZenWiFi XP4 Firmware version 3.0.0.4.386_47475 (2024/11/25)
- Started by fruitcornbread
- Replies: 1
-
Release ASUS ZenWiFi ET9 Firmware version 3.0.0.4.388_25146 (2024/11/19)
- Started by fruitcornbread
- Replies: 2
-
Release ASUS ZenWiFi XD4S / XD4 Plus Firmware version 3.0.0.4.386_69095 (2024/11/18)
- Started by fruitcornbread
- Replies: 0
-
Release Asus ZenWiFi XD4 Mini - Firmware Update 3.0.0.4_388_25106 (Nov 18 2024)
- Started by Grantman
- Replies: 6
Latest threads
-
-
-
NOTE for GT-AXE11000: Only Works Well for IP Passthrough Setup with GT-AXE11000_388.2_4.zip
- Started by realmikeazn
- Replies: 4
-
GT-AX6000 WAN Port as Trunk to upstream firewall??- Started by kstamand
- Replies: 0
-
1 Gbps, 2,5Gbps and 10Gbps long distance on OM1 62.5/125µm multimode fiber. Experience?
- Started by Pello
- Replies: 1
Support SNBForums w/ Amazon
If you'd like to support SNBForums, just use this link and buy anything on Amazon. Thanks!
Sign Up For SNBForums Daily Digest
Get an update of what's new every day delivered to your mailbox. Sign up here!