[Release] Asuswrt-Merlin 384.15 (and 384.13_4) are now available

[heslo]

Successful flash from 384.15 beta 1 here on my AC88U. No issues so far!

 

[goRt]

The documentation for AMTM can be found here: https://github.com/RMerl/asuswrt-merlin/wiki/AMTM

The code behind the link is wrong

 

[AndreiV]

Easy enough to find the right URL :

https://github.com/RMerl/asuswrt-merlin/wiki/AMTM

 

[neil0311]

Did a dirty upgrade of my AX88U from the .15 beta to the release. Still seeing these errors that showed up with the .15 Alpha. Would a reset stop these? What exactly is causing this?

Feb 9 07:51:11 kernel: CFG80211-ERROR) wl_cfg80211_change_station : WLC_SCB_AUTHORIZE sta_flags_mask not set

 

[joe68000]

Dirty flash from .14_2 on my RT-AC5300. Everything looks good... thanks everyone involved!

 

[Sirko]

Hello! On latest firmware (384.13_4), Delug is installed with errors and does not work. Installed as described on the wiki.
The console displays:
------
Admin@AC87:/tmp/mnt/sda5/entware/etc/init.d# opkg install deluge
Installing deluge (2.0.3-1a) to root...
Downloading http://bin.entware.net/armv7sf-k2.6/deluge_2.0.3-1a_armv7-2.6.ipk
Configuring deluge.
Setting default deluge ui to console ...
Unable to initialize gettext/locale!
'ngettext'
Traceback (most recent call last):
File "/opt/lib/python3.8/site-packages/deluge/i18n/util.py", line 118, in setup_translation
builtins.__dict__['_n'] = builtins.__dict__['ngettext']
KeyError: 'ngettext'
-----
Admin@AC87:/tmp/home/root# deluge -v
Unable to initialize gettext/locale!
'ngettext'
Traceback (most recent call last):
File "/opt/lib/python3.8/site-packages/deluge/i18n/util.py", line 118, in setup_translation
builtins.__dict__['_n'] = builtins.__dict__['ngettext']
KeyError: 'ngettext'
deluge 2.0.3
libtorrent: 1.1.14.0
Python: 3.8.1
OS: Linux 2.6.36.4brcmarm

Help me please.

 

[bratik]

Dirty flash from .13_2 => .13.4 on my RT-AC3200, followed by an update to amtm, installing Diversion and uiDivStats.
Everything seems to be working as expected.
Thank you everyone!

 

[QuikSilver]

Dirty upgrade from beta....so far so good!

 

[Marin]

Why am I excited to get home and do this update!?

Since amtm is now part of the firmware, is there any recommendation on which to update first (amtm or the firmware) or should that not matter?

Thanks for all the hard work, as always.

The recommendation for you and anyone else who is getting ready to do this would be to “enjoy” the fact that now AMTM is part of firmware which means that if you ever reset your router in the future and log into it for the first time via SSH, by simply typing “amtm” brings up everything cool that you ever wanted to install without having to no longer copy and paste this:

curl -Os https://diversion.ch/amtm/amtm && sh amtm

Or even this:

/jffs/scripts/amtm


Isn’t that great?






Sent from my iPhone using Tapatalk

 

[Deleted member 62525]

I see we are in the same boat with the 86u. just like you my note 9 had issues with 384.14 builds but I also had streaming issues with google home. I did try 384.13 and 384.15 beta and the note 9 seems ok with fixed channels with mimo and beamforming off, but my google home was still telling me it lost wifi intermittently, so I had to go back to 384.12 for stability with my google home devices.
Maybe next round Asus push something better for the 86u for @RMerlin to work his magic on . What is strange though is that 384.12 and 384.13 seem to be on the same code base from Asus for the 86u

I have been running 384.15_beta1 and now 384.15 on RT86U for a week now without any drops or issues. OpenVPN client DoT, DNSSEC and even chromecast - all work fine.

 

[DarkKnight75]

I see we are in the same boat with the 86u. just like you my note 9 had issues with 384.14 builds but I also had streaming issues with google home. I did try 384.13 and 384.15 beta and the note 9 seems ok with fixed channels with mimo and beamforming off, but my google home was still telling me it lost wifi intermittently, so I had to go back to 384.12 for stability with my google home devices.
Maybe next round Asus push something better for the 86u for @RMerlin to work his magic on . What is strange though is that 384.12 and 384.13 seem to be on the same code base from Asus for the 86u

Yeah for some reason not as stable as 384.12and will hold for a better firmware

 

[maxbraketorque]

According to the change logs, the only difference between beta1 and the release is the following:

- CHANGED: Improved connection handling in httpd (themiron)

Is that correct?

 

[maxbraketorque]

Can someone with an ac86u report back findings on wifi stability and or drops on 5ghz as I experienced on 384.14..I'm back on 384.12 amd running smooth again

No issues.

 

[RejZoR]

Thanks for the hard work Merlin! My RT-AC87U will be pleased

 

[netware5]

Dirty flash 3 hours ago from 384.13 with USB drive disconnected. No issues so far. The only minor issue observed is this syslog entry at the end of boot process:

kernel: bcm_i2c: bus 0: Failed to detect SFP: 100 retries exhausted

which I don't understand.

Thank you @RMerlin!

 

[XIII]

Upgraded from 384.15 Beta to 384.15 Final.

Only the usual (reboot) issue: catch-22 between ntp and NextDNS.

 

[jerry6]

384.15 running well on my AC5300 smooth upgrade nothing out of the ordinary showing on logs , still getting great transfer speeds and signal .
Thanks

 

[Jugnu]

Updated RT-AX88U from 384.15 Beta 1 to 384.15_0 release 'dirty'.

• Downloaded the correct file for my router.
• Verified the extracted RT-AX88U_384.15_0_cferom_ubi.w matched the sha256sum.sha256 hash file.
• In PuTTY, I updated all scripts to their latest versions (with the @Jack Yaz scripts, be sure to use 'u' and then 'uf' on each).
• In the GUI, I 'Safely removed' all USB drives from the router (Free RAM before, 35MB, Free RAM after, 465MB).
• Flashed the 384.15 final.
• After reboot, allowed the router to 'settle' for 15 to 20 minutes. But I did use my network as I normally would.
• After that short period of time, I rebooted the router once again.
• I will also reboot once more after an hour or more of using the network normally.
  • This being the final 'test' that the firmware upgrade 'took' properly.

No issues to report. WiFi as fast as ever. LAN as well. The network is as responsive as it has ever been thanks to the polished firmware, the current reboot(s) (@RMerlin! ) and undoubtedly helped with Unbound running as the DNS server.

And all scripts working too!
amtm, Diversion + Entware + pixelserv-tls, Skynet, YazFi, scribe, connmon, ntpMerlin, scMerlin, uiDivStats, uiScribe, Unbound, and disk checker, on Ext4 w/journaling and a 2GB swap file on a Patriot 256GB Elite USB drive in the USB 3.0 port in USB 3.0 mode.

Okay, great! Now, what are we supposed to do with the rest of the weekend!

My highest respect and appreciation for all the great talent, contributions, sweat and swearing this firmware is based on, from so many people, brought together by RMerlin and this milestone release. Simply too many to name without fear of forgetting someone!

Hi L&LD,

I had a question regarding the scripts update. You mentioned that you updated all the scripts using @Jack_Yaz scripts. Doesn't all the scripts suppose to gets update when flashing the latest 384.15 version? Do i really need to update all these scripts in my router? How do i update all these scripts if i need to as i can't find the instructions?

Thanks

 

[krgck]

A day later AC88U has nothing to report, smooth sailing.

 

[gattaca]

Upgraded from 384.14_2 to 384.15 Final on: AC86U, AC88U, AC1900P/68U.

1. I followed your advice and upgraded ALL AMTM scripts first. For Jack's stuff, someone posted to perform a U, then an UF forced update on the "j" items to be sure they were all current - so that's what I did for each one.
2. Backed up router configs and JFFS via GUI to my local system
3. (Note: NextDNS is OFF, returned to QUAD9 for DNS) for this upgrade.
4. Rebooted router, let stabilize (~7-10 mins)
5. Flashed the FW Note: I did not disconnect the USB SATA SSD from the router.
6. Waited about 5-7 mins after it said please reboot, then rebooted the router
7. Waited 7-10 mins, then logged into GUI and SSH
8. GUI is fine, things look normal, CPU very low
9. Hit issue with AMTM alias --> typed "unalias amtm" to remove that link, all is good now.
10. typed amtm
11. Checked for more updates. --> None.
12. Now watching...
13. Note above: I set router up to use Quad9 b/c of few reported issues with NextDNS being enabled. I just din't want to chance it. Will switch to NextDNS once things settle on this version.

Thanks so much! This is AWESOME!