What's new

Asus ZenWiFi ET8 - Connection Issues

  • SNBForums Code of Conduct

    SNBForums is a community for everyone, no matter what their level of experience.

    Please be tolerant and patient of others, especially newcomers. We are all here to share and learn!

    The rules are simple: Be patient, be nice, be helpful or be gone!

heaven

Occasional Visitor
Recently bought ZenWiFi ET8 and the first impression was great, the setup worked well, great speeds (or I didn't notice the problem at the beginning). A few days ago I started noticing that the satellite often gets disconnected. I have a NAS which is connected to the satellite by a wire with a Plex media server there. When people with mobile devices are moving around the devices switch between the satellite and the router and this causes the satellite to go out of sync (or something like that). The blue indicator starts blinking and often breaks the connection between the router and the satellite and thus disconnects all clients linked to the satellite. Network shares I have on the NAS are being disconnected, Time Machine backups on my Mac break, playback from Plex freezes.

The backhaul was configured over a 6GHz band and shows a good signal strength with speeds of around 2.8Gbps. I even tried moving the nodes closer to each other with a distance of fewer than 5 meters, the speed between the nodes was higher than 4Gbps. But this didn't help so I'm pretty sure it's not about the signal strength and notice. WiFi log shows noise -90 and RSSI -50 when the nodes are in separate rooms. I tried changing channels, reducing the bandwidth to 80Mhz, swapping nodes (after factory reset) but no luck. When swapped the nodes the router started freezing from time to time and rebooting unexpectedly (I guess firmware crashed). I checked the logs and they are full of errors (examples attached below). I saw there are even kernel panics. Some of those logs were taken after such a crash.

I've switched the backhaul to 5Ghz about 5 hours ago and the system seems to work sable. No disruptions, no crashes, just perfect. Except that I simply wasted money buying this 6Ghz device and can't use this band for anything other than a backhaul, which doesn't work. And now have to share the 5Ghz band between devices and backhaul connection. The support doesn't reply, I bought this item on Amazon from a US seller while I'm in another part of the world, paid a lot of fees to get it here, and most likely can't return it back. Not sure what to do with this and where to get help. Any help is appreciated but I'm skeptical that anything could be done at least until the new firmware is released (if this is not a hardware issue).

UPD. Forgot to mention the firmware is the latest available 3.0.0.4.386_43981-g8cc0fd3. I'd like to downgrade but can't find the previous version on the website.
 

Attachments

  • Time Machine fail 1.0.png
    Time Machine fail 1.0.png
    601.7 KB · Views: 140
  • Crash Log 1.txt
    47.2 KB · Views: 144
  • Crash Log 2.txt
    21.9 KB · Views: 110
  • Crash Log 3.txt
    49.7 KB · Views: 134
Hi, thank you for the suggestion. I will try this probably over the weekend. For now, I see 5Ghz also has disconnects but seems a bit more stable. I will monitor for one more day. Overall, is the situation common with the mesh systems or are they expected to be more reliable? Wondering if owners of other mesh systems have ever seen anything like this.
 
I've 2 terminals open in the background and ping commands to both the router and the satellite running.

Just recently ping to the satellite started timing out, the first failure appeared at 13:52:56, nothing in the router log so far. A few minutes later in the router log https://pastebin.com/raw/HG3z3v8x

At this time ping to my router started failing, from 14:00:48 to 14:00:54. I didn't do anything, no new devices were added to the network, it just failed and started doing something unknown. If there was an ability to see the log on the satellite, but I can't! Can only guess what happened there.

In my opinion, something is seriously messed up in the firmware. And this is probably the worst experience I've ever had. The thing that should just work behaves like an MVP.

UPD. I've just configured the SSH access and here's what I've found in the `/tmp/syslog.log-1` on the satellite.

Code:
Nov 30 13:48:40 wlceventd: wlceventd_proc_event(508): wl1.1: Disassoc 96:79:49:CA:9B:66, status: 0, reason: Disassociated because sending station is leaving (or has left) BSS (8), rssi:0
Nov 30 13:48:40 wlceventd: wlceventd_proc_event(508): wl1.1: Disassoc 96:79:49:CA:9B:66, status: 0, reason: Disassociated because sending station is leaving (or has left) BSS (8), rssi:0
Nov 30 13:52:42 wlceventd: wlceventd_proc_event(537): wl1.1: ReAssoc 96:79:49:CA:9B:66, status: Successful (0), rssi:-77
Nov 30 13:53:54 wlceventd: wlceventd_proc_event(491): wl1.1: Deauth_ind 96:79:49:CA:9B:66, status: 0, reason: Deauthenticated because sending station is leaving (or has left) IBSS or ESS (3), rssi:0
Nov 30 13:53:54 wlceventd: wlceventd_proc_event(508): wl1.1: Disassoc 96:79:49:CA:9B:66, status: 0, reason: Disassociated because sending station is leaving (or has left) BSS (8), rssi:0
Nov 30 13:53:54 wlceventd: wlceventd_proc_event(491): wl1.1: Deauth_ind 6E:20:4A:75:6E:20, status: 0, reason: Deauthenticated because sending station is leaving (or has left) IBSS or ESS (3), rssi:0
Nov 30 13:54:00 MISC: wifi upstream is connected, and disconnected from CAP.
Nov 30 13:54:11 rc_service: watchdog 1961:notify_rc start_cfgsync
Nov 30 13:54:41 rc_service: watchdog 1961:notify_rc start_cfgsync
Nov 30 13:58:49 rc_service: amas_misc 1966:notify_rc restart_wireless
Nov 30 13:58:49 kernel: irq -553648056, desc: df403640, depth: 1, count: 0, unhandled: 0
Nov 30 13:58:49 kernel: ->handle_irq():  c0064434, handle_bad_irq+0x0/0x278
Nov 30 13:58:49 kernel: ->irq_data.chip(): c066d440, 0xc066d440
Nov 30 13:58:49 kernel: ->action():   (null)
Nov 30 13:58:49 kernel:    IRQ_NOPROBE set
Nov 30 13:58:49 kernel:  IRQ_NOREQUEST set
Nov 30 13:58:49 kernel: unexpected IRQ trap at vector df000048

Then it rebooted. Exactly when I started having connection issues. I see these Disassoc/ReAssoc log entries like if someone started moving in the house or Smart Connect decided to switch the band, something went wrong and it crashed. So it's not about the connectivity it seems. It's just bad firmware (or hardware).
 
Last edited:
6ghz has less range than 5ghz. Therefore, you definitely don't want to be using it as a backhaul.

I personally would take this back and wait until Asus release a 6ghz mesh that also has a 4x4 5ghz channel, that way the 5ghz band would be fast enough to use as a backhaul. The 2x2 5ghz channel on the ET8 is not fast enough for a backhaul as that would only be 1.2gbps.

I have AX92u's and the 5ghz backhauls connect at 2.6gbps with a signal of -55db.

-55dBm ax No Yes Yes Yes 4 160M 2594.1M 2594.1M 107:14:05
 
The upper range of 5GHz and the start of 6GHz are almost identical. The range will not be affected. Or at least, shouldn't be in a properly designed router/antennae unit.
 
The signal quality looks pretty good and the speed is shown as 2.8Gbps with RSSI around -50.

@toaruScar the last log I posted with the kernel: unexpected IRQ trap at vector is from the satellite.

@toaruScar In addition, every time I restart the system the following crash log entries are in the log.
 

Attachments

  • startup.txt
    25.8 KB · Views: 117
Last edited:
@leerees I'm skeptical that it's due to the range, especially considering all these crash reports in the logs. I'm currently on 5G as a backhaul and it seems a bit more stable but disconnects are still happening from time to time.
 
I've been running the RC3-2 and -3 that's in the top pegged post in this forum. It has definitely been better, though not 100% perfect. But my videos now ride through a period of low bandwidth instead of being cut off when it does this "thing it does for a few seconds" and makes many wifi connections "blip" (they stay connected but stop communicating). I think these units have a hard time with 50+ devices on wifi, but there's hope that the new firmware will address this.
 
Suddenly this thing started working as expected (almost). I don' know what happened, firmware is the same but I went through many factory resets, and recently the satellite simply stopped connecting to the maser router just flashing the blue led. I did factory reset on the satellite pressing and holding the reset button, it did rese and then automatically re-connected to the router.

But the satellite still disconnects from the router a few times per day with these lines in the syslog
Dec 19 10:42:47 rc_service: amas_lanctrl 1437:notify_rc start_cfgsync
Dec 19 12:42:48 BHC: WiFi connection status change.
Dec 19 12:42:48 BHC: bandindex(0): state is 0
Dec 19 12:42:48 BHC: bandindex(1): state is 0
Dec 19 12:42:48 BHC: bandindex(2): state is 0
Dec 19 12:42:48 BHC: Topology change from 4 to -1.
Dec 19 12:42:52 BHC: IN_BR eth0,R1 eth5,R0
Dec 19 12:42:54 BHC: IN_BR eth0,R1
Dec 19 12:43:00 kernel: dpsta_register: null dpsta_ifnames!
Dec 19 12:43:00 kernel: dpsta_register: null dpsta_ifnames!
Dec 19 12:43:02 BHC: WiFi connection status change.
Dec 19 12:43:02 BHC: bandindex(0): state is 2
Dec 19 12:43:02 BHC: bandindex(1): state is 2
Dec 19 12:43:02 BHC: bandindex(2): state is 0
Dec 19 12:43:02 rc_service: watchdog 1428:notify_rc start_cfgsync
Dec 19 12:43:04 BHC: Topology change from -1 to 4.
Dec 19 12:43:06 BHC: IN_BR eth0,R1 eth5,R2
Dec 19 12:43:07 kernel: dpsta_register: null dpsta_ifnames!
Dec 19 12:43:07 kernel: kck:
Dec 19 12:43:07 kernel: 0000: bc 0b 07 27 1a c9 f6 16 7e 22 d8 5d 2a a5 c6 81
Dec 19 12:43:07 kernel: kek:
Dec 19 12:43:07 kernel: 0000: 49 4a 62 7f 2c 18 f5 96 48 39 30 f1 58 58 a4 80
Dec 19 12:43:07 kernel: replay_ctr:
Dec 19 12:43:07 kernel: 0000: 00 00 00 00 00 00 00 02
Dec 19 12:43:10 BHC: WiFi connection status change.
Dec 19 12:43:10 BHC: bandindex(0): state is 2
Dec 19 12:43:10 BHC: bandindex(1): state is 2
Dec 19 12:43:10 BHC: bandindex(2): state is 2
Dec 19 12:43:12 BHC: Topology change from 4 to 128.
Dec 19 12:43:13 kernel: br0: adding interface eth6 with same address as a received packet
Dec 19 12:43:13 BHC: IN_BR eth0,R1 eth5,R0
Dec 19 12:43:15 BHC: IN_BR eth0,R1 eth6,R2

Below are the corresponding lines from the master router at this same period of time
Dec 19 12:42:46 wlceventd: wlceventd_proc_event(508): wds1.0.1: Disassoc 7C:10:C9:A8:54:C4, status: 0, reason: Disassociated because sending station is leaving (or has left) BSS (8), rssi:0
Dec 19 12:42:46 kernel: wl1: set timeout 5 secs to wait dev reg finish
Dec 19 12:42:46 wlceventd: wlceventd_proc_event(508): eth5: Disassoc 7C:10:C9:A8:54:C4, status: 0, reason: Disassociated because sending station is leaving (or has left) BSS (8), rssi:0
Dec 19 12:42:46 kernel: Flushing net_device wds1.0.1.
Dec 19 12:43:00 wlceventd: wlceventd_proc_event(556): eth5: Assoc 7C:10:C9:A8:54:C4, status: Successful (0), rssi:-30
Dec 19 12:43:00 wlceventd: wlceventd_proc_event(556): eth4: Assoc 7C:10:C9:A8:54:C1, status: Successful (0), rssi:-38
Dec 19 12:43:07 wlceventd: wlceventd_proc_event(556): eth6: Assoc 7C:10:C9:A8:54:C8, status: Successful (0), rssi:-64
Dec 19 12:43:07 kernel: Register interface [wds2.0.1] MAC: 7c:10:c9:7e:74:28
Can anyone suggest what does this mean, why does the topology change, and what's going on.

While this was happening ping command to the satellite started timing out
Sun Dec 19 12:42:43 EET 2021: 64 bytes from 192.168.50.196: icmp_seq=4103 ttl=64 time=3.646 ms
Sun Dec 19 12:42:45 EET 2021: 64 bytes from 192.168.50.196: icmp_seq=4104 ttl=64 time=3.258 ms
Sun Dec 19 12:42:49 EET 2021: Request timeout for icmp_seq 4105
Sun Dec 19 12:42:51 EET 2021: Request timeout for icmp_seq 4106
Sun Dec 19 12:42:53 EET 2021: Request timeout for icmp_seq 4107
Sun Dec 19 12:42:56 EET 2021: Request timeout for icmp_seq 4108
Sun Dec 19 12:42:58 EET 2021: Request timeout for icmp_seq 4109
Sun Dec 19 12:43:00 EET 2021: Request timeout for icmp_seq 4110
Sun Dec 19 12:43:02 EET 2021: Request timeout for icmp_seq 4111
Sun Dec 19 12:43:04 EET 2021: Request timeout for icmp_seq 4112
Sun Dec 19 12:43:06 EET 2021: Request timeout for icmp_seq 4113
Sun Dec 19 12:43:06 EET 2021: 64 bytes from 192.168.50.196: icmp_seq=4114 ttl=64 time=60.333 ms
Sun Dec 19 12:43:08 EET 2021: 64 bytes from 192.168.50.196: icmp_seq=4115 ttl=64 time=3.150 ms
 

Similar threads

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!
Top