Release Asuswrt-Merlin 386.1 is now available

[Suresh]

Just upgraded AX86U from stock to 386.1_2 and factory reset. Everything seem to work fine except I have these messages flooding my log every few seconds. I am assuming this isn't expected behavior?

Feb 17 21:17:10 kernel: CONSOLE: 020657.022 wl1: wlc_ampdu_recv_addba_resp: ae:88:22:71:4b:66: Failed. status 1 wsize 0 policy 0
Feb 17 21:17:16 kernel: CONSOLE: 020662.512 wl1: wlc_ampdu_recv_addba_resp: 74:d8:3e:c8:98:58: Failed. status 37 wsize 64 policy 1
Feb 17 21:17:17 kernel: CONSOLE: 020663.129 wl1: r0hole: tx_exp_seq 0x9c, seq 0x9d
Feb 17 21:17:53 kernel: CONSOLE: 020699.235 wl1: wlc_ampdu_recv_addba_resp: 00:04:4b:bb:d6:48: Failed. status 37 wsize 64 policy 1
Feb 17 21:17:56 kernel: CONSOLE: 020702.127 wl1: wlc_ampdu_recv_addba_resp: 74:d8:3e:c8:98:58: Failed. status 37 wsize 64 policy 1
Feb 17 21:17:57 kernel: CONSOLE: 020703.860 wl1: r0hole: tx_exp_seq 0x9e, seq 0x9f
Feb 17 21:18:04 kernel: CONSOLE: 020709.976 wl1: wlc_ampdu_recv_addba_resp: ae:88:22:71:4b:66: Failed. status 1 wsize 0 policy 0
Feb 17 21:18:23 kernel: CONSOLE: 020729.311 wl1: r0hole: tx_exp_seq 0x6, seq 0x7
Feb 17 21:18:26 kernel: CONSOLE: 020732.379 wl1: wlc_ampdu_recv_addba_resp: ae:88:22:71:4b:66: Failed. status 1 wsize 0 policy 0
Feb 17 21:18:53 kernel: CONSOLE: 020758.926 wl1: wlc_ampdu_recv_addba_resp: 00:04:4b:bb:d6:48: Failed. status 37 wsize 64 policy 1
Feb 17 21:18:55 kernel: CONSOLE: 020760.982 wl1: wlc_ampdu_recv_addba_resp: 74:d8:3e:c8:98:58: Failed. status 37 wsize 64 policy 1
Feb 17 21:19:03 kernel: CONSOLE: 020769.036 wl1: wlc_ampdu_recv_addba_resp: ae:88:22:71:4b:66: Failed. status 1 wsize 0 policy 0
Feb 17 21:19:11 kernel: CONSOLE: 020777.183 wl1: wlc_ampdu_recv_addba_resp: ae:88:22:71:4b:66: Failed. status 1 wsize 0 policy 0
Feb 17 21:19:17 kernel: CONSOLE: 020782.585 wl1: r0hole: tx_exp_seq 0x6df, seq 0x6e0
Feb 17 21:19:53 kernel: CONSOLE: 020818.615 wl1: wlc_ampdu_recv_addba_resp: 00:04:4b:bb:d6:48: Failed. status 37 wsize 64 policy 1
Feb 17 21:19:55 kernel: CONSOLE: 020820.655 wl1: wlc_ampdu_recv_addba_resp: 74:d8:3e:c8:98:58: Failed. status 37 wsize 64 policy 1
Feb 17 21:20:03 kernel: CONSOLE: 020828.610 wl1: wlc_ampdu_recv_addba_resp: ae:88:22:71:4b:66: Failed. status 1 wsize 0 policy 0
Feb 17 21:20:11 kernel: CONSOLE: 020836.754 wl1: wlc_ampdu_recv_addba_resp: ae:88:22:71:4b:66: Failed. status 1 wsize 0 policy 0
Feb 17 21:20:17 kernel: CONSOLE: 020842.155 wl1: r0hole: tx_exp_seq 0x6e6, seq 0x6e7
Feb 17 21:20:28 kernel: CONSOLE: 020853.046 wl1: wlc_ampdu_recv_addba_resp: ae:88:22:71:4b:66: Failed. status 1 wsize 0 policy 0
Feb 17 21:20:38 kernel: CONSOLE: 020863.224 wl1: r0hole: tx_exp_seq 0xa8, seq 0xa9
Feb 17 21:20:55 kernel: CONSOLE: 020880.327 wl1: wlc_ampdu_recv_addba_resp: 74:d8:3e:c8:98:58: Failed. status 37 wsize 64 policy 1
Feb 17 21:20:59 kernel: CONSOLE: 020884.565 wl1: r0hole: tx_exp_seq 0x6ed, seq 0x6ee
Feb 17 21:21:02 kernel: CONSOLE: 020887.151 Unexpected RX reason 29 {if=wl1 fc=4188 seq=07b0 A1=3c:7c:3f:6a:1a:74 A2=74:d8:3e:c8:98:58}
Feb 17 21:21:04 kernel: CONSOLE: 020888.904 wl1.0: wlc_send_bar: for 74:d8:3e:c8:98:58 seq 0x7 tid 6
Feb 17 21:21:11 kernel: CONSOLE: 020895.906 wl1: wlc_ampdu_recv_addba_resp: 74:d8:3e:c8:98:58: Failed. status 37 wsize 64 policy 1
Feb 17 21:21:29 kernel: CONSOLE: 020914.396 wl1: r0hole: tx_exp_seq 0x6ef, seq 0x6f0
Feb 17 21:21:32 kernel: CONSOLE: 020917.149 wl1: r0hole: tx_exp_seq 0x594, seq 0x595
Feb 17 21:22:08 kernel: CONSOLE: 020952.758 wl1: wlc_cfp_scb_chain_sendup, tossing; wlc: 002827fc, h: 001958c6, reason: 29
Feb 17 21:22:08 kernel: CONSOLE: 020952.758 Unexpected RX reason 29 {if=wl1 fc=4188 seq=0900 A1=3c:7c:3f:6a:1a:74 A2=74:d8:3e:c8:98:58}
Feb 17 21:22:16 kernel: CONSOLE: 020960.664 wl1: wlc_ampdu_recv_addba_resp: 74:d8:3e:c8:98:58: Failed. status 37 wsize 64 policy 1
Feb 17 21:22:21 kernel: CONSOLE: 020965.976 wl1: wlc_ampdu_recv_addba_resp: 00:04:4b:bb:d6:48: Failed. status 37 wsize 64 policy 1
Feb 17 21:22:29 kernel: CONSOLE: 020973.197 wl1: wlc_ampdu_recv_addba_resp: ae:88:22:71:4b:66: Failed. status 1 wsize 0 policy 0
Feb 17 21:22:36 kernel: CONSOLE: 020980.657 wl1: r0hole: tx_exp_seq 0x7bd, seq 0x7be
Feb 17 21:22:56 kernel: CONSOLE: 021000.486 wl1: r0hole: tx_exp_seq 0x952, seq 0x953
Feb 17 21:23:05 kernel: CONSOLE: 021009.856 wl1: wlc_ampdu_recv_addba_resp: ae:88:22:71:4b:66: Failed. status 1 wsize 0 policy 0
Feb 17 21:23:14 kernel: CONSOLE: 021018.003 wl1: wlc_ampdu_recv_addba_resp: ae:88:22:71:4b:66: Failed. status 1 wsize 0 policy 0
Feb 17 21:23:16 kernel: CONSOLE: 021020.338 wl1: wlc_ampdu_recv_addba_resp: 74:d8:3e:c8:98:58: Failed. status 37 wsize 64 policy 1
Feb 17 21:23:18 kernel: CONSOLE: 021022.068 wl1: r0hole: tx_exp_seq 0xb2, seq 0xb3
Feb 17 21:23:21 kernel: CONSOLE: 021025.641 wl1: wlc_ampdu_recv_addba_resp: 00:04:4b:bb:d6:48: Failed. status 37 wsize 64 policy 1
Feb 17 21:23:56 kernel: CONSOLE: 021060.156 wl1: wlc_ampdu_recv_addba_resp: 74:d8:3e:c8:98:58: Failed. status 37 wsize 64 policy 1

 

[RMerlin]

Just upgraded AX86U from stock to 386.1_2 and factory reset. Everything seem to work fine except I have these messages flooding my log every few seconds. I am assuming this isn't expected behavior?

It's expected, as Asus currently compiles the RT-AX86U wireless driver with wifi debugging enabled.

 

[Suresh]

It's expected, as Asus currently compiles the RT-AX86U wireless driver with wifi debugging enabled.

Thank you. Appreciate your quick response.

 

[aex.perez]

I hesitate with this because I haven't captured it in the logs and or it may be AIMesh closed source code. But the activity is different from 386.1

Occasionally, as I move through the house I correlate Dissaoc/ReAssoc of my iPhone in the logs. But after a few minutes I lose my IPADDR. Still have good signal strength just no layer 3, no Internet, no local access. Not sure what to look for or how to test and even if I did, whether this was going to be closed source. I have the roaming assistant enabled, set to disconnect clients with an RSSI lower than -65 dBm. Tx power adjustment set to performance. No Smart connect. I can see the iPhone coming off or coming on the router or AIMesh nodes in wlceventd.log and roamast.log. Now after losing my IP, if I go back and connect back to the original location I was on, local and Internet connectivity resume. If I toggle WiFi on the phone I get it back. 2.4Ghz or 5Ghz no difference after this happens, I'm working again. Under 386.1 this happened very infrequently to the point where I thought just adjusting the threshold on the roaming assist would do the trick, and for the most part I felt it did. Under 386.1_2 this is happening much more often. What I have yet to try is if waiting long enough do I get the IPADDR back, I think I do, but need to be sure.

At this point not sure what to look for, where to look and a test scenario to capture, open to ideas...
Thinking of using the laptop, wireshark and roaming as a first step, to try to get a little more detail to correlate with the logs on the router, grab the arp table at the router, nodes and laptop and compare before, during and after. Taking suggestions.

Got this but I think that's related to AIMesh closed source;
Feb 17 18:12:58 AC5300-MBR kernel: br0: received packet on wl1.1 with own address as source address
Feb 17 18:26:09 AC5300-CP kernel: br0: received packet on wl2.1 with own address as source address
Feb 17 18:26:12 AX88U-MAIN kernel: br0: received packet on eth7 with own address as source address
Feb 17 18:54:03 AC5300-MBR kernel: br0: received packet on wl0.1 with own address as source address
Feb 17 18:54:43 AX88U-MAIN kernel: br0: received packet on eth6 with own address as source address
Feb 17 18:55:11 AC5300-MBR kernel: br0: received packet on wl0.1 with own address as source address
Feb 17 18:56:54 AX88U-MAIN kernel: br0: received packet on eth7 with own address as source address
Feb 17 18:56:58 AC5300-MBR kernel: br0: received packet on wl1.1 with own address as source address
Feb 17 18:57:12 AX88U-MAIN kernel: br0: received packet on eth7 with own address as source address
Feb 17 18:57:21 AC5300-MBR kernel: br0: received packet on wl1.1 with own address as source address
Feb 17 18:58:15 AX88U-MAIN kernel: br0: received packet on eth7 with own address as source address
Feb 17 18:58:19 AX88U-MAIN kernel: br0: received packet on eth7 with own address as source address
Feb 17 19:16:32 AC5300-CP kernel: br0: received packet on wl2.1 with own address as source address
Feb 17 19:16:33 AC5300-MBR kernel: br0: received packet on wl1.1 with own address as source address
Feb 17 19:16:53 AC5300-CP kernel: br0: received packet on wl2.1 with own address as source address
Feb 17 19:16:54 AX88U-MAIN kernel: br0: received packet on eth7 with own address as source address

A little more color and very likely ASUS AIMesh closed source.
Starting fresh on the main router, AX88U 386.1-2 - arp -a from router command line
(192.168.1.73) at 02:e9:2d:d7:08:c4 [ether] on br0

Move to the room where the AC5300 386.1-2 is, reissue arp
(192.168.1.73) at <incomplete> on br0

Waited 20 mins for it to update, never did and never got connectivity back but showed full strength WiFi signal.
After the 20min, got bored waiting and toggled WiFi on the phone and the live feed resumed. Did another arp -a and;
(192.168.1.73) at 02:e9:2d:d7:08:c4 [ether] on br0


1) If it fails and you try going from router to node again after toggling WiFi, it won't fail unless you clear the arp entry first, starting from scratch basically.
2) Second this scenario is going from router to node.
3) Start in reverse, connected on the node, clearing the arp entry, letting it relearn, walking back to the router, no issue, never drops the live feed or looses IP connectivity
4) arp entries on the nodes only list the router and the PC I'm SSH'ing from only (both on br0)

UPDATE: Got to try this all over again. Found out the 5Ghz-2 was off on the AC5300 in question. Could not replicate the issue if the wired AndroidTV box was on and streaming. The Amazon Echo was connected wireless 5Ghz in all cases. Going to try to be a bit more methodical tomorrow

 

[normanlai]

Dear Experts

i have the AC88

i uploaded the latest 386.1_2

everything seems fine, i even purposely reset to factory and formatted the partitions to ensure its really clean.

i scribbled all the settings from 384.18 and bit by bit typed into the new 386.1_2 so i think its clean as can be.

now my problem. i was able to enable WOL from internet in 384.18. I am trying to restore the WOL (internet) function to my AC88 running 386.1_2

This is what my "/scripts/services -start" contain:
#!/bin/sh
arp -i br0 -s 192.168.1.254 ff:ff:ff:ff:ff:ff

This is what my virtual Server / Port forwarding contain:

​

Service Name	External Port	Internal Port	Internal IP Address	Protocol	Source IP	Edit	Delete

​

WOL

254

9

192.168.1.254

UDP

it worked like a charm the past year.

from my phone i just need to trigger:

MYADDRESS.ddns.net:254 and point to my MAC address.

it wakes up my computer from anywhere.


suddenly it does not work in 386.1_2. The script is there. i uploaded the backup from 384.18 since the JFFS contains nothing but this 2 lines, well i thought, what can go wrong?

thank you for your patience.

 

[clweb]

Is that a comment to my previous message?

Corrupt? How? Does it cause some trouble?

Yes it was a comment to your message.
The valus of internet traffic are not displayed. But as far as I remember this bug was also present in previuos versions.
Sometimes the auto-logoff works. But when you close the browser without logoff, the problem appears.

 

[JackFrost]

I can confirm that.

If you don't manually log out from Merlin GUI and just close your browser and open the brower next day you are immediately in. No need to login again.

@RMerlin

Any possible ETA to fix this?

 

[roguetr]

RT-AC5300 ... Time scheduling now seems to work but DST isn't applied to the system time.

 

[Bieniu]

I did a factory reset and jfss format after the update AC86U from 384.17 to 386.1_2 and the CPU temperature is 91-93°C. Should I worry about it?

 

[MarkyPancake]

I did a factory reset and jfss format after the update from 384.17 to 386.1_2 and the temperature is still 91-93°C. Should I worry about it?

For comparison, my AC86U is still on 384.19 and these are the current temps:

• 2.4 GHz: 51°C
• 5 GHz: 57°C
• CPU: 67°C

 

[Bobbykha9]

Help? re 86U
I did upgrade from 386.1 to 386.1_2 feb 14th, today router lost internet connectivity, rebooted again by power cycling , saw this in syslog Can any one tell me what is it? Thx


Feb 16 21:49:02 kernel: SHN Release Version: 2.0.1 851496c
Feb 16 21:49:02 kernel: UDB Core Version: 0.2.18
Feb 16 21:49:02 kernel: sizeof forward pkt param = 280

Hi folks Can Pls anyone help me, I got the same log entries every day Do I need to do something or just disregard it, Thanks in advance

 

[ATLga]

Hi folks Can Pls anyone help me, I got the same log entries every day Do I need to do something or just disregard it, Thanks in advance

Merlin answered you yesterday morning

 

[Bobbykha9]

Merlin answered you yesterday morning

Thx I didn’t get email I thought no body said anything Thx RMerlin

 

[Bobbykha9]

Trend Micro engine loading, has always been there.

Thx RMerlin Sorry I saw your message very late, You are so quick to answer all questions I really appreciate your help

 

[heysoundude]

Hi Guys,

Found a possible bug in AiMesh on 386.1_2.

I have 2 hardwired Synology NAS's, both set using jumbo frames (MTU=9000) in conjunction with a W10 PC. When i connect them to my main AC2900 router, i'm able to open DSM (Syno Management) and use jumbo frames and shares from one to another. Things work fine.

Now when i move one of these NAS's to my AC68U AiMesh node, i can't open DSM on the remote (node) NAS or connect it to the NFS share of its brother on the main node anymore, except when i set the remote NAS to a standard MTU of 1500.
It seems as though Jumbo frames do not propagate to and from the node.

For now i'm using the standard MTU size of 1500 on the remote NAS, but i'd like to use jumbo frames because of faster throughput.

(Besides that: Adding the AiMesh node added another 3 degr. C to CPU temp on my main router)

EDIT: jumbo_frame_enable was set to 0 on node, setting it to 1 did not help

Something is tickling the back of my brain suggesting Spanning Tree Protocol on the node (and probably the router) needs to be activated...I think then it will (might? could?) fall in line with the router and use jumbo frames for anything wired to it.
Remember, AiMesh is just the wireless side of things - the routers have switches built in, and that side needs correct config as well. This might be more important in the AX models, with the 2.5G eth port, when it's used for wired backhaul when it's presumed the upstream wired WAN connection is likely symmetrical 1Gbps+
...IF (big if) I'm right in my understandings/recollections
So, Jumbo frames and Spanning tree on for both Router and node, and let us know how that works out after a save/apply and reboot

 

[heysoundude]

I did a factory reset and jfss format after the update AC86U from 384.17 to 386.1_2 and the CPU temperature is 91-93°C. Should I worry about it?

how long ago did you upgrade? let the router settle for a while longer and I'd wager it comes down: when I did my upgrade from 384.19 to 386.1, the temp did spike into the high 80s, but has since settled 10 degrees lower - when I happen to look, it's fluctuating in the 76-78 range, only 4-5 degrees warmer than before. but it took 12+ hrs to "settle" and cool - passive cooling is like that.

 

[GHammer]

I hesitate with this because I haven't captured it in the logs and or it may be AIMesh closed source code. But the activity is different from 386.1

Occasionally, as I move through the house I correlate Dissaoc/ReAssoc of my iPhone in the logs. But after a few minutes I lose my IPADDR. Still have good signal strength just no layer 3, no Internet, no local access. Not sure what to look for or how to test and even if I did, whether this was going to be closed source. I have the roaming assistant enabled, set to disconnect clients with an RSSI lower than -65 dBm. Tx power adjustment set to performance. No Smart connect. I can see the iPhone coming off or coming on the router or AIMesh nodes in wlceventd.log and roamast.log. Now after losing my IP, if I go back and connect back to the original location I was on, local and Internet connectivity resume. If I toggle WiFi on the phone I get it back. 2.4Ghz or 5Ghz no difference after this happens, I'm working again. Under 386.1 this happened very infrequently to the point where I thought just adjusting the threshold on the roaming assist would do the trick, and for the most part I felt it did. Under 386.1_2 this is happening much more often. What I have yet to try is if waiting long enough do I get the IPADDR back, I think I do, but need to be sure.

At this point not sure what to look for, where to look and a test scenario to capture, open to ideas...
Thinking of using the laptop, wireshark and roaming as a first step, to try to get a little more detail to correlate with the logs on the router, grab the arp table at the router, nodes and laptop and compare before, during and after. Taking suggestions.

Got this but I think that's related to AIMesh closed source;
Feb 17 18:12:58 AC5300-MBR kernel: br0: received packet on wl1.1 with own address as source address
Feb 17 18:26:09 AC5300-CP kernel: br0: received packet on wl2.1 with own address as source address
Feb 17 18:26:12 AX88U-MAIN kernel: br0: received packet on eth7 with own address as source address
Feb 17 18:54:03 AC5300-MBR kernel: br0: received packet on wl0.1 with own address as source address
Feb 17 18:54:43 AX88U-MAIN kernel: br0: received packet on eth6 with own address as source address
Feb 17 18:55:11 AC5300-MBR kernel: br0: received packet on wl0.1 with own address as source address
Feb 17 18:56:54 AX88U-MAIN kernel: br0: received packet on eth7 with own address as source address
Feb 17 18:56:58 AC5300-MBR kernel: br0: received packet on wl1.1 with own address as source address
Feb 17 18:57:12 AX88U-MAIN kernel: br0: received packet on eth7 with own address as source address
Feb 17 18:57:21 AC5300-MBR kernel: br0: received packet on wl1.1 with own address as source address
Feb 17 18:58:15 AX88U-MAIN kernel: br0: received packet on eth7 with own address as source address
Feb 17 18:58:19 AX88U-MAIN kernel: br0: received packet on eth7 with own address as source address
Feb 17 19:16:32 AC5300-CP kernel: br0: received packet on wl2.1 with own address as source address
Feb 17 19:16:33 AC5300-MBR kernel: br0: received packet on wl1.1 with own address as source address
Feb 17 19:16:53 AC5300-CP kernel: br0: received packet on wl2.1 with own address as source address
Feb 17 19:16:54 AX88U-MAIN kernel: br0: received packet on eth7 with own address as source address

Could be the same issue as mine.
https://www.snbforums.com/threads/an-observation-386-code-ax86u-and-wifi-failure.70425/#post-665177

 

[ledger2]

Device: RT-AX58U
Background: Previously installed firmware version was 384.19. Upgraded first to 386.1_2 and then downgraded to 386.1 (and then eventually back to 384.19).
The problem: have a Cisco switch (CBS250-8P), and after upgrading both to 386.1_2 and 368.1, I cannot reach to it any more. Can ping it though (via router), but deviced behind the switch do not work. When reverting back to 384.19, all things work just fine. No other changes made, just upgraded/downgraded the firmware - did work with 384, did not work with 386, and then worked again with 384.

Any ideas? Even how to locate the issue (debug or log)?

 

[Kees17760]

Something is tickling the back of my brain suggesting Spanning Tree Protocol on the node (and probably the router) needs to be activated...I think then it will (might? could?) fall in line with the router and use jumbo frames for anything wired to it.
Remember, AiMesh is just the wireless side of things - the routers have switches built in, and that side needs correct config as well. This might be more important in the AX models, with the 2.5G eth port, when it's used for wired backhaul when it's presumed the upstream wired WAN connection is likely symmetrical 1Gbps+
...IF (big if) I'm right in my understandings/recollections
So, Jumbo frames and Spanning tree on for both Router and node, and let us know how that works out after a save/

Hi and thanks for your reply.
Lan_stp was set to 1 on both master and node already. Switched them both to 0 and back again (via GUI) to no avail. Earlier switched jumbo_frame_enable to 1 (was initially 0) on the node, also to no avail

 

[Suzib6sw]

Any ideas? Even how to locate the issue (debug or log)?

When you upgraded to 386.x did you factory reset or did you factory reset and then load a .cfg file back in or did you manually? T