[Preview] Asuswrt-Merlin 384.3 pre-release test builds

[Datalink]

Running the stock Version 3.0.0.4.384.10007, the first three produce the typical warning page. The last links produce a result such as this, which is the last link:

wrs91.winshipway.com/
Category: 58(Shopping)
WTP Score: 91(Safe)
Credibility: 3(Safe) [Obsoleted]
By CoreTech WRS team ([email protected])

 

[DanTheMan]

Running the stock Version 3.0.0.4.384.10007, the first three produce the typical warning page. The last links produce a result such as this, which is the last link:

wrs91.winshipway.com/
Category: 58(Shopping)
WTP Score: 91(Safe)
Credibility: 3(Safe) [Obsoleted]
By CoreTech WRS team ([email protected])

Hmm, so must be something with the alpha or me using Skynet/AB-Solution...since I have AI Protection enabled but none of the links produce the warning page. So I should assume AI Protection isn’t running for me at the moment.

Thanks for checking those test links out for me on the latest stock firmware, that’s exactly what I was wondering and didn’t want to flash back to stock to find out, I appreciate it.

 

[RMerlin]

Hmm, so must be something with the alpha or me using Skynet/AB-Solution...since I have AI Protection enabled but none of the links produce the warning page.

If Skynet blocks access to the test site, then it won't trigger the warning.

The warnings do show on my RT-AC88U for pages that should trigger them.

 

[RMerlin]

I uploaded a new RT-AC56U test builds. This one contains CTF/PPPoE as well as multicast fixes from 382_50010. Please give it a shot.

If you still get non-working QoS with it, make sure you reconfigure your rules. My RT-AC56U reproduced the issue until I reconfigured my preferred priorities, then rebooted. After that rules were always properly configured (tested both DHCP and PPPoE).

 

[RMerlin]

They don't all produce the warning page, but I haven't looked into it to determine the reason.

Some of these test links are to test different categories, not just malicious ones. That last link for instance is to test if you want to block access to online shopping site (see the category shown on the displayed page).

 

[DanTheMan]

If Skynet blocks access to the test site, then it won't trigger the warning.

The warnings do show on my RT-AC88U for pages that should trigger them.

Thanks for checking, I’ll have to look through Skynet debug logs to see if it is blocking them. Strange thing is, the pages that should be blocked ( top 3 ) load up and look like this below...so it doesn’t seem like they’re being blocked by anything, AI, Skynet or AB-Solution.

wrs21.winshipway.com
Category: 74(Spyware)
WTP Score: 21(Dangerous)
Credibility: 1(Dangerous) [Obsoleted]

 

[charlie2alpha]

I uploaded a new RT-AC56U test builds. This one contains CTF/PPPoE as well as multicast fixes from 382_50010. Please give it a shot.

If you still get non-working QoS with it, make sure you reconfigure your rules. My RT-AC56U reproduced the issue until I reconfigured my preferred priorities, then rebooted. After that rules were always properly configured (tested both DHCP and PPPoE).

Installed 384.3_alpha2-g6dfe645 that I found in the test folder. QoS started normally for me, didn't have to touch anything in my rules. Enabled CTF, will know for certain if it works with my PPPoE connection later into the day, it is always easier to spot while trying to download torrents than doing a simple speedtest with my 50Mbit line.

 

[RMerlin]

Installed 384.3_alpha2-g6dfe645 that I found in the test folder. QoS started normally for me, didn't have to touch anything in my rules. Enabled CTF, will know for certain if it works with my PPPoE connection later into the day, it is always easier to spot while trying to download torrents than doing a simple speedtest with my 50Mbit line.

Make sure you have this build datestamp (from the Tools -> Sysinfo page):

Mon Jan 29 03:55:36 UTC 2018 merlin@6dfe645

For a few minutes there was another test build on Onedrive that was missing a few Trend Micro component updates - that prevented the Trend Micro engine from loading.

 

[charlie2alpha]

Make sure you have this build datestamp (from the Tools -> Sysinfo page):

Mon Jan 29 03:55:36 UTC 2018 merlin@6dfe645

For a few minutes there was another test build on Onedrive that was missing a few Trend Micro component updates - that prevented the Trend Micro engine from loading.

Yes, that's indeed the build I have. I tried to download the latest Ubuntu ISO via torrent, I think CTF does work but has less of an effect than I thought it would. My torrent client got about 300 peers, downloaded at 5.2 MB/sec and the RT-AC56U CPU was hovering between 50% and 80%

 

[charlie2alpha]

Feeling rather lonely as an RT-AC56U user, nobody else wants to test builds for this model? @RMerlin I am curious, what was the issue in the old frankenbuild that prevented QoS to start? As I saw reports from some RT-AC68U owners having similar problems with the first alphas of the 384 branch I am speculating that it was not something isolated to my model. I'm just happy you managed to migrate this model to the 384 branch, so far it works fine. Did not test stuff like VPN etc.

 

[John35]

Quick question - I see the RT-AC87U has finally got a 382 release (from ASUS), is this good, in that they are working on it, or bad as a 384 version may be a long way away (ASUS and Merlin)?

 

[RMerlin]

what was the issue in the old frankenbuild that prevented QoS to start?

No idea, I never really reproduced it with my RT-AC56U (did only very limited tests at the time). Closest I've been was with this new version where it wouldn't initialize QoS until I cleared a few nvram values (such as the one containing my priority preferences)

 

[eastavin]

Test Ai Protection using the links from the Trend Micro Web Protection test page:

https://success.trendmicro.com/solu...the-web-reputation-feature-in-officescan-osce

They don't all produce the warning page, but I haven't looked into it to determine the reason. The warning page is the result of the reputation scores.

I too have the same concern. In 382 beta on my RT-AC68U I was getting at least 1-2 hit a day in the 2way IPS reports that the router had been saved from badness and 1 hit a week on the malicious site blocking report. Usually nothing on the infected device report.

Since moving to 384 alpha I have had only 1 report of a malicious adsense, and only 1 report on 2 way IPS that AI Cloud was trying to brute force a password on my NAS. And again nothing on the infected device report. The above link did cause every instance of 41 and lower to get trapped in the malicious site blocking but I am still suspicious that the 2-way IPS may not be as successful as it was in 382.

 

[eastavin]

Client selection tool in Web History under Adaptive QOS does not select individual clients.

Also have been unable to get Download Master to work under the USB application tab. It starts but freezes within seconds.

Also see this qos error in the system log all the time when I have qos on.

Edward
RT-AC68U

 

[h3lmut]

I uploaded a new RT-AC56U test builds. This one contains CTF/PPPoE as well as multicast fixes from 382_50010. Please give it a shot.

If you still get non-working QoS with it, make sure you reconfigure your rules. My RT-AC56U reproduced the issue until I reconfigured my preferred priorities, then rebooted. After that rules were always properly configured (tested both DHCP and PPPoE).

I've tested it with fresh qos script, fq_codel, pppoe I get this error:

Jan 29 17:20:32 kernel: ERR[parse_qos_conf:932] Can't set new QoS conf while QoS is started!
Jan 29 17:20:32 kernel: ERR[ioctl_iqos_op_config:3592] parse qos_conf error!!
Jan 29 17:20:32 kernel: ioctl_iqos_op_config() fail!
Jan 29 17:20:32 kernel: ERR[qos_start:3344] QoS is already started!
Jan 29 17:20:32 kernel: ioctl_iqos_op_switch(1) fail!


after disabled fresh qos script I get:

Jan 29 17:54:26 rc_service: httpd 273:notify_rc restart_qos;restart_firewall
Jan 29 17:54:47 nat: apply nat rules (/tmp/nat_rules_ppp0_eth0)
Jan 29 17:54:47 custom_script: Running /jffs/scripts/firewall-start (args: ppp0)
Jan 29 17:55:13 rc_service: httpd 273:notify_rc restart_qos;restart_firewall
Jan 29 17:55:33 nat: apply nat rules (/tmp/nat_rules_ppp0_eth0)
Jan 29 17:55:33 custom_script: Running /jffs/scripts/firewall-start (args: ppp0)

I noticed on the qos statistic page that the download tab is blank after this update. upload stats working fine.


If I set qos to sfq without fresh qos script (qos statistic download tab blank too):

Jan 29 18:04:55 rc_service: httpd 273:notify_rc restart_qos;restart_firewall
Jan 29 18:05:18 kernel: ERR[parse_qos_conf:932] Can't set new QoS conf while QoS is started!
Jan 29 18:05:18 kernel: ERR[ioctl_iqos_op_config:3592] parse qos_conf error!!
Jan 29 18:05:18 kernel: ioctl_iqos_op_config() fail!
Jan 29 18:05:18 kernel: ERR[qos_start:3344] QoS is already started!
Jan 29 18:05:18 kernel: ioctl_iqos_op_switch(1) fail!
Jan 29 18:05:21 kernel: ERR[parse_qos_conf:932] Can't set new QoS conf while QoS is started!
Jan 29 18:05:21 kernel: ERR[ioctl_iqos_op_config:3592] parse qos_conf error!!
Jan 29 18:05:21 kernel: ioctl_iqos_op_config() fail!
Jan 29 18:05:21 kernel: ERR[qos_start:3344] QoS is already started!
Jan 29 18:05:21 kernel: ioctl_iqos_op_switch(1) fail!


I never get the notification which says that fq_codel was set in systemlog

 

[skeal]

The traffic analyzer stats tab doesn't populate with any clients. It shows zero clients. You probably have heard about this or maybe even closed source code but I thought I would send a heads up.

 

[charlie2alpha]

I've tested it with fresh qos script, fq_codel, pppoe I get this error:

Jan 29 17:20:32 kernel: ERR[parse_qos_conf:932] Can't set new QoS conf while QoS is started!
Jan 29 17:20:32 kernel: ERR[ioctl_iqos_op_config:3592] parse qos_conf error!!
Jan 29 17:20:32 kernel: ioctl_iqos_op_config() fail!
Jan 29 17:20:32 kernel: ERR[qos_start:3344] QoS is already started!
Jan 29 17:20:32 kernel: ioctl_iqos_op_switch(1) fail!


after disabled fresh qos script I get:

Jan 29 17:54:26 rc_service: httpd 273:notify_rc restart_qos;restart_firewall
Jan 29 17:54:47 nat: apply nat rules (/tmp/nat_rules_ppp0_eth0)
Jan 29 17:54:47 custom_script: Running /jffs/scripts/firewall-start (args: ppp0)
Jan 29 17:55:13 rc_service: httpd 273:notify_rc restart_qos;restart_firewall
Jan 29 17:55:33 nat: apply nat rules (/tmp/nat_rules_ppp0_eth0)
Jan 29 17:55:33 custom_script: Running /jffs/scripts/firewall-start (args: ppp0)

I noticed on the qos statistic page that the download tab is blank after this update. upload stats working fine.


If I set qos to sfq without fresh qos script (qos statistic download tab blank too):

Jan 29 18:04:55 rc_service: httpd 273:notify_rc restart_qos;restart_firewall
Jan 29 18:05:18 kernel: ERR[parse_qos_conf:932] Can't set new QoS conf while QoS is started!
Jan 29 18:05:18 kernel: ERR[ioctl_iqos_op_config:3592] parse qos_conf error!!
Jan 29 18:05:18 kernel: ioctl_iqos_op_config() fail!
Jan 29 18:05:18 kernel: ERR[qos_start:3344] QoS is already started!
Jan 29 18:05:18 kernel: ioctl_iqos_op_switch(1) fail!
Jan 29 18:05:21 kernel: ERR[parse_qos_conf:932] Can't set new QoS conf while QoS is started!
Jan 29 18:05:21 kernel: ERR[ioctl_iqos_op_config:3592] parse qos_conf error!!
Jan 29 18:05:21 kernel: ioctl_iqos_op_config() fail!
Jan 29 18:05:21 kernel: ERR[qos_start:3344] QoS is already started!
Jan 29 18:05:21 kernel: ioctl_iqos_op_switch(1) fail!


I never get the notification which says that fq_codel was set in systemlog

I had something similar when I first enabled the new FreshJR beta script, but after a while it all started working normally. I still need to test what happens after a reboot.

 

[h3lmut]

so what Iam seeing is that qos is working fine with fq_codel. dslreports shows a normal result and feeling with netflix + downloads in background is very good

 

[klemensior]

Just uploaded test build to AC56u. Bandwidth limiter for guest network was not working properly for outgoing traffic right after upload (incomming was ok). After setting it once again (without reboot), it's working as it should.

 

[DanTheMan]

I too have the same concern. In 382 beta on my RT-AC68U I was getting at least 1-2 hit a day in the 2way IPS reports that the router had been saved from badness and 1 hit a week on the malicious site blocking report. Usually nothing on the infected device report.

Since moving to 384 alpha I have had only 1 report of a malicious adsense, and only 1 report on 2 way IPS that AI Cloud was trying to brute force a password on my NAS. And again nothing on the infected device report. The above link did cause every instance of 41 and lower to get trapped in the malicious site blocking but I am still suspicious that the 2-way IPS may not be as successful as it was in 382.

I suppose it’s a good thing you are getting some malicious sites trapped by AI Protection.
I’ve verified my counts haven’t changed since I updated firmwares & no trend micro test links throw up a warning page so I’m assuming AI Protection simply isn’t working for me at the moment. Not sure what else to try other than a clean wipe. I’ve turned AI Protection on off multiple times, rebooted ( via router’s GUI ).