ASUS ZenWiFi AX Whole Home Tri-Band Mesh WiFi 6 System Not sure if this is the right place to ask…. I am thinking of upgrading my Google Mesh wifi to the above. Has anyone used this and does it...

[dodgydrains]

Did some quick tests on the new FW 45934.  It increased my DL speed on the furthest node to 604Mbps (increase of 60Mbps).  Not complaining at all ……  Just need ASUS to implement the Teams fix.

Share the knowledge

Liked by:

You need to login in order to vote

[UK Sentinel]

Share the knowledge

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

You need to login in order to vote

[dodgydrains]

Nov 4 15:59:04 kernel: ^[[0;33;41m[ERROR archer] archer_mcast_activate,554: ADD_PORT: WLAN SSID has already been added: egress_port 7, current 0x0008, new 0x0008^[[0m

Any ideas what this error is?  Minute later got a whole bunch of crashlog and lost internet connection

May 5 06:05:18 crashlog: LOG
May 5 06:05:18 crashlog: kernel BUG at fs/jffs2/gc.c:375!
May 5 06:05:18 crashlog: Internal error: Oops – BUG: 0 [#1] PREEMPT SMP ARM

I haven’t seen this before, this is on FW 45934.

 

Share the knowledge

You need to login in order to vote

[UK Sentinel]

Looks like an internal kernel is crashing or simular, usual a full factory reset cures these types of faults if it is not a coding error.

BTW: whats after ‘May 5 06:05:18 crashlog: Internal error: Oops – BUG: 0 [#1] PREEMPT SMP ARM ‘ ?

 

Share the knowledge

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

You need to login in order to vote

[dodgydrains]

Does this help?  Anything there in the logs that people can use to hack me?

ay 5 06:05:18 crashlog: LOG
May 5 06:05:18 crashlog: kernel BUG at fs/jffs2/gc.c:375!
May 5 06:05:18 crashlog: Internal error: Oops – BUG: 0 [#1] PREEMPT SMP ARM
May 5 06:05:18 crashlog: Modules linked in: nf_nat_sip init_addr( (null) – (null)), core_addr(bf126000 – bf1276d0)
May 5 06:05:18 crashlog: nf_conntrack_sip init_addr( (null) – (null)), core_addr(bf0fb000 – bf0fddbc)
May 5 06:05:18 crashlog: nf_nat_h323 init_addr( (null) – (null)), core_addr(bf0f6000 – bf0f6f50)
May 5 06:05:18 crashlog: nf_conntrack_h323 init_addr( (null) – (null)), core_addr(bf0aa000 – bf0ad8d4)
May 5 06:05:18 crashlog: nf_nat_rtsp init_addr( (null) – (null)), core_addr(bf02e000 – bf02e830)
May 5 06:05:18 crashlog: nf_conntrack_rtsp init_addr( (null) – (null)), core_addr(bf02b000 – bf02c208)
May 5 06:05:18 crashlog: nf_nat_ftp init_addr( (null) – (null)), core_addr(bf010000 – bf010228)
May 5 06:05:18 crashlog: nf_conntrack_ftp init_addr( (null) – (null)), core_addr(bf005000 – bf005b88)
May 5 06:05:18 crashlog: ip6table_nat init_addr( (null) – (null)), core_addr(bfbdc000 – bfbdc078)
May 5 06:05:18 crashlog: xt_length init_addr( (null) – (null)), core_addr(bfbd8000 – bfbd80b4)
May 5 06:05:18 crashlog: ath3k init_addr( (null) – (null)), core_addr(bfbd2000 – bfbd2888)
May 5 06:05:18 crashlog: btusb init_addr( (null) – (null)), core_addr(bfbc6000 – bfbc9ff4)
May 5 06:05:18 crashlog: btintel init_addr( (null) – (null)), core_addr(bfbc2000 – bfbc2198)
May 5 06:05:18 crashlog: thfsplus(O) init_addr( (null) – (null)), core_addr(bfba6000 – bfbb1c10)
May 5 06:05:18 crashlog: tntfs(PO) init_addr( (null) – (null)), core_addr(bfb1f000 – bfb6d8fc)
May 5 06:05:18 crashlog: tfat(PO) init_addr( (null) – (null)), core_addr(bfad0000 – bfb01f54)
May 5 06:05:18 crashlog: uas init_addr( (null) – (null)), core_addr(bfac9000 – bfacad48)
May 5 06:05:18 crashlog: usb_storage init_addr( (null) – (null)), core_addr(bfab6000 – bfab9820)
May 5 06:05:18 crashlog: sg init_addr( (null) – (null)), core_addr(bfaab000 – bfaaee80)
May 5 06:05:18 crashlog: sd_mod init_addr( (null) – (null)), core_addr(bfa9f000 – bfaa3840)
May 5 06:05:18 crashlog: scsi_mod init_addr( (null) – (null)), core_addr(bfa70000 – bfa7ea54)
May 5 06:05:18 crashlog: cdc_mbim init_addr( (null) – (null)), core_addr(bfa6b000 – bfa6ba70)
May 5 06:05:18 crashlog: qmi_wwan init_addr( (null) – (null)), core_addr(bfa62000 – bfa62674)
May 5 06:05:18 crashlog: cdc_wdm init_addr( (null) – (null)), core_addr(bfa5d000 – bfa5e5b8)
May 5 06:05:18 crashlog: cdc_ncm init_addr( (null) – (null)), core_addr(bfa55000 – bfa56fb8)
May 5 06:05:18 crashlog: rndis_host init_addr( (null) – (null)), core_addr(bfa50000 – bfa50b0c)
May 5 06:05:18 crashlog: cdc_ether init_addr( (null) – (null)), core_addr(bfa4c000 – bfa4c77c)
May 5 06:05:18 crashlog: ax88179_178a init_addr( (null) – (null)), core_addr(bfa44000 – bfa46544)
May 5 06:05:18 crashlog: asix init_addr( (null) – (null)), core_addr(bfa3b000 – bfa3d510)
May 5 06:05:18 crashlog: libphy init_addr( (null) – (null)), core_addr(bfa30000 – bfa32f84)
May 5 06:05:18 crashlog: cdc_acm init_addr( (null) – (null)), core_addr(bfa27000 – bfa291fc)

It carries on and on……

Share the knowledge

You need to login in order to vote

[UK Sentinel]

Nothing hack-able

I am not an expert, but does seem ARM (Broadcom related) so either wireless or CPU .

Either way, if this keeps happening, a factory reset is advisable.

Share the knowledge

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

You need to login in order to vote

[dodgydrains]

Done a factory reset again just in case.  Also sent logs to ASUS.

Share the knowledge

You need to login in order to vote

[UK Sentinel]

Perfect, take the rest of the day off

Share the knowledge

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

You need to login in order to vote

[Jacky Decoster]

tried latest official 45934. unfortunately, the usuall problems arise again : teams interruptions, RDP sessions disconnects…

back on ‘safe’ 42095 again, because with beta 46197, I experienced crashes after a couple of days of stability -> needed to completely reboot.

 

Share the knowledge

You need to login in order to vote

[UK Sentinel]

A missed opportunity by ASUS

Share the knowledge

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

You need to login in order to vote

[dodgydrains]

If anyone is interested in testing ASUSWRT 386 RC3-3 public beta:

https://drive.google.com/drive/folders/1zbP67c9LM-je_w3PEc36ybc_VFddJPPe

@UKSentinel, any ideas when the Teams fix will be implemented to stable FW?  I sent an email asking, but no reply.

Share the knowledge

You need to login in order to vote

[UK Sentinel]

Thanks for the link, where did you get the link from, just interested I am ?

Alas no idea regarding Teams fix , I can ask but do try to avoid annoying ASUS to much as they are busy ?

Share the knowledge

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

You need to login in order to vote

[dodgydrains]

UK Sentinel wrote:

Thanks for the link, where did you get the link from, just interested I am ?

Got it from ASUSWRT_2020 who usually posts it here:

https://www.snbforums.com/threads/asuswrt-386-rc3-3-public-beta-for-ipv6-ddns-and-ipv6-vpn-server.75829/#post-725294

Share the knowledge

You need to login in order to vote

[UK Sentinel]

Perfect – just making sure the link source was good

Good to see these betas cover :

support model list
GT-AX11000
RT-AX92U
RT-AX82U
RT-AX68U
RT-AX56U
RT-AX55
TUF-AX5400
TUF-AX3000
ZenWiFi ET8
ZenWiFi XT8
ZenWiFi XD6
ZenWiFi XD4

Share the knowledge

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

You need to login in order to vote

[Jonathan Morris]

I realise it’s been a bit quiet of late, but my wife has been working from home more recently due to us contracting Covid and isolating.

She hasn’t really told me much about any issues she’s had before, but did pipe up that she’s getting kicked off Team calls every day she’s had them since last week (not weekend) – sometimes 2 or 3 times.

Thing is, she has calls throughout the day but she said it always happens around 1600 lor after and now it has happened again, so this leaves me wondering what could be causing an issue at a specific time of day? I’ll need to investigate further, like how long her calls are and how long from starting to dropping etc etc.

Due to the issue of sometimes having the mesh lock on at 2.4GHz, it is set to reboot at 0400 every day. So, this means the issue happens around 12 hours later. Could this be a factor? A fault related to uptime? I might change it so it reboots later, and see if that causes the issues to happen later (bit of a longshot, but sometimes this is the only way to find the smoking gun).

I’m looking through the log and can see reference to a radar detection at 1549 (but nothing else thereafter), so I’m going to keep an eye out on what it does tomorrow. That could also be related, although it happens over 10 minutes before anything else as per the log:

 

Dec 7 15:49:54 amas_adtbw: [ADTBW]Radar detected, wait for radar timeout
Dec 7 16:01:48 wlceventd: wlceventd_proc_event(508): eth5: Disassoc D2:1C:C6:A9:1B:CB, status: 0, reason: Unspecified reason (1), rssi:0
Dec 7 16:01:48 wlceventd: wlceventd_proc_event(508): eth5: Disassoc D2:1C:C6:A9:1B:CB, status: 0, reason: Disassociated because sending station is leaving (or has left) BSS (8), rssi:0
Dec 7 16:01:50 wlceventd: wlceventd_proc_event(556): eth5: Assoc D2:1C:C6:A9:1B:CB, status: Successful (0), rssi:-66
Dec 7 16:03:02 wlceventd: wlceventd_proc_event(508): eth5: Disassoc 92:01:0F:02:A4:FB, status: 0, reason: Unspecified reason (1), rssi:0
Dec 7 16:03:02 wlceventd: wlceventd_proc_event(508): eth5: Disassoc 92:01:0F:02:A4:FB, status: 0, reason: Disassociated because sending station is leaving (or has left) BSS (8), rssi:0
Dec 7 16:03:04 wlceventd: wlceventd_proc_event(556): eth5: Assoc 92:01:0F:02:A4:FB, status: Successful (0), rssi:-66
Dec 7 16:03:14 wlceventd: wlceventd_proc_event(508): eth5: Disassoc 50:8E:49:46:B0:A4, status: 0, reason: Unspecified reason (1), rssi:0
Dec 7 16:03:14 wlceventd: wlceventd_proc_event(508): eth5: Disassoc 50:8E:49:46:B0:A4, status: 0, reason: Disassociated because sending station is leaving (or has left) BSS (8), rssi:0
Dec 7 16:03:16 wlceventd: wlceventd_proc_event(556): eth5: Assoc 50:8E:49:46:B0:A4, status: Successful (0), rssi:-63
Dec 7 16:03:59 roamast: sta 50:8E:49:46:B0:A4 ap F0:2F:74:8D:C3:F4 rcpi 44
Dec 7 16:03:59 roamast: after rssi -88
Dec 7 16:03:59 roamast: sta 50:8E:49:46:B0:A4 ap F0:2F:74:8D:C3:84 rcpi 98
Dec 7 16:03:59 roamast: after rssi -61
Dec 7 16:04:04 roamast: sta 50:8E:49:46:B0:A4 ap F0:2F:74:8D:C3:F4 rcpi 44
Dec 7 16:04:04 roamast: after rssi -88
Dec 7 16:04:04 roamast: sta 50:8E:49:46:B0:A4 ap F0:2F:74:8D:C3:84 rcpi 98
Dec 7 16:04:04 roamast: after rssi -61
Dec 7 16:04:14 roamast: sta 50:8E:49:46:B0:A4 ap F0:2F:74:8D:C3:F4 rcpi 44
Dec 7 16:04:14 roamast: after rssi -88
Dec 7 16:04:14 roamast: sta 50:8E:49:46:B0:A4 ap F0:2F:74:8D:C3:84 rcpi 98
Dec 7 16:04:14 roamast: after rssi -61
Dec 7 16:04:24 roamast: sta 50:8E:49:46:B0:A4 ap F0:2F:74:8D:C3:F4 rcpi 44
Dec 7 16:04:24 roamast: after rssi -88
Dec 7 16:04:24 roamast: sta 50:8E:49:46:B0:A4 ap F0:2F:74:8D:C3:84 rcpi 98
Dec 7 16:04:24 roamast: after rssi -61
Dec 7 16:04:44 roamast: sta 50:8E:49:46:B0:A4 ap F0:2F:74:8D:C3:F4 rcpi 46
Dec 7 16:04:44 roamast: after rssi -87
Dec 7 16:04:44 roamast: sta 50:8E:49:46:B0:A4 ap F0:2F:74:8D:C3:84 rcpi 98
Dec 7 16:04:44 roamast: after rssi -61
Dec 7 16:04:49 roamast: sta 50:8E:49:46:B0:A4 ap F0:2F:74:8D:C3:F4 rcpi 46
Dec 7 16:04:49 roamast: after rssi -87
Dec 7 16:04:49 roamast: sta 50:8E:49:46:B0:A4 ap F0:2F:74:8D:C3:84 rcpi 98
Dec 7 16:04:49 roamast: after rssi -61
Dec 7 16:04:54 roamast: sta 50:8E:49:46:B0:A4 ap F0:2F:74:8D:C3:F4 rcpi 46
Dec 7 16:04:54 roamast: after rssi -87
Dec 7 16:04:54 roamast: sta 50:8E:49:46:B0:A4 ap F0:2F:74:8D:C3:84 rcpi 98
Dec 7 16:04:54 roamast: after rssi -61
Dec 7 16:05:04 roamast: sta 50:8E:49:46:B0:A4 ap F0:2F:74:8D:C3:F4 rcpi 44
Dec 7 16:05:04 roamast: after rssi -88
Dec 7 16:05:04 roamast: sta 50:8E:49:46:B0:A4 ap F0:2F:74:8D:C3:84 rcpi 98
Dec 7 16:05:04 roamast: after rssi -61
Dec 7 16:05:14 roamast: sta 50:8E:49:46:B0:A4 ap F0:2F:74:8D:C3:F4 rcpi 46
Dec 7 16:05:14 roamast: after rssi -87
Dec 7 16:05:14 roamast: sta 50:8E:49:46:B0:A4 ap F0:2F:74:8D:C3:84 rcpi 100
Dec 7 16:05:14 roamast: after rssi -60
Dec 7 16:11:34 wlceventd: wlceventd_proc_event(508): wds2.0.1: Disassoc F0:2F:74:8D:C3:F8, status: 0, reason: Disassociated because sending station is leaving (or has left) BSS (8), rssi:0
Dec 7 16:11:34 kernel: Virtual device br0 asks to queue packet!
Dec 7 16:11:34 kernel: Virtual device br0 asks to queue packet!

Share the knowledge

You need to login in order to vote

[Author]

Posts