[Release 384/NG] Asuswrt-Merlin 384.4 is now available

[marzell]

Flashed my AC87U with 384.4.
Firmware is stable now. Experienced one little issue with the wifi 5G connection.

Connected devices (for example: macbook and chromecast on 5ghz wifi) are not listed in 5ghz network map. When not listed in network map it is not default available in dropdown section with policy based routing rules (OpenVPN).

More users with this experience? Is it a little bug? (workaround is possible by self adding ip-address to policy based routing).

 

[RMerlin]

@RMerlin - If I upgrade from 384.3 to 384.4 right now, what are the odds my OpenDNS server is going to get dorked? My wife is on a trip and uses that connection daily. I'd prefer to have the latest security, but should I wait until she gets home at the end of the month? Thanks.

I assume you mean your DDNS? I doubt it will have any impact, I don't recall seeing any major changes from Asus around the DDNS code.

 

[JaimeZX]

DOH! Sorry, no I meant my OpenVPN server. Simply rebooting the router is one thing, but upgrading the firmware gives me pause. :facepalm:

 

[Sinner]

Does the crond notification logged after ntp sync also shows the same offset? I don't have any cron task set up at the time to check cron events, but crond does log that event with the correct time here:

Mar 31 00:14:58 dnsmasq[1193]: using local addresses only for domain lostrealm.lan
Mar 31 00:15:04 crond[369]: time disparity of 590654 minutes detected
Mar 31 00:15:06 rc_service: udhcpc 751:notify_rc start_dnsmasq

I don't know how Busybox's crond retrieves the timezone, I'd have to look at its code. What do you have in /etc/TZ?

Also, on which router? Could be a difference between 1.24 and 1.25's busybox applet.

@FreshJR noticed his cron off by 5hr on his 68u. I had no freshjr script restart on my 3100 the other night after the 2.062 sig update which made me dig a little deeper when I came home next day.

 

[scjr]

@RMerlin I noticed you have alpha_1 test builds of 384.5 on OneDrive. What GPL are they based on?

I’ll probably wait until it makes beta. Thanks for all your hard work. Much appreciated.

 

[Sanna1967]

What GPL are they based on?

384.5 (xx-xxx-2018)
- NEW: Merged withh GPL 384_20624 (with RT-AC68U binary blobs)
- NEW: Merged RT-AC86U binary blobs and SDK from 384_20467

 

[scjr]

384.5 (xx-xxx-2018)
- NEW: Merged withh GPL 384_20624 (with RT-AC68U binary blobs)
- NEW: Merged RT-AC86U binary blobs and SDK from 384_20467

Awesome. Thank you @Sanna1967!

 

[Morac]

Is 384.4_2 vulnerable to the CVE-2018-8826 remote code execution vulnerability that ASUS recently fixed in 20624?

 

[eastavin]

Not in the US Fcc changed the rules a few years ago. Now the lower 5ghz channels are aloud the same power as the higher channels.

Yes you are right. I should have said "originally" meant for indoor use.. https://apps.fcc.gov/edocs_public/attachmatch/DOC-326341A1.pdf The equipment in the field though did not get changed out overnight. Its only been 4 years since the announcement.

 

[Igor]

Yes or No? Clearing the browser cache is done. RT-AC68U.

 

[telUK]

Flashed my AC87U with 384.4.
Firmware is stable now. Experienced one little issue with the wifi 5G connection.

Connected devices (for example: macbook and chromecast on 5ghz wifi) are not listed in 5ghz network map. When not listed in network map it is not default available in dropdown section with policy based routing rules (OpenVPN).

More users with this experience? Is it a little bug? (workaround is possible by self adding ip-address to policy based routing).

Similar issue here with 5ghz connected devices, they disappear from the network map, they are still connected to the internet but come and go with the drop of a hat on the network map.

Might be a different issue to you, but something is up with the network map, its very unstable, was like this in the previous firmware as well.

 

[FreshJR]

Does the crond notification logged after ntp sync also shows the same offset? I don't have any cron task set up at the time to check cron events, but crond does log that event with the correct time here:

Mar 31 00:14:58 dnsmasq[1193]: using local addresses only for domain lostrealm.lan
Mar 31 00:15:04 crond[369]: time disparity of 590654 minutes detected
Mar 31 00:15:06 rc_service: udhcpc 751:notify_rc start_dnsmasq

I don't know how Busybox's crond retrieves the timezone, I'd have to look at its code. What do you have in /etc/TZ?

Also, on which router? Could be a difference between 1.24 and 1.25's busybox applet.

I am running an AC68U, the time zone issue was FIXED upon a router reboot but my all cron tasks were cleared. I was not aware that cron tasks did not exhibit persistence throughout a reboot. After the reboot it seems whatever timezone bug was occurring has corrected itself!

--CHECK CURRENT SETTINGS
admin@RT-AC68U-8838:/tmp/etc# cat TZ
UTC6DST,M3.2.0/2,M10.2.0/2                <---- CORRECT, this is my current central time zone
admin@RT-AC68U-8838:/tmp/etc# date
Sun Apr  1 04:48:20 DST 2018              <---- CORRECT this my my current time
----
CRON RESULTS
Apr  1 04:48:31 admin: test
Apr  1 09:49:00 crond[269]: USER admin pid 19623 cmd logger $(date)
Apr  1 09:49:00 admin: Sun Apr 1 09:49:00 GMT 2018        <---- results OFF by 5 hours
----
RESTART ROUTER
--> CRON JOBS DISAPPEARED, not sure cron jobs are supposed to be persistant ?!?!?
--> setup cron jobs again
----
CRON TEST 2
Apr  1 04:55:00 crond[298]: USER admin pid 10846 cmd logger $(date)
Apr  1 04:55:00 admin: Sun Apr 1 04:55:00 DST 2018
Apr  1 04:55:15 admin: test    <---- cron time is now correct

 

[Reef2009]

Hi I've issues with stability on my Ac68u.
Asus released a new official firmware update would it be advisable to flash this and than reflash Merlin firmware?
https://www.asus.com/us/Networking/RTAC68U/HelpDesk_BIOS/

 

[scjr]

Hi I've issues with stability on my Ac68u.
Asus released a new official firmware update would it be advisable to flash this and than reflash Merlin firmware?
https://www.asus.com/us/Networking/RTAC68U/HelpDesk_BIOS/

Either try one or the other.

Make sure you factory reset and enter all your settings manually,

 

[octopus]

I have tested the new software and have discovered a problem:
When you take out cable from a PC and reconnect you can't reach
router web interface again. You have to restart the router.
Has anybody discovered the same thing? RT-AC68U 384.4_2

 

[vibroverbus]

Just updated to _2 yesterday and have some weird cron behavior now?

Did a "cru l" and several jobs are not listed.
I load these jobs via services-start script at boot time.
Here's slightly disguised example.

# backup nvram settings
    if ! /usr/sbin/cru a SettingsBackup "xx xx * * * xxxxx/nvram-save.sh"; then
        echo "    Error creating nvram backup cron job"
    else
        echo "    Success creating nvram backup cron job"
    fi

There are 3 entries in a row in services-start like that, all identical formats.

They've always worked fine. Updated to _2 yesterday and according to my syslog those "cru a" tasks are succeeding fine, but after a reboot, the crontab only shows the last job of the 3.

If I copy paste run the "cru a" commands interactively, exactly as listed, they all complete fine and the jobs appear in "cru l" (or by manually checking the crontab file) as they should.

Oddly it kinda looks like at least one of the jobs that 'doesn't appear' ran anyway (the nvram-save.sh seems to have run at the correct time overnight, despite the fact that it does not appear after a reboot).

Could it be some kind of process-fork and locking/write thing, where those script commands fork and the /var/spool/cron/crontabs/someadminname only gets written by the last cru to complete?

 

[stambeccuccio]

Before there was the signature date, now no longer

 

[Wutikorn]

Before there was the signature date, now no longer

Was this from 384.4 or the new alpha version? I'm seeing the date in 384.4, although, not the correct date though, it hasn't been updated for a while now, same problem with stock firmware.

 

[RMerlin]

Is 384.4_2 vulnerable to the CVE-2018-8826 remote code execution vulnerability that ASUS recently fixed in 20624?

No idea, since the details of that CVE are not public.

 

[stambeccuccio]

Was this from 384.4 or the new alpha version? ...

From 384.4