Beta Asuswrt-Merlin 386.5 Beta is now available

[ColinTaylor]

acsd2 doesn't appear to be working. Same problem was present in 386.4. I was hoping the change to model specific versions might have changed this but it hasn't. (I've only tested this on 2.4GHz)

In the past there were obvious messages (APCS_CSTIMER) in the syslog every 15 minutes when acsd2 was being used. They are no longer present.

Most of the time, when the router boots up the following messages are shown resulting to it defaulting to channel 1:

May  5 06:05:11 acsd: eth6: Selecting 2g band ACS policy
May  5 06:05:11 acsd: acsd_main_loop(1178): sync_id: 26126, status:1, misc.error/abort
May  5 06:05:11 acsd: acs_candidate_score_busy(1081): eth6: busy check failed for chanspec: 0x1803 (1l)
May  5 06:05:11 acsd: acs_candidate_score_intf(1133): eth6: intf check failed for chanspec: 0x1803 (1l)
May  5 06:05:11 acsd: acs_candidate_score_bgnoise(1602): eth6: bgnoise check failed for chanspec: 0x1803 (1l)
May  5 06:05:11 acsd: acs_candidate_score_txop(1860): eth6: txop check failed for chanspec: 0x1803 (1l)
May  5 06:05:11 acsd: acs_candidate_score_cns(1696): eth6: knoise check failed for chanspec: 0x1803 (1l)
:
May  5 06:05:11 acsd: acs_candidate_score_busy(1081): eth6: busy check failed for chanspec: 0x190b (13u)
May  5 06:05:11 acsd: acs_candidate_score_intf(1133): eth6: intf check failed for chanspec: 0x190b (13u)
May  5 06:05:11 acsd: acs_candidate_score_bgnoise(1602): eth6: bgnoise check failed for chanspec: 0x190b (13u)
May  5 06:05:11 acsd: acs_candidate_score_txop(1860): eth6: txop check failed for chanspec: 0x190b (13u)
May  5 06:05:11 acsd: acs_candidate_score_cns(1696): eth6: knoise check failed for chanspec: 0x190b (13u)
May  5 06:05:11 acsd: eth6: selected channel spec: 0x1803 (1l)
May  5 06:05:11 acsd: eth6: Adjusted channel spec: 0x1803 (1l)
May  5 06:05:11 acsd: eth6: selected channel spec: 0x1803 (1l)
May  5 06:05:11 acsd: acs_set_chspec: 0x1803 (1l) for reason APCS_INIT

Regardless of whether those messages were present it doesn't appear to be updating the channels stats when using commands like acs_cli2 -i eth6 dump chanim.

Perhaps the behaviour has changed and it is working as expected. But I'm in a fairly crowded 2.4GHz environment and I've never seen acsd2 change the channel. If I periodically run acs_cli2 -i eth6 autochannel (or manually restart the WiFi) it will occasionally change channels.

@RMerlin I appreciate that the WiFi code is beyond your control but I thought I'd mention it after seeing that you had made some changes effecting acds2.

 

[haryb]

In this version, RT-AX58U V2 - will be or is supported ? Are you add this fixed in this beta version?

 

[Suzib6sw]

Upgraded to Beta1 from Alpha 2 on 3X RT-AX58U in Aimesh .. Have always used Adaptive QOS (work from home) and had no problems with logging (QOS Web History ) till 2 days ago (2/23) when all web history stopped.. on the 23rd, I did try the various QOS options to see if there was any improvements for my set up. I went back to Adaptive and left it there till today when I wanted to check the web history and noticed no log entries since the 23rd. I cleared the history and turned off Web history and turned is back on.. Checked the System log and saw this.

Feb 25 11:19:02 rc_service: httpd 1607:notify_rc clean_web_history
Feb 25 11:19:10 rc_service: httpd 1607:notify_rc restart_qos;restart_firewall
Feb 25 11:19:12 kernel: Archer TCP Pure ACK Enabled
Feb 25 11:19:12 kernel: ^[[0;33;41m[ERROR archer] sysport_tm_command,1224: Feature Unavailable^[[0m
Feb 25 11:19:18 BWDPI: fun bitmap = 5ff
Feb 25 11:19:18 A.QoS: qos_count=0, qos_check=0
Feb 25 11:19:48 rc_service: httpd 1607:notify_rc restart_qos;restart_firewall
Feb 25 11:19:49 kernel: Archer TCP Pure ACK Enabled
Feb 25 11:19:49 kernel: ^[[0;33;41m[ERROR archer] sysport_tm_command,1224: Feature Unavailable^[[0m
Feb 25 11:19:55 BWDPI: fun bitmap = 5ff
Feb 25 11:19:55 A.QoS: qos_count=0, qos_check=0
Feb 25 11:19:58 A.QoS: qos rule is less than 22
Feb 25 11:19:58 A.QoS: restart A.QoS because set_qos_conf / set_qos_on / setup rule fail
Feb 25 11:19:59 A.QoS: qos_count=0, qos_check=1
Feb 25 11:20:02 A.QoS: qos rule is less than 22
Feb 25 11:20:02 A.QoS: restart A.QoS because set_qos_conf / set_qos_on / setup rule fail
I'll try a reboot later and see if it starts logging again

 

[shabbs]

Indeed. I've got cable, 925 down, 18 up.

Same... but my up is a little better.

 

[Jeep]

Same... but my up is a little better.

Similar here as well.

 

[SomeWhereOverTheRainBow]

acsd2 doesn't appear to be working. Same problem was present in 386.4. I was hoping the change to model specific versions might have changed this but it hasn't. (I've only tested this on 2.4GHz)

In the past there were obvious messages (APCS_CSTIMER) in the syslog every 15 minutes when acsd2 was being used. They are no longer present.

Most of the time, when the router boots up the following messages are shown resulting to it defaulting to channel 1:

May  5 06:05:11 acsd: eth6: Selecting 2g band ACS policy
May  5 06:05:11 acsd: acsd_main_loop(1178): sync_id: 26126, status:1, misc.error/abort
May  5 06:05:11 acsd: acs_candidate_score_busy(1081): eth6: busy check failed for chanspec: 0x1803 (1l)
May  5 06:05:11 acsd: acs_candidate_score_intf(1133): eth6: intf check failed for chanspec: 0x1803 (1l)
May  5 06:05:11 acsd: acs_candidate_score_bgnoise(1602): eth6: bgnoise check failed for chanspec: 0x1803 (1l)
May  5 06:05:11 acsd: acs_candidate_score_txop(1860): eth6: txop check failed for chanspec: 0x1803 (1l)
May  5 06:05:11 acsd: acs_candidate_score_cns(1696): eth6: knoise check failed for chanspec: 0x1803 (1l)
:
May  5 06:05:11 acsd: acs_candidate_score_busy(1081): eth6: busy check failed for chanspec: 0x190b (13u)
May  5 06:05:11 acsd: acs_candidate_score_intf(1133): eth6: intf check failed for chanspec: 0x190b (13u)
May  5 06:05:11 acsd: acs_candidate_score_bgnoise(1602): eth6: bgnoise check failed for chanspec: 0x190b (13u)
May  5 06:05:11 acsd: acs_candidate_score_txop(1860): eth6: txop check failed for chanspec: 0x190b (13u)
May  5 06:05:11 acsd: acs_candidate_score_cns(1696): eth6: knoise check failed for chanspec: 0x190b (13u)
May  5 06:05:11 acsd: eth6: selected channel spec: 0x1803 (1l)
May  5 06:05:11 acsd: eth6: Adjusted channel spec: 0x1803 (1l)
May  5 06:05:11 acsd: eth6: selected channel spec: 0x1803 (1l)
May  5 06:05:11 acsd: acs_set_chspec: 0x1803 (1l) for reason APCS_INIT

Regardless of whether those messages were present it doesn't appear to be updating the channels stats when using commands like acs_cli2 -i eth6 dump chanim.

Perhaps the behaviour has changed and it is working as expected. But I'm in a fairly crowded 2.4GHz environment and I've never seen acsd2 change the channel. If I periodically run acs_cli2 -i eth6 autochannel (or manually restart the WiFi) it will occasionally change channels.

@RMerlin I appreciate that the WiFi code is beyond your control but I thought I'd mention it after seeing that you had made some changes effecting acds2.

I am noticing the same issue, for me, when I see these logs I am also losing wireless on some of my devices , sometimes it triggers a wan issue as well. Idk if it is consequence or causation

 

[AntonK]

Similar here as well.

View attachment 39812

Mine.

 

[learning_curve]

Not a member of the #HeavyDownloads Club but seeing as mine is a FTTH 300mb Down / Up subscription with the ISP's router bridged to my Asus router (no throttling at all and excellent VFM) I'm not complaining...

 

[AntonK]

Not a member of the #HeavyDownloads Club but seeing as mine is a FTTH 300mb Down / Up subscription with the ISP's router bridged to my Asus router (no throttling at all and excellent VFM) I'm not complaining... View attachment 39814

Beautiful! I’m not a speed freak either, but I do wonder about this whole symmetrical/asymmetrical service business.

 

[shabbs]

Beautiful! I’m not a speed freak either, but I do wonder about this whole symmetrical/asymmetrical service business.

It's total chiz. Gimme 500/500 and I'll take that any day over 1G down/chiz up.

 

[ColinTaylor]

Can we please stop spamming this thread with pointless off-topic chit chat about download speeds. We're meant to be reporting issues with the beta firmware.

 

[kernol]

To bring back on topic ... we were specifically asked to test QoS [primarily "Traditional"].
There have been some comments on Adaptive [problems ... not working as it should] - but none that I have seen on Traditional QoS ??

I did quite a bit of testing in the Alpha thread and found that Adaptive and Flex were broken under 386.5 - but worked a treat under 386.4 - at least on my RT-AX86U as it did on Asus Stock firmware. No idea why this should be or whether the significant changes to Traditional QoS impacted on the other versions.

Also - has anyone tested Adaptive under Asus stock version 3004-386_46061 ?? If it works properly there then something introduced in Merlin may be the cause of it breaking and such info would help the Maestro.

I'm an avid Cake QoS user given my modest connection speeds - so it is of no consequence to me because Cake works really well under 386.5 ... but others may be impacted?

 

[HorseCalledHorse]

Happy to report that the one 2.4 wireless device I mentioned my RT-AC86U had issues with (a Dolphin robotic pool cleaner) has been connected for 78 hours since I loaded the 386.5 beta.

 

[XIII]

Happy to report that the one 2.4 wireless device I mentioned my RT-AC86U had issues with (a Dolphin robotic pool cleaner) has been connected for 78 hours since I loaded the 386.5 beta.

Unfortunately my (most) problematic 2.4 GHz device disconnected multiple times from my AC86U last night.

 

[kernol]

OK - so no other testers ... crash test dummy to the rescue ... applies to RT-AX86U can't comment on other routers ...

1. Traditional QoS works as never before - scores A+ on https://www.waveform.com/tools/bufferbloat? and has low latency. Note however that like Cake - it disables HW acceleration - both Runner and Flow Cache!
2. Cake QoS works as well as it ever did.
3. Adaptive QoS is definitely broken ... [which means FlexQoS which depends on Adaptive QoS - is also broken @dave14305 ].

Adaptive QoS -

• Keeps HW acceleration enabled - Runner and Flow cache;
• "Bandwidth Monitor" does not provide accurate speed readings;
• Bufferbloat scores a "C" if you lucky;
• Latency scores are spread all over the place;

Log shows the following ...

RT-AX86U-E330 A.QoS: qos_count=0, qos_check=0
RT-AX86U-E330 A.QoS: qos rule is less than 22
RT-AX86U-E330 A.QoS: restart A.QoS because set_qos_conf / set_qos_on / setup rule fail
RT-AX86U-E330 A.QoS: qos_count=0, qos_check=1
RT-AX86U-E330 A.QoS: qos rule is less than 22
RT-AX86U-E330 A.QoS: restart A.QoS because set_qos_conf / set_qos_on / setup rule fail
RT-AX86U-E330 kernel: [tdts_shell_ioctl_stat:256] Recv ioctl req with op 2

Adaptive QoS worked really well under stock 46061 and under Merlin 386.4

 

[Ubimo]

Today I saw this in syslog:

Feb 26 12:14:31 kernel: bcm_mcast_mld_add:833 mc_fdb->rep_list ffffffc013532728 next ffffffc007397420 prev ffffffc007397420 rep_entry->list ffffffc007397420 next ffffffc013532728 prev ffffffc013532728

What's this?

 

[rlj2]

OK - so no other testers ... crash test dummy to the rescue ... applies to RT-AX86U can't comment on other routers ...

1. Traditional QoS works as never before - scores A+ on https://www.waveform.com/tools/bufferbloat? and has low latency. Note however that like Cake - it disables HW acceleration - both Runner and Flow Cache!
2. Cake QoS works as well as it ever did.
3. Adaptive QoS is definitely broken ... [which means FlexQoS which depends on Adaptive QoS - is also broken @dave14305 ].

Adaptive QoS -

• Keeps HW acceleration enabled - Runner and Flow cache;
• "Bandwidth Monitor" does not provide accurate speed readings;
• Bufferbloat scores a "C" if you lucky;
• Latency scores are spread all over the place;

Log shows the following ...

RT-AX86U-E330 A.QoS: qos_count=0, qos_check=0
RT-AX86U-E330 A.QoS: qos rule is less than 22
RT-AX86U-E330 A.QoS: restart A.QoS because set_qos_conf / set_qos_on / setup rule fail
RT-AX86U-E330 A.QoS: qos_count=0, qos_check=1
RT-AX86U-E330 A.QoS: qos rule is less than 22
RT-AX86U-E330 A.QoS: restart A.QoS because set_qos_conf / set_qos_on / setup rule fail
RT-AX86U-E330 kernel: [tdts_shell_ioctl_stat:256] Recv ioctl req with op 2

Adaptive QoS worked really well under stock 46061 and under Merlin 386.4

I showed this video to Rmerlin. Something has been up with flowcache and the AX86u for a long time.

https://imgur.com/uDlxQTj

 

[gattaca]

Updated 3 of 4 RT-AX86U from 386.3_2 to 386.5 Beta this AM. The dirty upgrade went smoothly. I have no AMTM issues which I also updated first.
Updated 2 of 2 RT-AC68U WAPs from 386.3_2 to 386.5 Beta this AM. No issues with dirty upgrade there either.

I followed my general update procedure: backup router configs, backup jffs, reboot router, leave alone 20+ mins, logically disconnect any USB media, perform upgrade, allow router to sit for 15+ mins, update AMTM (if required), final reboot, verify all is OK.

The one issue that landed is I now have the dreaded "X" --> "Internet Status: Disconnected" on the main GUI. I have used both the ping and dns query option listing multiple well known targets for years and they were always working. I tried resetting both off/on- no dice. The internet is accessible, but that "X" just gives me pause.

The nslookup for the router for the infamous target is below. IDK if this is the root-cause. I'm reading thru the other threads posted about this issue now. And yes dns.msftncsi.com is whitelisted in Diversion.

nslookup dns.msftncsi.com
Server: 127.0.0.1
Address 1: 127.0.0.1 localhost.localdomain

Name: dns.msftncsi.com
Address 1: 131.107.255.255 dns.msftncsi.com
Address 2: fd3e:4f5a:5b81::1

Resolution: I followed this post from RMerlin -> Release - Asuswrt-Merlin 386.4 is now available | SmallNetBuilder Forums (snbforums.com)

Hmm, maybe this rev does not like having more than 1 dns target to verify whether it is the MS dns or not? As soon as I added a 2nd dns target with associated IPs, the main GUI reverted to "Disconnected".
Outcome: select 1 dns target and it's IP. I had no issues still listing multiple ping targets.
Stay safe, stay alive. Later. THANK YOU!

 

[JWoo]

Running great. 386.5 Beta 1 seems to be a very stable and solid release.

 

[rotareneg]

I just noticed the following event in the log on my RT-AC66U B1 which was dirty flashed from 386.4 to 386.5. It's been working just fine since the update, I just figured it might be worth mentioning only because I couldn't find any other references to nt_monitor crashes when searching the forum.

Feb 25 17:17:16 kernel: nt_monitor/283: potentially unexpected fatal signal 6.
Feb 25 17:17:16 kernel: Pid: 283, comm:           nt_monitor
Feb 25 17:17:16 kernel: CPU: 1    Tainted: P             (2.6.36.4brcmarm #1)
Feb 25 17:17:16 kernel: PC is at 0x406aa340
Feb 25 17:17:16 kernel: LR is at 0x40131214
Feb 25 17:17:16 kernel: pc : [<406aa340>]    lr : [<40131214>]    psr: 60000010
Feb 25 17:17:16 kernel: sp : bdfff530  ip : 4013be5c  fp : 00014717
Feb 25 17:17:16 kernel: r10: 4070208c  r9 : 4012f6fc  r8 : 000009fc
Feb 25 17:17:16 kernel: r7 : 00000025  r6 : 00000006  r5 : 0000011b  r4 : 4013c038
Feb 25 17:17:16 kernel: r3 : 4013c038  r2 : 00000803  r1 : 00000006  r0 : 00000000
Feb 25 17:17:16 kernel: Flags: nZCv  IRQs on  FIQs on  Mode USER_32  ISA ARM  Segment user
Feb 25 17:17:16 kernel: Control: 10c53c7d  Table: 9da8804a  DAC: 00000015
Feb 25 17:17:16 kernel: nt_monitor/219: potentially unexpected fatal signal 6.
Feb 25 17:17:16 kernel: nt_monitor/187: potentially unexpected fatal signal 6.
Feb 25 17:17:16 kernel: Pid: 187, comm:           nt_monitor
Feb 25 17:17:16 kernel: CPU: 1    Tainted: P             (2.6.36.4brcmarm #1)
Feb 25 17:17:16 kernel: PC is at 0x406aa890
Feb 25 17:17:16 kernel: LR is at 0x40131ee4
Feb 25 17:17:16 kernel: pc : [<406aa890>]    lr : [<40131ee4>]    psr: 60000010
Feb 25 17:17:16 kernel: sp : be992d50  ip : 4013bde8  fp : 00000000
Feb 25 17:17:16 kernel: r10: be992df8  r9 : 0000907c  r8 : 000086b0
Feb 25 17:17:16 kernel: r7 : 000000a2  r6 : be992de4  r5 : be992d98  r4 : be992d98
Feb 25 17:17:16 kernel: r3 : 00000000  r2 : 00000258  r1 : be992d98  r0 : fffffdfc
Feb 25 17:17:16 kernel: Flags: nZCv  IRQs on  FIQs on  Mode USER_32  ISA ARM  Segment user
Feb 25 17:17:16 kernel: Control: 10c53c7d  Table: 9da8804a  DAC: 00000015
Feb 25 17:17:16 kernel: Pid: 219, comm:           nt_monitor
Feb 25 17:17:16 kernel: CPU: 0    Tainted: P             (2.6.36.4brcmarm #1)
Feb 25 17:17:16 kernel: PC is at 0x406aa890
Feb 25 17:17:16 kernel: LR is at 0x40131ee4
Feb 25 17:17:16 kernel: pc : [<406aa890>]    lr : [<40131ee4>]    psr: 60000010
Feb 25 17:17:16 kernel: sp : be1ff528  ip : 4013bde8  fp : 000142af
Feb 25 17:17:16 kernel: r10: 00000000  r9 : 401796e7  r8 : 4070227c
Feb 25 17:17:16 kernel: r7 : 000000a2  r6 : 001e8481  r5 : be1ff550  r4 : 00000000
Feb 25 17:17:16 kernel: r3 : 00000001  r2 : 00000230  r1 : 00000000  r0 : fffffdfc
Feb 25 17:17:16 kernel: Flags: nZCv  IRQs on  FIQs on  Mode USER_32  ISA ARM  Segment user
Feb 25 17:17:17 kernel: Control: 10c53c7d  Table: 9da8804a  DAC: 00000015