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

[Vincent Meyer]

Will the RT-AC66U have a 384.4 beta ? If not, will there be a release for this model when the beta cycle is over?

I'm running 384.4 beta 3 on an RT-AC88U in our main office, and everything is smooth. Our other two locations are on the RT-AC66U and I would love to have them on the same code base. They're on the last legacy code release. The performance on the beta on our main router has been fantastic so far, no problems or glitches. Thank you, Merlin!

 

[Clark Griswald]

I haven’t seen this behavior on my 1900P. I just checked and it’s disabled. I know if you install the Asus app, it will turn that feature on automatically.

I have the asus app installed on ios devices, and my “Enable Web Access from Wan” is disabled and has not been automatically enabled.

 

[scjr]

I have the asus app installed on ios devices, and my “Enable Web Access from Wan” is disabled and has not been automatically enabled.

Interesting. It’s been awhile since it’s been installed, but when it was it enabled that feature. Thanks for confirming.

 

[agilani]

Hello,

I have been long time user, and lurker on these forums.
Have been running Asuswrt-Merlin for many years now. Current setup is RT-AC88U
Currently running 384.4 Beta 3 and My Wireless 2.4Ghz and 5Ghz both die once a day or twice. I have restart scheduled at 3am but that isn't enough as it seems it is happening more often.
After major update I always do factory reset and manually enter my config just to make sure things are clean.

Here are last few lines of logs before wireless decided to take a dump.


Mar 13 08:19:03 kernel: DUMP CONSOLE: 045732.138 0x00ec8166 0x00c98166 0x00c98166 0x00c98166
Mar 13 08:19:03 kernel: DUMP CONSOLE: 045732.138 0x00ec8166 0x00c98166 0x00c98166 0x00c98166
Mar 13 08:19:03 kernel: DUMP CONSOLE: 045732.138 PC (psmdebug):
Mar 13 08:19:03 kernel: DUMP CONSOLE: 045732.138 0x00ff8028 0x00ff8047 0x00fe805b 0x00ec8064
Mar 13 08:19:03 kernel: DUMP CONSOLE: 045732.138 0x00ff8028 0x00ff8048 0x00ff8061 0x00ff8067
Mar 13 08:19:03 kernel: DUMP CONSOLE: 045732.138 psmx stack_status : 0x1
.
.
.
Feb 13 18:00:17 syslogd started: BusyBox v1.25.1

Are you running other repeaters? Those symptoms seems to be similar to what a few of us have been seeing with the older version of the code running with additional repeaters. The wireless, both 2.4 and 5ghz stop working. Only option right now is to go back to the 380.69 branch.

 

[FatBoyNL]

I came from a legacy version so now did a factory reset and manual re-config and everything is fine now, thanks

Btw, i think the DST setting is (still?) wrong for GMT +1 (Amsterdam). I found this old post; https://www.snbforums.com/threads/rt-n66u-system-time-wrong.13427/#post-212517

And i've configured it like that now but by default it says 2th (or 3rd... don't recall exactly) sunday and hour 2 for both start and end which is wrong.

Experienced that behaviour here in Utrecht as well
You probably got the remark in yellow writing that your locale isn't the same as your region. Solution is to set it to set summer time to start at the 4th sunday in March, like you did.

Summer time started yesterday in the USA, but not in Europe. Just a coincidence, not beta related I think. Also can't find any locale setting in my RT-AC87U though I could be very blind. Perhaps tied to language settings?

 

[HardCat]

384.4 Beta 3 is now available for download. List of changes:

0206b32 Updated documentation
644942d httpd: check that opendir() succeeded, otherwise httpd would crash
a25de1c entware: add 64-bit support for HND platform
2aec002 entware: point setup script to the new Entware installers (following the NG/3X repos merge)
40ba6c4 sd-idle: fix spindown/up logging
a4e8553 rc: move services-start custom script to the very end of start_services()
65183bd rc: when preparing httpd key/cert from a stored pair, also generate server.pem with them for AiCloud
cc353fb httpd: gencert: no longer generate cfgsync cert (now handled by cfgsync itself)
956c32c webui: update Site Survey page for AiMesh-capable models to use the new wlc_scan_state values from GPL 20379
aa3949d webui: fix broken DST offset parser (Asus bug in 20379)
3f1ea25 httpd: restart daemon after the user upload a new SSL certificate
9f158cd Bumped revision to beta 3

Please test the new Entware installer.

This should hopefully be the final beta.

@RMerlin - I think there is a very minor syntax error in the entware-setup.sh script.

line 111 is missing the second "l" for /dev/null

tar -czf "$entPartition/jffs_scripts_backup_$(date +%F_%H-%M).tgz" /jffs/scripts/* >/dev/nul

Not sure if this may also impact @john9527 with his recent release too, he may want to check.

Cheers...

 

[XIII]

Don't have the time to investigate right now, but both my iPhone and iPad cannot connect to the IPsec VPN on my AC86U (which did work OK with a previous beta).

This is the only thing I see in the log:

Mar 13 22:29:00 06[IKE] 192.168.1.xxx is initiating a Main Mode IKE_SA
Mar 13 22:29:28 02[IKE] 192.168.1.yyy is initiating a Main Mode IKE_SA

(with xxx being my iPhone and yyy my iPad)

I'm not sure how to investigate this. Suggestions?

 

[XIII]

PS: apparently the time is 1 hour off here as well

(however "data" via ssh does report 21:32, so I'm surprised to see 22:29 in the log)

 

[PDinDetroit]

RT-AC86U updated yesterday, no issues. Had 3 desktops, 3 laptops, and 3 VM's updating Windows 7/10/Server 2016 today with no issues.

 

[gponcho]

I have no plan to support the GT-AC5300, only the RT-AC5300.



No idea, I don't use link aggregation, as it's mostly useless in a home environment. It requires multiple concurrent clients, and it also requires disks that are fast enough to handle two concurrent 1 Gbps link - that's rarely the case with mechanical drives.

Thanks Merlin much appreciated.

 

[gponcho]

It should: https://asuswrt.lostrealm.ca/about

EDIT: Never mind. The RT-AC5300 is supported just not in the 384.X firmwares.

Thanks for the reply

 

[jrmwvu04]

Not sure if this may also impact @john9527 with his recent release too, he may want to check.

Yes, this is also present in 31E6.

tar -czf "$entPartition/jffs_scripts_backup_$(date +%F_%H-%M).tgz" /jffs/scripts/* >/dev/nul

 

[john9527]

Yes, this is also present in 31E6.

And has been that way since the entware-setup script was added in 2015 (V16 for my fork, I'd have to lookup the level for Merlin, but same time frame)

 

[jrmwvu04]

And has been that way since the entware-setup script was added in 2015 (V16 for my fork, I'd have to lookup the level for Merlin, but same time frame)

The script backup is made with no problem, which I suspect is why nobody noticed.

Well having looked up some info, it’s just cosmetic it seems. I do recall seeing the output about the scripts being backed up. That doesn’t seem like information that necessarily needs to be hidden to me. But,

 

[bluepoint]

I'm referring to the drivers build date of Feb/ 7.

ASUSWRT-Merlin RT-AC68U 384.4-beta3 Sat Mar 10 18:28:22 UTC 2018
xxxxxx@RT-AC68P-4738:/tmp/home/root# wl ver
6.37 RC14.126
wl0: Feb  7 2018 15:55:36 version 6.37.14.126 (r561982)

I'll double check when my son's iPhone comes, it's possible the phone is in "low power mode" state, hence, lower link rate would make sense.

Confirmed when iPhone is in "low power mode" link speed is lower, at full power, link speed is back to 866 Mbps.

 

[RMerlin]

Will the RT-AC66U have a 384.4 beta ? If not, will there be a release for this model when the beta cycle is over?

No. The RT-N66U and RT-AC66U are no longer actively supported, since Asus hasn't moved these models to the new 382/384 code.

@RMerlin - I think there is a very minor syntax error in the entware-setup.sh script.

Thanks, fixed.

Note that this didn't really have any impact, it just meant the output was sent to the wrong location rather than being dismissed. Backing up was still working properly.

PS: apparently the time is 1 hour off here as well

(however "data" via ssh does report 21:32, so I'm surprised to see 22:29 in the log)

Services don't all properly handle the daylight saving change automatically without a restart.

 

[Mark Taylor]

Hello,

I have been long time user, and lurker on these forums.
Have been running Asuswrt-Merlin for many years now. Current setup is RT-AC88U
Currently running 384.4 Beta 3 and My Wireless 2.4Ghz and 5Ghz both die once a day or twice. I have restart scheduled at 3am but that isn't enough as it seems it is happening more often.
After major update I always do factory reset and manually enter my config just to make sure things are clean.

Here are last few lines of logs before wireless decided to take a dump.

Hello PeterDNA

My guess is your router hardware is faulty. I have used this same router for years, RT-AC68U prior, and all the recent Merlin firmware and never had issues with wireless. I recall mention of some faulty units at one time so if still under warranty get a replacement. Might want to also make sure Airtime Fairness is disabled.

 

[PeterDNA]

Hello PeterDNA

My guess is your router hardware is faulty. I have used this same router for years, RT-AC68U prior, and all the recent Merlin firmware and never had issues with wireless. I recall mention of some faulty units at one time so if still under warranty get a replacement. Might want to also make sure Airtime Fairness is disabled.

Well this issue with wireless started happening with 384.4

-Peter

 

[Grisu]

Experienced that behaviour here in Utrecht as well
Solution is to set it to set summer time to start at the 4th sunday in March, like you did.
Summer time started yesterday in the USA, but not in Europe.

Look here, 5th sunday start and end will be only correct value for EU as it will be interpreted as last sunday: https://www.snbforums.com/threads/b...ta-is-now-available.44941/page-23#post-388651

Requested this correction years ago, but asus sleeping well and deaf on their ears.
5th sunday should be corrected to LAST sunday, this is how it works and seems to be programmed this way.

 

[zorax222]

When I moved to Beta 3 from a previous stable build, my VPN rules don’t seem to work correctly anymore.

I set up my entire internal network to default to the VPN in the VPN Client rules with all devices 192.168.1.0/24, dest 0.0.0.0 interface VPN. I then exclude 10 clients individually (name, ex: 192.168.1.10, dest 0.0.0.0, interface WAN) – TiVos and computers so as to not get blocked. My IP start pool is 192.168.1.2 and end is 196.168.1.254. Everything seems to be setup the same as before.

The problem I run into is that only 6 addresses are excluded from forced routing:

Mar 14 15:07:00 openvpn-updown: Forcing 192.168.1.0/24 to use DNS server 10.9.0.1

Mar 14 15:07:00 openvpn-updown: Excluding 192.168.1.120 from forced DNS routing (up to 6 addresses)

The first 6 addresses are excluded properly, but the next 4 clients (policy rule set to WAN) still go over the VPN.

Previously, I could exclude addresses from using the VPN without any issues. Is there something I could be missing?