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

[RMerlin]

March 24th: Version 384.4_2 has been released, containing security fixes.

Asuswrt-Merlin 384.4 is now available for all supported models. The focus of this release was porting the last remaining models to the 384/NG code branch, and updating to the latest GPL available, bringing us back in sync with Asus's latest release.

The highlights of this release:

• Merged with GPL 384_20379 (with some binary components from 382_50010 and 384_20308 depending on models)
• Added support for the RT-AC5300 and RT-AC87U, completing the task of migrating models to the new 384/NG code branch. As a reminder, the RT-N66U and the original RT-AC66U will NOT be migrated to the 384 code base, and support for these two is going to be dropped.
• Added IPSEC server support to the RT-AC86U.
• Moved Entware to the new 3x-NG merged repository, and added 64bit Entware support to the RT-AC86U (user-configurable when running entware-setup)
• Changed Samba protocol support, now defaults to SMBv1 + SMBv2 support. This means SMB sharing will be a bit slower than with SMBv1, but more secure. The protocol settings now allow you to chose between SMBv1 (faster but not secure), SMBv2 (secure but not compatible with everything) and SMBv1 + SMBv2 (the new default, matches the behaviour of the old SMBv2 setting in previous releases). I personally recommend switching to SMBv2, unless you have embedded devices which do not support SMBv2 yet.
• The telnet server support has been removed, for security purposes. Please use SSH instead.
• Merlin NAT loopback was removed, as it was becoming increasingly problematic with the constant low-level changes to the firewall
• A few other fixes, please read the changelog for details

As a reminder, if you are migrating to a 384 firmware for the first time:

• Clear your browser cache or do a forced reload the first time you access the router under 384 (to refresh your cached CSS files)
• If coming from 380.xx, it's strongly recommended to do a factory default after flashing 384, and manually reconfiguring. Things might work correctly if you don't, but you might have to double check some of your previous settings, for instance OpenVPN's.

Also note that AiMesh is NOT supported, and there are currently no new information as to whether it will eventually be supported or not.

The focus will now be on issuing one final 380.70 release to bring closure to the 380 branch. This release should be fairly minor, bringing mostly a few bug fixes.

Please keep discussions in this thread to this specific release.


Downloads are here.
Changelog is here.

 

[scjr]

Smooth upgrade over beta 3. Thanks again Eric!

 

[Keenan]

Installed and working fine so far, thanks!

 

[skeal]

Upgraded both routers. AC3100 and AC68U all is good!!

 

[agilani]

I didn't check where the beta 4 left off. Is the repeater mode working on this version yet? A few of us were having wireless dropouts in repeater mode. Funny thing is, its only a hub issue. I left the spoke repeaters on 384.3 code base and they are operating normally still.

 

[unsynaps]

Still issues restoring a backup of the JFFS partition even after a fresh flash then Restore/Initialize.

Even making a backup them immediately trying to reupload spits the following error.

Setting File uploaded fail. It may result from incorrect Setting File or error transmission. Please check the validation of Setting File and try again.

Nothing in the syslog when the upload button is hit.

EDIT: Giving up on this issue for now and just spending forever to reconfigure by hand... HTTPD crashed. Twice.

Mar 16 21:27:54 kernel: httpd[795]: unhandled level 3 translation fault (11) at 0x0014e05c, esr 0x92000007
Mar 16 21:27:54 kernel: pgd = ffffffc0152e2000
Mar 16 21:27:54 kernel: [0014e05c] *pgd=000000001535d003, *pud=000000001535d003, *pmd=0000000015326003, *pte=0000000000000000
Mar 16 21:27:54 kernel: CPU: 0 PID: 795 Comm: httpd Tainted: P           O    4.1.27 #2
Mar 16 21:27:54 kernel: Hardware name: Broadcom-v8A (DT)
Mar 16 21:27:54 kernel: task: ffffffc0193a0140 ti: ffffffc015360000 task.ti: ffffffc015360000
Mar 16 21:27:54 kernel: PC is at 0xf7090aa0
Mar 16 21:27:54 kernel: LR is at 0x263b0
Mar 16 21:27:54 kernel: pc : [<00000000f7090aa0>] lr : [<00000000000263b0>] pstate: 20000010
Mar 16 21:27:54 kernel: sp : 00000000ffe3cc98
Mar 16 21:27:54 kernel: x12: 00000000000866dc
Mar 16 21:27:54 kernel: x11: 0000000000073a96 x10: 0000000000000001
Mar 16 21:27:54 kernel: x9 : 000000000014b770 x8 : 0000000000000000
Mar 16 21:27:54 kernel: x7 : 000000000014ded8 x6 : 0000000000136af0
Mar 16 21:27:54 kernel: x5 : 000000000014e050 x4 : 000000000014e050
Mar 16 21:27:54 kernel: x3 : 00000000ffffffff x2 : 00000000f6f3c7a8
Mar 16 21:27:54 kernel: x1 : 0000000000000000 x0 : 000000000014e050
Mar 16 21:27:54 kernel: br0: topology change detected, propagating
Mar 16 21:27:54 kernel: br0: port 5(eth5) entered forwarding state
Mar 16 21:27:54 kernel: br0: topology change detected, propagating
Mar 16 21:27:54 kernel: br0: port 6(eth6) entered forwarding state
Mar 17 01:28:20 watchdog: restart httpd
Mar 17 01:28:20 rc_service: watchdog 803:notify_rc stop_httpd
Mar 17 01:28:20 rc_service: watchdog 803:notify_rc start_httpd
Mar 16 21:28:20 RT-AC86U: start httpd:80
Mar 16 21:29:01 kernel: httpd[2038]: unhandled level 3 translation fault (11) at 0x00607084, esr 0x92000007
Mar 16 21:29:01 kernel: pgd = ffffffc014135000
Mar 16 21:29:01 kernel: [00607084] *pgd=0000000014002003, *pud=0000000014002003, *pmd=0000000013941003, *pte=0000000000000000
Mar 16 21:29:01 kernel: CPU: 0 PID: 2038 Comm: httpd Tainted: P           O    4.1.27 #2
Mar 16 21:29:01 kernel: Hardware name: Broadcom-v8A (DT)
Mar 16 21:29:01 kernel: task: ffffffc0191f40c0 ti: ffffffc0143c0000 task.ti: ffffffc0143c0000
Mar 16 21:29:01 kernel: PC is at 0xf7014aa0
Mar 16 21:29:01 kernel: LR is at 0x263b0
Mar 16 21:29:01 kernel: pc : [<00000000f7014aa0>] lr : [<00000000000263b0>] pstate: 20000010
Mar 16 21:29:01 kernel: sp : 00000000ff94a7c8
Mar 16 21:29:01 kernel: x12: 00000000000866dc
Mar 16 21:29:01 kernel: x11: 0000000000073a96 x10: 0000000000000001
Mar 16 21:29:01 kernel: x9 : 00000000005f2700 x8 : 0000000000000000
Mar 16 21:29:01 kernel: x7 : 0000000000606f00 x6 : 00000000005f94e8
Mar 16 21:29:01 kernel: x5 : 0000000000607078 x4 : 0000000000607078
Mar 16 21:29:01 kernel: x3 : 00000000ffffffff x2 : 00000000f6ec07a8
Mar 16 21:29:01 kernel: x1 : 0000000000000000 x0 : 0000000000607078
Mar 17 01:29:20 watchdog: restart httpd
Mar 17 01:29:20 rc_service: watchdog 803:notify_rc stop_httpd
Mar 17 01:29:20 rc_service: watchdog 803:notify_rc start_httpd
Mar 16 21:29:20 RT-AC86U: start httpd:80

 

[Pit_g]

Upgrade firmware to 384.4 RT-AC68U Hw V E1

Restored to factory

And when upgrade qos signature:

Mar 17 02:42:09 kernel: nvram: consolidating space!

Mar 17 02:42:46 rc_service: httpd 288:notify_rc start_sig_check

Mar 17 02:43:12 kernel: ERR[parse_qos_conf:932] Can't set new QoS conf while QoS is started!

Mar 17 02:43:12 kernel: ERR[ioctl_iqos_op_config:3592] parse qos_conf error!!

Mar 17 02:43:12 kernel: ioctl_iqos_op_config() fail!

Mar 17 02:43:12 kernel: ERR[qos_start:3344] QoS is already started!

Mar 17 02:43:12 kernel: ioctl_iqos_op_switch(1) fail!

 

[jerry6]

loaded ten minutes after you uploaded 384 , so far looking good , nothing strange turning up in logs , all working well .

 

[richardeid]

I'm coming from 382.1_2. I have a 4TB drive connected to the USB3 port. I've noticed something through a couple of boots on 384.4 now. In all past versions I've seen that 4TB drive be available as soon as the web UI was available. But now what I'm noticing is that the web UI will be accessible and that drive shows as unmounted but after a minute or so I see it as being available. And of course this all shows in that order in the system log.

Anyway, if that's a new change on the 384 branch that's pretty cool, because I guess that means I'm getting a UI more quickly available to me after a boot. If not, just wondering what's different on my end because I didn't do a factory reset, I just updated in-place. So nothing as far as my settings or anything has changed.

 

[Blacklistedcard]

Load 384.4 on both AC86U and 87U, both are running great.....

 

[Morac]

Loaded 384.4 on top of 384.3 on my 88u, so far so good.

One odd thing I noticed during the update was that the lights never went completely out. Usually the lights would all turn on and then go out and then slowly come back on one at a time. This time the lights didn’t all come on and go off, instead the leftmost light never went off. I thought maybe something had gone wrong, but it flashed to 384.4.

 

[mafiaboy01]

AC3100, AC87 and AC56 all working great!

 

[RMerlin]

And when upgrade qos signature:

This is normal.

 

[penguin22]

All looking good coming from beta 3 on AC86U.

 

[natzakaria]

AC5300 - working great

 

[Striker317]

Upgraded both routers. AC3100 and AC68U all is good!!

Sorry for this targeted message to you.

Can you humour me and see if your USB ports work?

On my hw rev A6 ac3100 and my hw rev A1 ac68 they don’t seem to be ever since the 384 branch was started both Merlin and stock firmware. Tried both a sandisk 2gig USB key and a wd mybook 4 tb drive.

Just trying to see if others see this before I report more fully. You happen to have the same hardware (though perhaps different hw rev) as me.

 

[Pit_g]

This is normal.

Ok

Thanks Merlin.......great work

 

[Netbug]

installed 7 hours ago on rt-ac86u and all seems good, nothing abnormal looking in logs. Thanks RMerlin.

 

[pattiri]

my router is up for more than 7 hours and this was the only update that went everything went smooth since the beginning of the 382 releases. Every time I had small problems which solved with a reboot but this time everything is perfect

 

[Thorton]

Upgraded AC87U from 380.69 in several minutes after you uploaded new firmware, works well so far.