Forum Replies Created
-
AuthorPosts
-
Is there just a 20/40/80/ as would be a good option to see if the 160 is troublesome for yourself and maybe others for the more recent firmware releases ?
I have already reverted to offline beta 21101, if it also has the same issue I will try 20/40/80. This option is available for me, but I have now set it to 160 MHz only. This has always worked for me on 21101 and previous stable FW.
If this issues continues on 21011 I will try 20/40/80.
You need to login in order to vote
Mine is at 20/40/80/160 on the backhaul. This worked fine on previous firmware. Not sure what has changed from ASUS end.
You need to login in order to vote
I had reverted firmware from 21617 to 388.1 alpha 1, but similar issues were present (but not as bad). Now back to the offline beta 21101. The last ‘stable’ FW for me was 49873. May revert back to that at some point until ASUS sort this mess out.
You need to login in order to vote
Decided to test gnuton 388.1 alpha 1, cannot be any worse than official 21617…..

You need to login in order to vote
I am out tonight but just checked the link ASUS sent myself and it is no longer valid for that particular firmware. Sometimes to go forward you have to go back
Thanks, if it the link is gone I will revert to the last offline beta you shared. Come on ASUS, get your act together……


You need to login in order to vote
Happy to test. Thanks. What is different between the offline and the online 21617 available here?
After I spoke with ASUS, the new Offline seems pointless, (older revision number and less improvements) and ASUS agreed
Are you still able to share that new offline beta for testing?
The new release is proving to be very problematic for me with wireless backhaul connection issues once a day.
You need to login in order to vote
I will see what ASUS say, I am sure it is nothing to worry about and more annoying keep seeing that repetitive log message and would be interesting if others are seeing this also. But as you say, RMerlin is probable correct and relates to NAT accelerator and is meaningless to us users, but no harm in checking
That’s great! Thanks! I was surprised that no one else chimed in experiencing this. There is couple reports about it from last year but no real answers. https://www.snbforums.com/threads/asus-xt8-kernel-error-after-running-newest-beta-xt8-9-0-1-4-386_46197_gfc5aa34_nodpi-for-1-week.75946/
I do not get this continuously, which is why I haven’t taken notice at all. Twice in the log in 2 hours (again no idea what it means though):
Nov 24 20:38:22 kernel: ^[[0;33;41m[ERROR archer] archer_mcast_activate,577: ADD_PORT: WLAN SSID has already been added: egress_port 7, current 0x0002, new 0x0002^[[0m
Nov 24 20:47:01 kernel: ^[[0;33;41m[ERROR archer] archer_mcast_activate,577: ADD_PORT: WLAN SSID has already been added: egress_port 7, current 0x0002, new 0x0002^[[0m
You need to login in order to vote
hi all, Tried 3.0.0.4.388.21617 today, but reverted back to 3.0.0.4.386.49873.
- Several ‘Teams meeting’ dropouts
- Several RDP session dropouts.
reminds me of older firmwares that had the same issue. so, unfortunately : NOGO for me.
Interesting – I’m also on 21617 and have no issues with Teams. Consistently inconsistent!
Are you using wired or wireless backhaul?
You need to login in order to vote
Feedback sent, the wireless backhaul went down again and recovered. I mentioned you in the comments. The uptime did not reset.
Where all your XT8 using 21617 ?
Yes, all on latest official 21617
You need to login in order to vote
Can you send feedback this morning if possible and in comments box and detail UK Sentinel and time of issue, then let me know, as then I will let ASUS know? As you say, with four nodes, this is interesting (I think you are four nodes) ?
Feedback sent, the wireless backhaul went down again and recovered. I mentioned you in the comments. The uptime did not reset.
Yes, my setup is 4 XT8’s and wireless backhaul. With the beta 21101 (I think the one you shared) didn’t get any problems for 6+ days.
You need to login in order to vote
After exactly 1 day and 8 hours the wireless backhaul went down and then recovered. These are the logs for the time it happened, not sure if it shows anything, should I send feedback?
Nov 23 07:58:33 wlceventd: wlceventd_proc_event(530): eth5: Auth AA:45:C4:F8:E3:8A, status: Successful (0), rssi:-63
Nov 23 07:58:33 wlceventd: wlceventd_proc_event(540): eth5: ReAssoc AA:45:C4:F8:E3:8A, status: Successful (0), rssi:-63
Nov 23 07:58:39 roamast: [EXAP]Deauth old sta in 1 0: AA:45:C4:F8:E3:8A
Nov 23 07:58:39 roamast: eth5: disconnect weak signal strength station [aa:45:c4:f8:e3:8a]
Nov 23 07:58:39 roamast: eth5: remove client [aa:45:c4:f8:e3:8a] from monitor list
Nov 23 07:58:43 wlceventd: wlceventd_proc_event(494): eth5: Deauth_ind AA:45:C4:F8:E3:8A, status: 0, reason: Previous authentication no longer valid (2), rssi:-79
Nov 23 07:58:43 wlceventd: wlceventd_proc_event(494): eth5: Deauth_ind AA:45:C4:F8:E3:8A, status: 0, reason: Disassociated due to inactivity (4), rssi:-79
Nov 23 07:58:43 wlceventd: wlceventd_proc_event(494): eth5: Deauth_ind AA:45:C4:F8:E3:8A, status: 0, reason: Previous authentication no longer valid (2), rssi:-79
Nov 23 07:58:44 wlceventd: wlceventd_proc_event(511): eth5: Disassoc AA:45:C4:F8:E3:8A, status: 0, reason: Disassociated because sending station is leaving (or has left) BSS (8), rssi:0
Nov 23 08:05:14 wlceventd: wlceventd_proc_event(530): eth6: Auth FC:34:97:9A:C8:48, status: Successful (0), rssi:-84
Nov 23 08:05:14 wlceventd: wlceventd_proc_event(559): eth6: Assoc FC:34:97:9A:C8:48, status: Successful (0), rssi:-84
Nov 23 08:05:14 kernel: Register interface [wds2.0.1] MAC: fc:34:97:9b:0b:08
Nov 23 08:05:28 wlceventd: wlceventd_proc_event(530): eth4: Auth FC:34:97:9A:C8:41, status: Successful (0), rssi:0
Nov 23 08:05:28 wlceventd: wlceventd_proc_event(559): eth4: Assoc FC:34:97:9A:C8:41, status: Successful (0), rssi:-69
Nov 23 08:05:45 wlceventd: wlceventd_proc_event(511): wds2.0.1: Disassoc FC:34:97:9A:C8:48, status: 0, reason: Disassociated because sending station is leaving (or has left) BSS (8), rssi:0
Nov 23 08:05:45 wlceventd: wlceventd_proc_event(511): eth6: Disassoc FC:34:97:9A:C8:48, status: 0, reason: Disassociated because sending station is leaving (or has left) BSS (8), rssi:0
Nov 23 08:05:57 wlceventd: wlceventd_proc_event(511): wds0.0.1: Disassoc FC:34:97:9A:C8:41, status: 0, reason: Disassociated because sending station is leaving (or has left) BSS (8), rssi:0
Nov 23 08:05:57 kernel: Flushing net_device wds0.0.1.
Nov 23 08:05:57 wlceventd: wlceventd_proc_event(511): eth4: Disassoc FC:34:97:9A:C8:41, status: 0, reason: Disassociated because sending station is leaving (or has left) BSS (8), rssi:0
You need to login in order to vote
Weird that the latest update isn’t shown when you check via the router interface, but is via the Asus app!
Same here (NA version 1) 9.0.0.4.388_21493 is still running smoothly for me, 140MB free, backhaul is at 385hrs connected and my TP-Link switches and plugs are at 384hrs Going to hold off on updating for a bit to see how 3.0.0.4388_21617 plays out.
Is your setup with 2 or 4 XT8’s? It seems that there are more issues on 21493 with 4 x XT8’s.
You need to login in order to vote
Weird that the latest update isn’t shown when you check via the router interface, but is via the Asus app!
Same for me too, weird
You need to login in order to vote
@dodgydrains – ASUS have asked me if you would like to try another offline beta for the XT8 (not for sharing) ?
Happy to test. Thanks. What is different between the offline and the online 21617 available here?
https://dlcdnets.asus.com/pub/ASUS/wireless/ZenWiFi_XT8/FW_ZENWIFI_XT8_300438821617.zip
You need to login in order to vote
-
AuthorPosts
