ASUS ZenWiFi AX (XT8) – devices intermittently disconnect and do not reconnect.

[damo2k]

Hi all,

I have recently come across an issue with my ASUS ZenWiFi AX (XT8) (2x nodes) where devices intermittently disconnect and do not seem to be able to reconnect.

I observe that some security cameras and baby monitor disconnect from the router, and do not seem to be able to connect back until I reboot the device or router. This doesn’t happen for all the camera, but does appear to consistently affect the same ones.

In addition to this, I have observed that by Pixel 7 phone sometimes was constantly connecting and disconnecting from the network (i.e switching from wifi to 5g and back constantly). This behavior appeared around the same time as the other issue above.

This problem seems to have only started when I switched internet providers. Previously I was bridging the router to Virgin Media modem via its ethernet port. But now I am with Vodafone, and I am using one of the Asus nodes as a WAN PPPoE connection to the internet provider directly, using the ethernet port from my ONT, instead of using the Vodafone modem. Could it be related and causing my issues?

What I tried:
The router was using “Smart Connect”, however I since did a hard factory reset on both nodes, and then disabled “Smart Connect” and separated out the 2.5 and 5ghz networks. This seems to have fixed the constant disconnecting/reconnecting on my Pixel 7, and it connects to either the 2.4 or 5ghz, whichever has best signal. However, the cameras which only work on the 2.4ghz network have the issue remaining.

In my router logs, I see excessive entries for some MACs around:
(Note: I masked the MACs)

`Jan 6 16:21:09 wlceventd: wlceventd_proc_event(645): eth4: Deauth_ind 11:22:33:72:65:B9, status: 0, reason: Disassociated due to inactivity (4), rssi:-63
Jan 6 16:21:09 wlceventd: wlceventd_proc_event(645): eth4: Deauth_ind 11:22:33:72:65:B9, status: 0, reason: Previous authentication no longer valid (2), rssi:-63
Jan 6 16:21:10 wlceventd: wlceventd_proc_event(662): eth4: Disassoc 11:22:33:72:65:B9, status: 0, reason: Disassociated because sending station is leaving (or has left) BSS (8), rssi:0
Jan 6 16:21:20 wlceventd: wlceventd_proc_event(685): eth4: Auth 11:22:33:72:65:B9, status: Successful (0), rssi:0
Jan 6 16:21:20 wlceventd: wlceventd_proc_event(722): eth4: Assoc 11:22:33:72:65:B9, status: Successful (0), rssi:-57
Jan 6 16:21:49 wlceventd: wlceventd_proc_event(645): eth4: Deauth_ind 11:22:33:72:65:B9, status: 0, reason: Disassociated due to inactivity (4), rssi:-63
Jan 6 16:21:49 wlceventd: wlceventd_proc_event(645): eth4: Deauth_ind 11:22:33:72:65:B9, status: 0, reason: Previous authentication no longer valid (2), rssi:-63
Jan 6 16:21:50 wlceventd: wlceventd_proc_event(662): eth4: Disassoc 11:22:33:72:65:B9, status: 0, reason: Disassociated because sending station is leaving (or has left) BSS (8), rssi:0
Jan 6 16:22:25 wlceventd: wlceventd_proc_event(685): eth4: Auth 11:22:33:72:65:B9, status: Successful (0), rssi:0
Jan 6 16:22:25 wlceventd: wlceventd_proc_event(722): eth4: Assoc 11:22:33:72:65:B9, status: Successful (0), rssi:-58
Jan 6 16:22:47 wlceventd: wlceventd_proc_event(645): eth4: Deauth_ind 11:22:33:72:65:B9, status: 0, reason: Disassociated due to inactivity (4), rssi:-63
Jan 6 16:22:47 wlceventd: wlceventd_proc_event(645): eth4: Deauth_ind 11:22:33:72:65:B9, status: 0, reason: Previous authentication no longer valid (2), rssi:-63
Jan 6 16:22:48 wlceventd: wlceventd_proc_event(662): eth4: Disassoc 11:22:33:72:65:B9, status: 0, reason: Disassociated because sending station is leaving (or has left) BSS (8), rssi:0
Jan 6 16:23:44 wlceventd: wlceventd_proc_event(685): eth4: Auth 11:22:33:72:65:B9, status: Successful (0), rssi:0
Jan 6 16:23:44 wlceventd: wlceventd_proc_event(722): eth4: Assoc 11:22:33:72:65:B9, status: Successful (0), rssi:-58
Jan 6 16:24:10 wlceventd: wlceventd_proc_event(645): eth4: Deauth_ind 11:22:33:72:65:B9, status: 0, reason: Disassociated due to inactivity (4), rssi:-63
Jan 6 16:24:10 wlceventd: wlceventd_proc_event(645): eth4: Deauth_ind 11:22:33:72:65:B9, status: 0, reason: Previous authentication no longer valid (2), rssi:-63
Jan 6 16:24:11 wlceventd: wlceventd_proc_event(662): eth4: Disassoc 11:22:33:72:65:B9, status: 0, reason: Disassociated because sending station is leaving (or has left) BSS (8), rssi:0
Jan 6 16:24:49 wlceventd: wlceventd_proc_event(685): eth4: Auth 11:22:33:72:65:B9, status: Successful (0), rssi:0
Jan 6 16:24:49 wlceventd: wlceventd_proc_event(722): eth4: Assoc 11:22:33:72:65:B9, status: Successful (0), rssi:-58`

A count of the number of times Disassociated because sending station is leaving appears per MAC in the logs:

`➜ ~ grep ‘Disassociated because sending station is leaving’ router.txt | awk ‘{ print $8} ‘ | sort | uniq -c
2 11:22:33:4B:4A:0F,
3 11:22:33:72:45:31,
2 11:22:33:CF:6E:8E,
2 11:22:33:CF:73:D5,
2 11:22:33:CF:7D:49,
1 11:22:33:D3:A5:7E,
3 11:22:33:40:75:5D,
2 11:22:33:0B:A0:B6,
1 11:22:33:34:AA:F5,
4 11:22:33:3D:81:70,
225 11:22:33:72:65:B9,
2 11:22:33:AD:10:4D,
2 11:22:33:AF:6A:C5,
576 11:22:33:FE:25:07,
2 11:22:33:1C:31:89,
6 11:22:33:0A:76:87,
8 11:22:33:20:35:EE,
4 11:22:33:99:28:65,
6 11:22:33:62:5B:3B,
5 11:22:33:8E:61:3F,
5 11:22:33:FC:81:47,
5 11:22:33:0A:D3:1A,`

Is this a known problem? Is there anything else I can try? Could it be related to use the router for a WAN PPPoE connection?

Share the knowledge

• This topic was modified 5 months, 1 week ago by damo2k.
• This topic was modified 5 months, 1 week ago by damo2k.
• This topic was modified 5 months, 1 week ago by damo2k.

You need to login in order to vote

[UK Sentinel]

Is the Vodafone connection you have Full Fibre via an ONT ?

Ideally if you have two XT8’s, one should be set as AiMesh Primary and the other should be set as Node ?

How are the two XT8’s connected to each other (backhaul) ?

Share the knowledge

In a completely sane world, madness is the only freedom (J.G.Ballard).

You need to login in order to vote

[damo2k]

Yup its full fiber via an ONT. Yup I have one set as the primary, and the other as a node. The backhauls are connected via the 2nd 5Ghz network.

The only thing that has changed is that the Primary is now using PPPoE to the ONT directly, where as before it was simply connected to the ethernet port of the Virgin Media router that was in bridged-mode. This is when it seems the problems started. Maybe the XT8 has issues with operation and PPPoE.

Share the knowledge

You need to login in order to vote

[UK Sentinel]

Great, that all sounds correct, is the security cameras and baby monitor disconnects happen mainly when they are connected to the Primary or Node as we may be able to tweak those settings etc. ?

Are you using the latest ASUS ZenWiFi XT8 Firmware version 3.0.0.4.388_24688 or ASUS ZenWiFi XT8 V2 Firmware version 3.0.0.4.388_24684.

Share the knowledge

In a completely sane world, madness is the only freedom (J.G.Ballard).

You need to login in order to vote

[damo2k]

Most are connected to the Node. The baby monitor was connected to the primary up till tonight, as I since moved the monitor.

Both XT8 devices are on FW: 3.0.0.4.388_24684. I seem to have the V1 hardware. This issue seems to have remained across the last 1 or 2 firmware versions.

Share the knowledge

• This reply was modified 5 months, 1 week ago by damo2k.

You need to login in order to vote

[UK Sentinel]

Double check that if you could, If you have Hardware Version 1 then you should be using ASUS ZenWiFi XT8 Firmware version 3.0.0.4.388_24688 which is the latest release ?

Share the knowledge

In a completely sane world, madness is the only freedom (J.G.Ballard).

You need to login in order to vote

[damo2k]

On the bottom of both devices it shows HW Ver: 1 Is there anywhere else to check?

Share the knowledge

You need to login in order to vote

[UK Sentinel]

. damo2k Said:

On the bottom of both devices it shows HW Ver: 1 Is there anywhere else to check?

 

If you still have the original box, check the Box Label as the HW Version should be there also.

Edit: from what I recall, the ASUS ZenWiFi XT8 V2 hardware version was released from late 2022 or early 2023, what date is on your XT8 label ?

Share the knowledge

In a completely sane world, madness is the only freedom (J.G.Ballard).

You need to login in order to vote

[damo2k]

Yeah its HW version 1.0.

The labels on the bottom of the devices show a date of 2022, but show HW Ver: 1.0. The box also shows HW Ver: 1.0 with a date of 2022.

Also on the router terminal, I see similar:

admin@ZenWiFi_XT8-42E0:/# nvram show | grep HwVer
HwVer=1.0

admin@ZenWiFi_XT8-42E0:/# nvram show | grep DCode
DCode=20220215

Note: I have since upgraded the firmware to version: 3.0.0.4.388_24688-gf94212b

Share the knowledge

• This reply was modified 5 months, 1 week ago by damo2k.

You need to login in order to vote

[UK Sentinel]

Great news.

It will be interesting to see if you still have any wifi disconnects now Primary and Node are using the latest firmware.

Share the knowledge

In a completely sane world, madness is the only freedom (J.G.Ballard).

You need to login in order to vote

[damo2k]

I’m not feeling too optimistic about that, as I have experienced this issue across at least 2 previous firmware versions! I have a feeling the router is behaving unexpectedness since I started using it with PPPoE.

I will try using the original ISP modem/router for PPPoE at some stage and bridge to the Asus primary, should the problem return, to see if it makes any difference.

Share the knowledge

Liked by:

You need to login in order to vote

[damo2k]

Hmm not to long after firmware upgrade and rebooting, the issue came back! Trying the original setup will be the next step, i.e. switching back from wireless router mode to AP mode and bridging to the ISP router. Disappointing for such an expensive piece of kit.

Share the knowledge

• This reply was modified 5 months, 1 week ago by damo2k.

You need to login in order to vote

[UK Sentinel]

That is unfortunate, did you factory reset when you switched from Router connection to PPPoE, if you did then we can start looking at your Wifi settings etc.?

Edit: just noticed you have reached out over at SNB Forums, let those forum members assist you as there is a wealth of experience and I would not like to duplicate your efforts, feel free to come back if issue remains unresolved.

 

Share the knowledge

In a completely sane world, madness is the only freedom (J.G.Ballard).

You need to login in order to vote

[damo2k]

Yeah I did a hard factory reset on both devices when changing over to PPPoE. I even swapped the devices around. I.e. node to primary and primary to node and factory reset.

The static IP suggestion on SNB Forums unfortunately hasn’t improved the situation.

Share the knowledge

• This reply was modified 5 months, 1 week ago by damo2k.

Liked by:

You need to login in order to vote

[damo2k]

Ok so I applied some settings or configuration changes as recommended in the thread linked below and it seems to have resolved the issue. At least the system didn’t have the permanent disconnects for over 10 days now where as before they were coming back every few days.

I’m still not sure why these settings fix the issue, and why the issue only started since putting the primary node into PPPoE mode.

Here is the thread, and I have copied below in case it goes down or disappears.

• set Backhaul Connection Priority to “5GHz-2 Wifi first” (probably not relevant for you since you’re wired)
• set 2.4GHz bandwidth to 20MHz
• fix control channels on 2.4GHz/5GHz-1/5GHz-2 bands to 1, 36, and 149, respectively
• disable Universal Beamforming on all bands
• disable Roaming Assistant on 5GHz-2 band (again, probably not relevant for you since you’re not using it as backhaul)

Share the knowledge

You need to login in order to vote

[Author]

Posts