[Beta 384/NG] Asuswrt-merlin 384.4 Beta is now available

[RMerlin]

I did indeed determine this by not seeing the green lock in Firefox when accessing https://router.asus.com:8443 (but did not check the files on the router).

If the padlock was missing, then it was indeed not using the correct certificate. That scenario I haven't been able to reproduce so far on my RT-AC86U.

What I was referring to was the info shown on the DDNS page, where it shows the hostname, expiration date, etc... That info might not be accurate if AiCloud overwrote the file (which is what I mostly addressed in a recent fix, but still one scenario that I can't control - AiCloud's cert generation is in the smbdav closed source module...)

 

[RMerlin]

I saw this was reported before but just wanted to confirm this is showing in my logs also. If I go to the QoS settings and hit APPLY to force QoS to restart it will repeat this in the logs again. I just flashed today, did a factory reset afterwards. 384.4_beta2

Ignore these. Asus's Trend Micro code checks too quickly to determine if the Adaptive QoS rules have been applied - it will simply recheck a number of times until they finally complete, at which time it will signal that it has successfully applied all rules. The patch script I use to implement fq_codel makes the process take a little longer than on the stock firmware (where the same warning can also appear, but less frequently).

 

[RejZoR]

I'm assuming the fix for RT-AC87U Qantenna watchdog is included in these to prevent random wireless dropping that we experienced in older versions?

 

[PeterV]

@PeterV @XIII

https://drive.google.com/open?id=1RDFciwMMTsAk89ox2QWKYn7hIEdN9yVD

Try this, this included commit.
https://github.com/RMerl/asuswrt-merlin.ng/commit/a4e85534314734ed316bf6ac90b691159be62f09

I guess it is timing issue ' -'
If it works, then wait next beta or snapshot.

Thanks, tried, but without any results ...
During the day, as I said before, I made reset config of the router, and initially installed only AB-Solution with pixel-srv.
services-start works without problem
After that I made several changes via web-interface, and after final reboot - it was stop working.
With your version - no changes.
Now I reverted back beta 1 (without clearing jffs, usb, didn't reset of configuration) - and everything is working.
Yes, it still no records in the log something like "custom_script: Running /jffs/scripts/services-start", but I can see the messages from this script, like " admin: AB-Solution started rc.unslung via /jffs/scripts/services-start".
So, the same configs, the same jffs and scrips, but under beta1 it's working, under beta2 (and unofficial beta3) - don't work.
And, I'm sure - it's depend on something configurable from web-interface ...

beta2(3) grep 'scripts' from log

2018-03-08T20:02:07+02:00 192.168.99.142 custom_script: Running /jffs/scripts/wan-start (args: 0)
2018-03-08T20:02:07+02:00 192.168.99.142 admin: AB-Solution created br0:pixelserv 192.168.1.2 via /jffs/scripts/wan-start
2018-03-08T20:02:07+02:00 192.168.99.142 custom_script: Running /jffs/scripts/firewall-start (args: eth0)
2018-03-08T20:02:09+02:00 192.168.99.142 custom_script: Running /jffs/scripts/firewall-start (args: eth0)
2018-03-08T20:02:16+02:00 192.168.99.142 custom_script: Running /jffs/scripts/firewall-start (args: eth0)
2018-03-08T20:03:32+02:00 192.168.99.142 custom_script: Running /jffs/scripts/wan-start (args: 0)
2018-03-08T20:03:32+02:00 192.168.99.142 admin: AB-Solution created br0:pixelserv 192.168.1.2 via /jffs/scripts/wan-start
2018-03-08T20:03:36+02:00 192.168.99.142 custom_script: Running /jffs/scripts/firewall-start (args: eth0)
2018-03-08T20:03:39+02:00 192.168.99.142 custom_script: Running /jffs/scripts/firewall-start (args: eth0)
2018-03-08T20:03:42+02:00 192.168.99.142 custom_script: Running /jffs/scripts/post-mount (args: /tmp/mnt/entware)
2018-03-08T20:04:24+02:00 192.168.99.142 custom_script: Running /jffs/scripts/firewall-start (args: eth0)
2018-03-08T20:04:36+02:00 192.168.99.142 custom_script: Running /jffs/scripts/post-mount (args: /tmp/mnt/data)
2018-03-08T20:04:36+02:00 192.168.99.142 admin: AB-Solution added entries via /jffs/scripts/post-mount
2018-03-08T20:04:36+02:00 192.168.99.142 admin: runnig swapon via /jffs/scripts/post-mount
2018-03-08T20:04:36+02:00 192.168.99.142 custom_script: Running /jffs/scripts/dnsmasq.postconf (args: /etc/dnsmasq.conf)
2018-03-08T20:04:36+02:00 192.168.99.142 admin: AB-Solution linked ab_dnsmasq_postconf.sh via /jffs/scripts/dnsmasq.postconf

beta1 'scripts' from log

2018-03-08T20:17:06+02:00 192.168.99.142 custom_script: Running /jffs/scripts/firewall-start (args: eth0)
2018-03-08T20:17:08+02:00 192.168.99.142 custom_script: Running /jffs/scripts/post-mount (args: /tmp/mnt/entware)
2018-03-08T20:17:09+02:00 192.168.99.142 custom_script: Running /jffs/scripts/firewall-start (args: eth0)
2018-03-08T20:17:09+02:00 192.168.99.142 admin: AB-Solution started rc.unslung via /jffs/scripts/services-start
2018-03-08T20:17:09+02:00 192.168.99.142 admin: Started pixelserv-tls (AB-Solution) from /jffs/scripts/services-start.
2018-03-08T20:17:09+02:00 192.168.99.142 custom_script: Running /jffs/scripts/post-mount (args: /tmp/mnt/data)
2018-03-08T20:17:09+02:00 192.168.99.142 admin: AB-Solution added entries via /jffs/scripts/post-mount
2018-03-08T20:17:09+02:00 192.168.99.142 admin: runnig swapon via /jffs/scripts/post-mount
2018-03-08T20:17:09+02:00 192.168.99.142 custom_script: Running /jffs/scripts/dnsmasq.postconf (args: /etc/dnsmasq.conf)
2018-03-08T20:17:10+02:00 192.168.99.142 admin: AB-Solution linked ab_dnsmasq_postconf.sh via /jffs/scripts/dnsmasq.postconf
2018-03-08T20:17:20+02:00 192.168.99.142 custom_script: Running /jffs/scripts/firewall-start (args: eth0)

 

[PeterV]

Another interesting things:
1. /jffs/scripts/services-stop will run only after reboot from command line. And never - when it was done via web-interface.
2. /jffs/scripts/unmount will run only during new firmware upload. And never via any reboot, nor from command line, nor via web-interface.

 

[RMerlin]

I'm assuming the fix for RT-AC87U Qantenna watchdog is included in these to prevent random wireless dropping that we experienced in older versions?

Yes, commit e4853fb2e1a0f01229868f8c18b12c4e285f4198 .

 

[PeterV]

Ok. I'm tired to find answer - why ...
Now I have these lines in post-mount

if [ "$1" = "/tmp/mnt/entware" ];then.
    logger "runnig services-start via $0"
    [ -x /jffs/scripts/services-start ] && /jffs/scripts/services-start
fi

And it's work like a charm ...

 

[RMerlin]

Upgraded my AC86U from beta 1 to beta 2.

Again my carefully created SSL certificate/key were overwritten by router generated ones.

BTW, you can upload them using SCP, they reside in /jffs/ssl/ as cert.pem and key.pem. Restart httpd after uploading to apply them.

 

[Rene1978]

@RMerlin ,

Any ideas on my analysis below? Can I provide more info somehow to help you?

Running a RT-87U here and since I installed 384.4-Beta1 and 2 my internet speed (using speedtest.net) has decreased dramatically.

Situation:

• ISP linespeed: 150 Mb/s down / 50 Mb/s up (Cable)
• ISP modem running as Router: Full speed using RJ-45 connection PC direct to modem
• ISP modem running as Bridge: Full speed using RJ-45 connection using PC direct to modem
  
• Running 380.X --> Full speed through ac WiFi and RJ-45 to RT-87U
• Running 384.4 Beta1 & 2 --> Download max 35 Mb/s (wired & WiFi same) / Upload 45 Mb/s (QoS enabled)
  
• Running 384.4 Beta1 & 2 --> Download max 35 Mb/s (wired & WiFi same) / Upload 45 Mb/s (QoS fully disabled)

Anyone any tips? The problem is somewhere in 384.4, but I cannot find the problem..

 

[XIII]

BTW, you can upload them using SCP, they reside in /jffs/ssl/ as cert.pem and key.pem. Restart httpd after uploading to apply them.

I uploaded them via the web UI, but I might try this if it happens again with Beta 3.

 

[vladsuk]

1) Exact same sd-idle daemon as before. Spindown is dependent on the disk's firmware, and whether any service accesses that disk or not.
2) Make sure you enable data collection: https://github.com/RMerl/asuswrt-merlin/wiki/Wi-Fi-Radar

Thanks for explanation, Wifi radar already works, the reason was MAC filtering enabled.

What about wifi timer reset after router restart? Is it normal?

 

[XIII]

Entware starts fine after I moved the starting into post-mount as described here:

https://github.com/RMerl/asuswrt-merlin/wiki/USB-Disk-Check-at-Boot

Good enough for now. Maybe even a keeper?

 

[primitivo]

@RMerlin there must be a bug somewhere. Just bought RT-AC86U, loaded it with latest 384.4_beta2 + did a factory reset + JFFS format + enabled custom scripts, then when I go to "network map" tab and click on clients "view list", the httpd process get rebooted:

Mar 9 04:03:04 watchdog: restart httpd
Mar 9 04:03:04 rc_service: watchdog 795:notify_rc stop_httpd
Mar 9 04:03:04 rc_service: watchdog 795:notify_rc start_httpd
Mar 9 04:03:04 RT-AC86U: start httpd:80

Could it be related to this?

I am unable to create this folder via ssh though:

admin@RT-AC86U-B768:/tmp/home/root# mkdir /jffs/usericon/
mkdir: can't create directory '/jffs/usericon/': Read-only file system

Any solution or possible fix that you are going to apply?

 

[primitivo]

@RMerlin there must be a bug somewhere. Just bought RT-AC86U, loaded it with latest 384.4_beta2 + did a factory reset + JFFS format + enabled custom scripts, then when I go to "network map" tab and click on clients "view list", the httpd process get rebooted:

Mar 9 04:03:04 watchdog: restart httpd
Mar 9 04:03:04 rc_service: watchdog 795:notify_rc stop_httpd
Mar 9 04:03:04 rc_service: watchdog 795:notify_rc start_httpd
Mar 9 04:03:04 RT-AC86U: start httpd:80

Could it be related to this?

I am unable to create this folder via ssh though:

admin@RT-AC86U-B768:/tmp/home/root# mkdir /jffs/usericon/
mkdir: can't create directory '/jffs/usericon/': Read-only file system

Any solution or possible fix that you are going to apply?

Forget it. Apparently after all this years and code changes from 380.xx to 384.xx it still takes twice reboots to get JFFS up and running.

 

[tmoe]

@RMerlin ,

Any ideas on my analysis below? Can I provide more info somehow to help you?

Running a RT-87U here and since I installed 384.4-Beta1 and 2 my internet speed (using speedtest.net) has decreased dramatically.

Situation:

• ISP linespeed: 150 Mb/s down / 50 Mb/s up (Cable)
• ISP modem running as Router: Full speed using RJ-45 connection PC direct to modem
• ISP modem running as Bridge: Full speed using RJ-45 connection using PC direct to modem
  
• Running 380.X --> Full speed through ac WiFi and RJ-45 to RT-87U
• Running 384.4 Beta1 & 2 --> Download max 35 Mb/s (wired & WiFi same) / Upload 45 Mb/s (QoS enabled)
  
• Running 384.4 Beta1 & 2 --> Download max 35 Mb/s (wired & WiFi same) / Upload 45 Mb/s (QoS fully disabled)

Anyone any tips? The problem is somewhere in 384.4, but I cannot find the problem..

i'm on rt-87u and I'm running 384.4 beta 1 and no differences in upload or download, wired/wireless. I did factory reset not sure if that mattered, as well as complete flush of browser cache. Seems to be running as smooth as any before, I reboot once a week and don't have wireless disconnects.

 

[Odkrys]

Thanks, tried, but without any results ...

My problem has resolved on beta3.
Maybe it is your specific issue.
I am sorry I can't help you.

 

[RMerlin]

@RMerlin ,

Any ideas on my analysis below? Can I provide more info somehow to help you?

Running a RT-87U here and since I installed 384.4-Beta1 and 2 my internet speed (using speedtest.net) has decreased dramatically.

Situation:

• ISP linespeed: 150 Mb/s down / 50 Mb/s up (Cable)
• ISP modem running as Router: Full speed using RJ-45 connection PC direct to modem
• ISP modem running as Bridge: Full speed using RJ-45 connection using PC direct to modem
  
• Running 380.X --> Full speed through ac WiFi and RJ-45 to RT-87U
• Running 384.4 Beta1 & 2 --> Download max 35 Mb/s (wired & WiFi same) / Upload 45 Mb/s (QoS enabled)
  
• Running 384.4 Beta1 & 2 --> Download max 35 Mb/s (wired & WiFi same) / Upload 45 Mb/s (QoS fully disabled)

Anyone any tips? The problem is somewhere in 384.4, but I cannot find the problem..

Turn off your modem for 10-15 mins to reset your connection. There's no reason for the firmware to slow things down, people are able to reach close to 900 Mbps with that model.

 

[RMerlin]

Thanks for explanation, Wifi radar already works, the reason was MAC filtering enabled.

What about wifi timer reset after router restart? Is it normal?

No idea. That code is Asus's, I haven't touched it.

 

[Rene1978]

Turn off your modem for 10-15 mins to reset your connection. There's no reason for the firmware to slow things down, people are able to reach close to 900 Mbps with that model.

@RMerlin, Thanks. I have rebooted both the modem and the RT-87U router a few times and it is back in working order. The reason why it did why it did still illudes me, but as long as it does not happen again I am happy. Since it did not occur in the direct modem connection I assumed the RT_87U was at fault. Especially since it happended after the 384.4 upgrade. Purely interested, why is there no reason for the firmware to slow things down? Doesn't it control the routing (layer 3) on the WAN to LAN connection, as well as processing the traffic through QoS, Firewall etc.?

Anyway, keep up the good work. Happy that I can keep my RT-87U in service a little longer before it really goes out of support.

 

[RMerlin]

The reason why it did why it did still illudes me, but as long as it does not happen again I am happy.

One common cause is that between firmware changes, your router might end up using a different MAC to request a lease. Some ISPs don't deal well with that, and seem to limit your speed until you keep the modem turned off for an extended period of time, releasing the original lease.