What's new

Release Asuswrt-Merlin 386.1 is now available

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

Status
Not open for further replies.
Wrong interface? On my AX88 5G WLAN is on eth7 and 2.4G on eth6 and wl commands works fine there..
Did you enable wl0.1 (guest network)? There are currently some (logging) issues with guest 1 - maybe you run into another problem... :rolleyes:
Whoops, you're right, I disabled Guest Network 1 due to the log spamming. Already had forgotten, thanks.
 
Currently not on my local network and can't log in remotely on my router via SSH (though I thought I enabled that).

I did enable it, but as soon as I log out and back in again it reverts to “LAN only”.

Is this a known bug of this release? (On AC86u)
 
I'm facing a problem with RT-AC86U where the devices is unable to connect to 2.4GHz after a certain time (from days to weeks). I can see the SSID but it just refused to connect.
I have no problem with 5GHz. This issues seems to begin from 384.18 onwards and now I'm on 386.1_2 and it's still happening.
By the time I notice the problem and view the logs, its already rolled over.

Any method or any logs I can check for the issue?


Code:
Feb 20 14:46:00 wlceventd: wlceventd_proc_event(526): eth5: Auth B0:95:75:70:B0:4E, status: Successful (0), rssi:0
Feb 20 14:46:00 wlceventd: wlceventd_proc_event(490): eth5: Deauth_ind 84:D8:1B:20:A6:8F, status: 0, reason: Class 2 frame received from nonauthenticated station (6), rssi:0
Feb 20 14:46:00 wlceventd: wlceventd_proc_event(526): eth5: Auth 84:D8:1B:20:A6:8F, status: Successful (0), rssi:0
Feb 20 14:46:00 wlceventd: wlceventd_proc_event(490): eth5: Deauth_ind B0:95:75:70:B0:4E, status: 0, reason: Class 2 frame received from nonauthenticated station (6), rssi:0
Feb 20 14:46:00 wlceventd: wlceventd_proc_event(526): eth5: Auth B0:95:75:70:B0:4E, status: Successful (0), rssi:0
Feb 20 14:46:00 wlceventd: wlceventd_proc_event(490): eth5: Deauth_ind 84:D8:1B:20:A6:8F, status: 0, reason: Class 2 frame received from nonauthenticated station (6), rssi:0
Feb 20 14:46:00 wlceventd: wlceventd_proc_event(526): eth5: Auth 84:D8:1B:20:A6:8F, status: Successful (0), rssi:0
Feb 20 14:46:00 wlceventd: wlceventd_proc_event(526): eth5: Auth 28:6C:07:B9:00:A2, status: Successful (0), rssi:0
Feb 20 14:46:00 wlceventd: wlceventd_proc_event(526): eth5: Auth 28:6C:07:B9:00:A2, status: Successful (0), rssi:0
Feb 20 14:46:00 wlceventd: wlceventd_proc_event(490): eth5: Deauth_ind B0:95:75:70:B0:4E, status: 0, reason: Class 2 frame received from nonauthenticated station (6), rssi:0
Feb 20 14:46:00 wlceventd: wlceventd_proc_event(526): eth5: Auth 28:6C:07:B9:00:A2, status: Successful (0), rssi:0
Feb 20 14:46:00 wlceventd: wlceventd_proc_event(490): eth5: Deauth_ind 84:D8:1B:20:A6:8F, status: 0, reason: Class 2 frame received from nonauthenticated station (6), rssi:0
Feb 20 14:46:00 wlceventd: wlceventd_proc_event(526): eth5: Auth 84:D8:1B:20:A6:8F, status: Successful (0), rssi:0
Feb 20 14:46:01 wlceventd: wlceventd_proc_event(490): eth5: Deauth_ind 84:D8:1B:20:A6:8F, status: 0, reason: Class 2 frame received from nonauthenticated station (6), rssi:0
Feb 20 14:46:01 wlceventd: wlceventd_proc_event(526): eth5: Auth 84:D8:1B:20:A6:8F, status: Successful (0), rssi:0
Feb 20 14:46:01 wlceventd: wlceventd_proc_event(526): eth5: Auth 00:03:7F:77:0D:76, status: Successful (0), rssi:0
Feb 20 14:46:01 wlceventd: wlceventd_proc_event(526): eth5: Auth B0:95:75:70:B0:4E, status: Successful (0), rssi:0
Feb 20 14:46:01 wlceventd: wlceventd_proc_event(526): eth5: Auth 00:03:7F:77:0D:76, status: Successful (0), rssi:0
Feb 20 14:46:01 wlceventd: wlceventd_proc_event(490): eth5: Deauth_ind 84:D8:1B:20:A6:8F, status: 0, reason: Class 2 frame received from nonauthenticated station (6), rssi:0
Feb 20 14:46:01 wlceventd: wlceventd_proc_event(526): eth5: Auth 84:D8:1B:20:A6:8F, status: Successful (0), rssi:0
Feb 20 14:46:01 wlceventd: wlceventd_proc_event(526): eth5: Auth 00:03:7F:77:0D:76, status: Successful (0), rssi:0
Feb 20 14:46:01 wlceventd: wlceventd_proc_event(490): eth5: Deauth_ind B0:95:75:70:B0:4E, status: 0, reason: Class 2 frame received from nonauthenticated station (6), rssi:0
Feb 20 14:46:01 wlceventd: wlceventd_proc_event(526): eth5: Auth B0:95:75:70:B0:4E, status: Successful (0), rssi:0
Feb 20 14:46:01 wlceventd: wlceventd_proc_event(490): eth5: Deauth_ind 84:D8:1B:20:A6:8F, status: 0, reason: Class 2 frame received from nonauthenticated station (6), rssi:0
Feb 20 14:46:01 wlceventd: wlceventd_proc_event(526): eth5: Auth 34:CE:00:FB:63:2C, status: Successful (0), rssi:0
Feb 20 14:46:01 wlceventd: wlceventd_proc_event(490): eth5: Deauth_ind B0:95:75:70:B0:4E, status: 0, reason: Class 2 frame received from nonauthenticated station (6), rssi:0
Feb 20 14:46:01 wlceventd: wlceventd_proc_event(526): eth5: Auth B0:95:75:70:B0:4E, status: Successful (0), rssi:0
Feb 20 14:46:01 wlceventd: wlceventd_proc_event(526): eth5: Auth 34:CE:00:FB:63:2C, status: Successful (0), rssi:0
Feb 20 14:46:02 wlceventd: wlceventd_proc_event(526): eth5: Auth 34:CE:00:FB:63:2C, status: Successful (0), rssi:0
Feb 20 14:46:02 wlceventd: wlceventd_proc_event(490): eth5: Deauth_ind B0:95:75:70:B0:4E, status: 0, reason: Class 2 frame received from nonauthenticated station (6), rssi:0
Feb 20 14:46:02 wlceventd: wlceventd_proc_event(526): eth5: Auth B0:95:75:70:B0:4E, status: Successful (0), rssi:0
Feb 20 14:46:02 wlceventd: wlceventd_proc_event(526): eth5: Auth 84:D8:1B:20:A6:8F, status: Successful (0), rssi:0
Try manually assigning your 2.4 MHz channel to the one with the least signal. I had this problem with my IoT Nexx Garage Opener until did that.
 
I did enable it, but as soon as I log out and back in again it reverts to “LAN only”.

Is this a known bug of this release? (On AC86u)

Apparently this is configured by nvram variable sshd_enable.

Even after setting it manually to 1 ("LAN & WAN") via SSH (and restarting sshd), I cannot log in via SSH remotely.

EDIT: I can log in remotely via SSH once and then the variable sshd_enable is reset to 2... remote log in via SSH fails again.

Can somebody else please test/verify this?
 
Last edited:
OOPS: I forgot that I had done a factory reset and Skynet was still set to Secure Mode (which disables WAN access).

However, even disabling Secure Mode does not help.

EDIT: Seems solved after upgrading to 386.1 Alpha 2 and/or unbanning my (external) IP in Skynet?
 
Last edited:
Everything fine except my Swann Security Cameras lag and drop out, any suggestions on how to fix?

I think I'll go back to 384.18, I found no issues with this version compared to the new versions.
 
I've got a fan setup like those for one of my AC86Us. I also have another AC86U with the fan in the link below. It snaps in place rather than requiring tape, screws or velcro. And it has an adjustable speed and dust filter. Its very nifty. Delivery time was much faster than indicated on the Amazon website.

https://www.amazon.com/gp/product/B07XDGXWC3/?tag=snbforums-20
This looks great! I noticed one of the reviews says this fan did not fit on the AC2900 (AC86u). Can you confirm you are using this fan as intended by snapping in place on a RT-AC86u? I just wanted to check before placing an order. Any idea how many degrees this dropped your CPU temperature? Thanks for your help!
 
This looks great! I noticed one of the reviews says this fan did not fit on the AC2900 (AC86u). Can you confirm you are using this fan as intended by snapping in place on a RT-AC86u? I just wanted to check before placing an order. Any idea how many degrees this dropped your CPU temperature? Thanks for your help!

Yes, it fits my AC86U as intended, and the air flow ports on the back of the router match up with the air flow ports on the fan assembly. The GT-AC2900 has different air flow ports.


 
Try manually assigning your 2.4 MHz channel to the one with the least signal. I had this problem with my IoT Nexx Garage Opener until did that.
Normally I’ll just fixed to channel 1 after the initial reset. Will try to fixed it to other channel and see if this is still happening.
 
My AI Mesh node doesnt connect to the main router since this morning.
Not sure if related to this firmware or a different bug though.
I have a AX-86U as main router and use a AX-58U as wired node for the upper levels of my house.
Just started work and noticed i had a weak WiFi signal on the laptop.
I can ping the IP of the Mesh node, i can access the webgui of the node but its states it cant reach the Mesh router, wich is strange as my client can reach the node through the router.
1613980445878.png

I dont see anyhting in the logs of the router about a connection attempt of the node.
Rebooting the node from the router AIMesh menu actually reboots the node, so the connection from the router to the node seems to work.

Code:
-FB40 kernel: eth3 (Ext switch port: 2) (Logical Port: 10) (phyId: a) Link DOWN.
Feb 22 08:55:36 RT-AX86U-FB40 kernel: br0: port 2(eth3) entered disabled state
Feb 22 08:55:36 RT-AX86U-FB40 kernel: _blog_emit, blogp = 0x23c0
SNIP BLOG EMIT
Feb 22 08:55:42 RT-AX86U-FB40 kernel: _blog_emit, blogp = 0x23c0
Feb 22 08:55:42 RT-AX86U-FB40 kernel: eth3 (Ext switch port: 2) (Logical Port: 10) (phyId: a) Link Up at 1000 mbps full duplex
Feb 22 08:55:42 RT-AX86U-FB40 kernel: br0: port 2(eth3) entered listening state
Feb 22 08:55:42 RT-AX86U-FB40 kernel: br0: port 2(eth3) entered listening state
Feb 22 08:55:44 RT-AX86U-FB40 kernel: _blog_emit, blogp = 0x23c0
Feb 22 08:55:44 RT-AX86U-FB40 kernel: _blog_emit, blogp = 0x23c0
Feb 22 08:55:44 RT-AX86U-FB40 kernel: br0: port 2(eth3) entered learning state
Feb 22 08:55:45 RT-AX86U-FB40 kernel: _blog_emit, blogp = 0x22a0
Feb 22 08:55:45 RT-AX86U-FB40 kernel: _blog_emit, blogp = 0x2360
Feb 22 08:55:46 RT-AX86U-FB40 kernel: br0: topology change detected, propagating
Feb 22 08:55:46 RT-AX86U-FB40 kernel: br0: port 2(eth3) entered forwarding state
Feb 22 08:55:48 RT-AX86U-FB40 kernel: eth3 (Ext switch port: 2) (Logical Port: 10) (phyId: a) Link DOWN.
Feb 22 08:55:48 RT-AX86U-FB40 kernel: br0: port 2(eth3) entered disabled state
Feb 22 08:55:48 RT-AX86U-FB40 kernel: _blog_emit, blogp = 0x1b68
SNIP BLOG EMIT
Feb 22 08:55:56 RT-AX86U-FB40 kernel: _blog_emit, blogp = 0x23c0
Feb 22 08:56:00 RT-AX86U-FB40 kernel: eth3 (Ext switch port: 2) (Logical Port: 10) (phyId: a) Link Up at 1000 mbps full duplex
Feb 22 08:56:00 RT-AX86U-FB40 kernel: _blog_emit, blogp = 0x22c0
Feb 22 08:56:00 RT-AX86U-FB40 kernel: br0: port 2(eth3) entered listening state
Feb 22 08:56:00 RT-AX86U-FB40 kernel: br0: port 2(eth3) entered listening state
Feb 22 08:56:01 RT-AX86U-FB40 hostapd: eth7: STA 40:2f:86:XX:XX:XX WPA: group key handshake completed (RSN)
Feb 22 08:56:01 RT-AX86U-FB40 hostapd: eth7: STA e4:a7:a0:XX:XX:XX WPA: group key handshake completed (RSN)
Feb 22 08:56:01 RT-AX86U-FB40 hostapd: eth7: STA 44:07:0b:XX:XX:XX WPA: group key handshake completed (RSN)
Feb 22 08:56:01 RT-AX86U-FB40 hostapd: eth7: STA 88:d0:39:XX:XX:XX WPA: group key handshake completed (RSN)
Feb 22 08:56:01 RT-AX86U-FB40 hostapd: eth7: STA 14:c1:4e:XX:XX:XX WPA: group key handshake completed (RSN)
Feb 22 08:56:01 RT-AX86U-FB40 hostapd: eth6: STA 04:cf:8c:XX:XX:XX WPA: group key handshake completed (RSN)
Feb 22 08:56:01 RT-AX86U-FB40 hostapd: eth7: STA 64:a2:f9:XX:XX:XX WPA: group key handshake completed (RSN)
Feb 22 08:56:01 RT-AX86U-FB40 kernel: CONSOLE: 147202.488 tx:prep:802.1x
Feb 22 08:56:01 RT-AX86U-FB40 kernel: CONSOLE: 147202.488 tx:prep:802.1x
Feb 22 08:56:01 RT-AX86U-FB40 kernel: CONSOLE: 147202.489 tx:prep:802.1x
Feb 22 08:56:01 RT-AX86U-FB40 kernel: CONSOLE: 147202.489 tx:prep:802.1x
Feb 22 08:56:01 RT-AX86U-FB40 kernel: CONSOLE: 147202.489 tx:prep:802.1x
Feb 22 08:56:01 RT-AX86U-FB40 kernel: CONSOLE: 147202.590 tx:prep:802.1x
Feb 22 08:56:01 RT-AX86U-FB40 hostapd: eth7: STA c0:ee:fb:XX:XX:XX WPA: group key handshake completed (RSN)
Feb 22 08:56:02 RT-AX86U-FB40 kernel: CONSOLE: 147202.693 tx:prep:802.1x
Feb 22 08:56:02 RT-AX86U-FB40 kernel: _blog_emit, blogp = 0x23c0
Feb 22 08:56:02 RT-AX86U-FB40 kernel: _blog_emit, blogp = 0x23c0
Feb 22 08:56:02 RT-AX86U-FB40 hostapd: eth7: STA 28:c2:1f:XX:XX:XX WPA: group key handshake completed (RSN)
Feb 22 08:56:02 RT-AX86U-FB40 kernel: CONSOLE: 147203.191 tx:prep:802.1x
Feb 22 08:56:02 RT-AX86U-FB40 kernel: br0: port 2(eth3) entered learning state
Feb 22 08:56:04 RT-AX86U-FB40 kernel: br0: topology change detected, propagating
Feb 22 08:56:04 RT-AX86U-FB40 kernel: br0: port 2(eth3) entered forwarding state
Feb 22 08:56:05 RT-AX86U-FB40 kernel: _blog_emit, blogp = 0x22a0
Feb 22 08:56:12 RT-AX86U-FB40 kernel: _blog_emit, blogp = 0x23c0
Feb 22 08:56:12 RT-AX86U-FB40 kernel: _blog_emit, blogp = 0x23c0
Feb 22 08:56:13 RT-AX86U-FB40 kernel: device br0 entered promiscuous mode
Feb 22 08:56:17 RT-AX86U-FB40 kernel: _blog_emit, blogp = 0x1b88
SNIP BLOG EMIT
Feb 22 08:56:18 RT-AX86U-FB40 kernel: _blog_emit, blogp = 0x23c0
Feb 22 08:56:19 RT-AX86U-FB40 kernel: device br0 left promiscuous mode
Feb 22 08:56:21 RT-AX86U-FB40 kernel: _blog_emit, blogp = 0x23c0
Feb 22 08:56:21 RT-AX86U-FB40 kernel: _blog_emit, blogp = 0x23c0
Feb 22 08:56:26 RT-AX86U-FB40 kernel: _blog_emit, blogp = 0x1c28
Feb 22 08:56:30 RT-AX86U-FB40 kernel: CONSOLE: 147231.041 wl1: wlc_ampdu_recv_addba_resp: 44:07:0b:XX:XX:XX: Failed. status 37 wsize 64 policy 1
Feb 22 08:56:32 RT-AX86U-FB40 kernel: _blog_emit, blogp = 0x2
SNIP BLOG EMIT
Feb 22 08:57:09 RT-AX86U-FB40 kernel: _blog_emit, blogp = 0x2380
Feb 22 08:57:10 RT-AX86U-FB40 kernel: CONSOLE: 147270.640 wl1.0: wlc_send_bar: for 40:2f:86:XX:XX:XX seq 0x846 tid 0
Feb 22 08:57:11 RT-AX86U-FB40 kernel: _blog_emit, blogp = 0x1ac8
Feb 22 08:57:13 RT-AX86U-FB40 kernel: _blog_emit, blogp = 0x23c0
Feb 22 08:57:18 RT-AX86U-FB40 kernel: CONSOLE: 147278.401 wl1.0: wlc_send_bar: for 14:c1:4e:XX:XX:XX seq 0xedf tid 6
Feb 22 08:57:25 RT-AX86U-FB40 kernel: _blog_emit, blogp = 0x22e0
SNIP BLOG EMIT
Feb 22 08:57:30 RT-AX86U-FB40 kernel: _blog_emit, blogp = 0x22e0
Feb 22 08:57:30 RT-AX86U-FB40 kernel: CONSOLE: 147290.790 wl1: wlc_ampdu_recv_addba_resp: 44:07:0b:XX:XX:XX: Failed. status 37 wsize 64 policy 1
Feb 22 08:57:38 RT-AX86U-FB40 kernel: _blog_emit, blogp = 0x2
SNIP BLOG EMIT
Feb 22 08:57:54 RT-AX86U-FB40 kernel: _blog_emit, blogp = 0x23c0
Feb 22 08:57:59 RT-AX86U-FB40 kernel: CONSOLE: 147320.112 wl1.0: wlc_send_bar: for 14:c1:4e:XX:XX:XX seq 0xf2e tid 6
Feb 22 08:57:59 RT-AX86U-FB40 kernel: CONSOLE: 147320.113 wl1.0: wlc_send_bar: for 14:c1:4e:XX:XX:XX seq 0xf2e tid 6

EDIT:
Just rebooted everything and still the same problem.
Looking at my WiFi networks i can now also see the Open ASUS network and from the strength i assume its the AX58U.
But im not able to actually connect too it
 
Last edited:
My AI Mesh node doesnt connect to the main router since this morning.
Not sure if related to this firmware or a different bug though.
I have a AX-86U as main router and use a AX-58U as wired node for the upper levels of my house.
Just started work and noticed i had a weak WiFi signal on the laptop.
I can ping the IP of the Mesh node, i can access the webgui of the node but its states it cant reach the Mesh router, wich is strange as my client can reach the node through the router.
View attachment 31074
I dont see anyhting in the logs of the router about a connection attempt of the node.
Rebooting the node from the router AIMesh menu actually reboots the node, so the connection from the router to the node seems to work.

Code:
-FB40 kernel: eth3 (Ext switch port: 2) (Logical Port: 10) (phyId: a) Link DOWN.
Feb 22 08:55:36 RT-AX86U-FB40 kernel: br0: port 2(eth3) entered disabled state
Feb 22 08:55:36 RT-AX86U-FB40 kernel: _blog_emit, blogp = 0x23c0
SNIP BLOG EMIT
Feb 22 08:55:42 RT-AX86U-FB40 kernel: _blog_emit, blogp = 0x23c0
Feb 22 08:55:42 RT-AX86U-FB40 kernel: eth3 (Ext switch port: 2) (Logical Port: 10) (phyId: a) Link Up at 1000 mbps full duplex
Feb 22 08:55:42 RT-AX86U-FB40 kernel: br0: port 2(eth3) entered listening state
Feb 22 08:55:42 RT-AX86U-FB40 kernel: br0: port 2(eth3) entered listening state
Feb 22 08:55:44 RT-AX86U-FB40 kernel: _blog_emit, blogp = 0x23c0
Feb 22 08:55:44 RT-AX86U-FB40 kernel: _blog_emit, blogp = 0x23c0
Feb 22 08:55:44 RT-AX86U-FB40 kernel: br0: port 2(eth3) entered learning state
Feb 22 08:55:45 RT-AX86U-FB40 kernel: _blog_emit, blogp = 0x22a0
Feb 22 08:55:45 RT-AX86U-FB40 kernel: _blog_emit, blogp = 0x2360
Feb 22 08:55:46 RT-AX86U-FB40 kernel: br0: topology change detected, propagating
Feb 22 08:55:46 RT-AX86U-FB40 kernel: br0: port 2(eth3) entered forwarding state
Feb 22 08:55:48 RT-AX86U-FB40 kernel: eth3 (Ext switch port: 2) (Logical Port: 10) (phyId: a) Link DOWN.
Feb 22 08:55:48 RT-AX86U-FB40 kernel: br0: port 2(eth3) entered disabled state
Feb 22 08:55:48 RT-AX86U-FB40 kernel: _blog_emit, blogp = 0x1b68
SNIP BLOG EMIT
Feb 22 08:55:56 RT-AX86U-FB40 kernel: _blog_emit, blogp = 0x23c0
Feb 22 08:56:00 RT-AX86U-FB40 kernel: eth3 (Ext switch port: 2) (Logical Port: 10) (phyId: a) Link Up at 1000 mbps full duplex
Feb 22 08:56:00 RT-AX86U-FB40 kernel: _blog_emit, blogp = 0x22c0
Feb 22 08:56:00 RT-AX86U-FB40 kernel: br0: port 2(eth3) entered listening state
Feb 22 08:56:00 RT-AX86U-FB40 kernel: br0: port 2(eth3) entered listening state
Feb 22 08:56:01 RT-AX86U-FB40 hostapd: eth7: STA 40:2f:86:XX:XX:XX WPA: group key handshake completed (RSN)
Feb 22 08:56:01 RT-AX86U-FB40 hostapd: eth7: STA e4:a7:a0:XX:XX:XX WPA: group key handshake completed (RSN)
Feb 22 08:56:01 RT-AX86U-FB40 hostapd: eth7: STA 44:07:0b:XX:XX:XX WPA: group key handshake completed (RSN)
Feb 22 08:56:01 RT-AX86U-FB40 hostapd: eth7: STA 88:d0:39:XX:XX:XX WPA: group key handshake completed (RSN)
Feb 22 08:56:01 RT-AX86U-FB40 hostapd: eth7: STA 14:c1:4e:XX:XX:XX WPA: group key handshake completed (RSN)
Feb 22 08:56:01 RT-AX86U-FB40 hostapd: eth6: STA 04:cf:8c:XX:XX:XX WPA: group key handshake completed (RSN)
Feb 22 08:56:01 RT-AX86U-FB40 hostapd: eth7: STA 64:a2:f9:XX:XX:XX WPA: group key handshake completed (RSN)
Feb 22 08:56:01 RT-AX86U-FB40 kernel: CONSOLE: 147202.488 tx:prep:802.1x
Feb 22 08:56:01 RT-AX86U-FB40 kernel: CONSOLE: 147202.488 tx:prep:802.1x
Feb 22 08:56:01 RT-AX86U-FB40 kernel: CONSOLE: 147202.489 tx:prep:802.1x
Feb 22 08:56:01 RT-AX86U-FB40 kernel: CONSOLE: 147202.489 tx:prep:802.1x
Feb 22 08:56:01 RT-AX86U-FB40 kernel: CONSOLE: 147202.489 tx:prep:802.1x
Feb 22 08:56:01 RT-AX86U-FB40 kernel: CONSOLE: 147202.590 tx:prep:802.1x
Feb 22 08:56:01 RT-AX86U-FB40 hostapd: eth7: STA c0:ee:fb:XX:XX:XX WPA: group key handshake completed (RSN)
Feb 22 08:56:02 RT-AX86U-FB40 kernel: CONSOLE: 147202.693 tx:prep:802.1x
Feb 22 08:56:02 RT-AX86U-FB40 kernel: _blog_emit, blogp = 0x23c0
Feb 22 08:56:02 RT-AX86U-FB40 kernel: _blog_emit, blogp = 0x23c0
Feb 22 08:56:02 RT-AX86U-FB40 hostapd: eth7: STA 28:c2:1f:XX:XX:XX WPA: group key handshake completed (RSN)
Feb 22 08:56:02 RT-AX86U-FB40 kernel: CONSOLE: 147203.191 tx:prep:802.1x
Feb 22 08:56:02 RT-AX86U-FB40 kernel: br0: port 2(eth3) entered learning state
Feb 22 08:56:04 RT-AX86U-FB40 kernel: br0: topology change detected, propagating
Feb 22 08:56:04 RT-AX86U-FB40 kernel: br0: port 2(eth3) entered forwarding state
Feb 22 08:56:05 RT-AX86U-FB40 kernel: _blog_emit, blogp = 0x22a0
Feb 22 08:56:12 RT-AX86U-FB40 kernel: _blog_emit, blogp = 0x23c0
Feb 22 08:56:12 RT-AX86U-FB40 kernel: _blog_emit, blogp = 0x23c0
Feb 22 08:56:13 RT-AX86U-FB40 kernel: device br0 entered promiscuous mode
Feb 22 08:56:17 RT-AX86U-FB40 kernel: _blog_emit, blogp = 0x1b88
SNIP BLOG EMIT
Feb 22 08:56:18 RT-AX86U-FB40 kernel: _blog_emit, blogp = 0x23c0
Feb 22 08:56:19 RT-AX86U-FB40 kernel: device br0 left promiscuous mode
Feb 22 08:56:21 RT-AX86U-FB40 kernel: _blog_emit, blogp = 0x23c0
Feb 22 08:56:21 RT-AX86U-FB40 kernel: _blog_emit, blogp = 0x23c0
Feb 22 08:56:26 RT-AX86U-FB40 kernel: _blog_emit, blogp = 0x1c28
Feb 22 08:56:30 RT-AX86U-FB40 kernel: CONSOLE: 147231.041 wl1: wlc_ampdu_recv_addba_resp: 44:07:0b:XX:XX:XX: Failed. status 37 wsize 64 policy 1
Feb 22 08:56:32 RT-AX86U-FB40 kernel: _blog_emit, blogp = 0x2
SNIP BLOG EMIT
Feb 22 08:57:09 RT-AX86U-FB40 kernel: _blog_emit, blogp = 0x2380
Feb 22 08:57:10 RT-AX86U-FB40 kernel: CONSOLE: 147270.640 wl1.0: wlc_send_bar: for 40:2f:86:XX:XX:XX seq 0x846 tid 0
Feb 22 08:57:11 RT-AX86U-FB40 kernel: _blog_emit, blogp = 0x1ac8
Feb 22 08:57:13 RT-AX86U-FB40 kernel: _blog_emit, blogp = 0x23c0
Feb 22 08:57:18 RT-AX86U-FB40 kernel: CONSOLE: 147278.401 wl1.0: wlc_send_bar: for 14:c1:4e:XX:XX:XX seq 0xedf tid 6
Feb 22 08:57:25 RT-AX86U-FB40 kernel: _blog_emit, blogp = 0x22e0
SNIP BLOG EMIT
Feb 22 08:57:30 RT-AX86U-FB40 kernel: _blog_emit, blogp = 0x22e0
Feb 22 08:57:30 RT-AX86U-FB40 kernel: CONSOLE: 147290.790 wl1: wlc_ampdu_recv_addba_resp: 44:07:0b:XX:XX:XX: Failed. status 37 wsize 64 policy 1
Feb 22 08:57:38 RT-AX86U-FB40 kernel: _blog_emit, blogp = 0x2
SNIP BLOG EMIT
Feb 22 08:57:54 RT-AX86U-FB40 kernel: _blog_emit, blogp = 0x23c0
Feb 22 08:57:59 RT-AX86U-FB40 kernel: CONSOLE: 147320.112 wl1.0: wlc_send_bar: for 14:c1:4e:XX:XX:XX seq 0xf2e tid 6
Feb 22 08:57:59 RT-AX86U-FB40 kernel: CONSOLE: 147320.113 wl1.0: wlc_send_bar: for 14:c1:4e:XX:XX:XX seq 0xf2e tid 6

EDIT:
Just rebooted everything and still the same problem.
Looking at my WiFi networks i can now also see the Open ASUS network and from the strength i assume its the AX58U.
But im not able to actually connect too it
Try remove node and add it back. If can't add back, check your WPS setting.
 
My AI Mesh node doesnt connect to the main router since this morning.
Not sure if related to this firmware or a different bug though.
I have a AX-86U as main router and use a AX-58U as wired node for the upper levels of my house.
Just started work and noticed i had a weak WiFi signal on the laptop.
I can ping the IP of the Mesh node, i can access the webgui of the node but its states it cant reach the Mesh router, wich is strange as my client can reach the node through the router.


EDIT:
Just rebooted everything and still the same problem.
Looking at my WiFi networks i can now also see the Open ASUS network and from the strength i assume its the AX58U.
But im not able to actually connect too it
I saw something Similar twice before. .. Once was after power cuts.. the node router came up but the WAN led was red. Second time, it came back up bit everything looked ok except no connectivity .. These have ethernet back haul.. In the 1st case, just adding the node back in the GUI worked, the Second case, the WPS button reset on the node and then re-add via the GUI worked. I would suggest , if you had power spikes or drops, you get the node on a UPS or at the very lease, a surge protector.
 
Perhaps. Can't withdraw at the moment to test. But if i get some low use time this weekend, I'll test it for an hour or so with clients powering on and off.
Over the weekend I played around with this problem and did not get very far with respect to a solution. I would disconnect and reconnect clients to see if the client list would auto update. Things I tried to see if I could get the client list to auto update:
ActionResultComment
Withdrew from Trend Micro / rebootedNo Auto Update without forcing refresh in status windowBoth wireless and wired clients would not update
Toggled Jumbo Frames on / rebootedNo Auto Update without forcing refresh in status windowBoth wireless and wired clients would not update
Toggled Jumbo Frames off / rebootedNo Auto Update without forcing refresh in status windowBoth wireless and wired clients would not update
Removed Mesh Node (TM still not active) / rebootedNo Auto Update without forcing refresh in status windowBoth wireless and wired clients would not update
Made config and jffs backup / hard reset / reapplied backupsNo Auto Update without forcing refresh in status windowBoth wireless and wired clients would not update
Hard reset / Manual setup (no TM / no mesh node)Wireless clients auto update / some wired clients auto updateWired clients that auto updated seem to be "newer" clients. That is, had NIC cards that were from 2016 or newer. Brand of NIC seemed irrelevant (Realtek, Broadcom, INTEL, etc.)
Hard reset / Manual setup TM active (FlexQoS) (no mesh node)Wireless clients auto update / some wired clients auto updateNo change in behavior from above
Hard reset / Manual setup TM active (FlexQoS) . Hard Reset Mesh Node and re-added it to the main routerWireless clients auto update / some wired clients auto updateNo change in behavior from above
 
Try remove node and add it back. If can't add back, check your WPS setting.
WPS?
I have WPS turned off as the unit is connected by cable to the main router.

I saw something Similar twice before. .. Once was after power cuts.. the node router came up but the WAN led was red. Second time, it came back up bit everything looked ok except no connectivity .. These have ethernet back haul.. In the 1st case, just adding the node back in the GUI worked, the Second case, the WPS button reset on the node and then re-add via the GUI worked. I would suggest , if you had power spikes or drops, you get the node on a UPS or at the very lease, a surge protector.

Thx, its working now after i fully resetted the device.
I am not aware of powerspikes or drops, none of my devices have ever had power problems and the main fuses are still intact
Im going to monitor if it happens again
 
If you remove the AiMesh node and want to add it back into the network again, then WPS must be turned on to be able to do so. :)

Afterward, disable it.
 
just upgraded to 389.1.2, did a factory reset and try to install Diversion but it's seem like hanging as seen below. Any idea?

yUIp1r5.png
 
Status
Not open for further replies.

Latest threads

Sign Up For SNBForums Daily Digest

Get an update of what's new every day delivered to your mailbox. Sign up here!

Members online

Top