What's new

[Release] Asuswrt-Merlin 384.18 and 384.13_10 is now available

  • SNBForums Code of Conduct

    SNBForums is a community for everyone, no matter what their level of experience.

    Please be tolerant and patient of others, especially newcomers. We are all here to share and learn!

    The rules are simple: Be patient, be nice, be helpful or be gone!

Status
Not open for further replies.
this might be a dumb question but in regards to "UPDATED: Merged GPL 384_8563 for AX models.". Does this mean that the AX88U firmware on ASUS's website is still newer since it is "Version 3.0.0.4.384.9107". Or those numbers don't correlate?
Not a dumb question at all. In times like this Merlin can only merge what he has. I would venture to guess that Asus updated the official firmware after giving Merlin the GPLs he need to update the AX model. Short story version....yes, official is technically newer.
 
Not a dumb question at all. In times like this Merlin can only merge what he has. I would venture to guess that Asus updated the official firmware after giving Merlin the GPLs he need to update the AX model. Short story version....yes, official is technically newer.
but after 384.18, 384.19 comes :)
 
On the AIMesh Router admin-Firmware upgrade page, the AIMesh Nodes are also listed with Upload link. This takes you to the node login page & you can upload off line as before. Take care to get the correct firmware for each.

Does this depend on using a wired backhaul though, as I'm using wireless? If it needs wired, I can always bring the node downstairs and connect it to the router via a short Ethernet cable, then I guess I connect to the router via Ethernet like I normally do for updates and the node update process will be managed over the temporary wired backhaul?
 
Asuswrt-Merlin 384.18 (current models) and 384.13_10 (RT-AC87U and RT-AC3200) is now available. The focus of this release was the merge of new GPL releases from Asus.

384.13_10 will probably be the final release for the RT-AC87U and RT-AC3200, due to the GPL code of these two models being currently completely out of sync with the code used by the other models.

Code:
384.18 (28-June-2020)
  - NOTE: A number of changes for some models are not backward
          compatible with previous versions.  Downgrading to
          a previous release will require a factory default reset
          afterward in many cases.
  - UPDATED: Merged GPL 384_8563 for AX models.
  - UPDATED: Merged GPL 384_81918 for mainline models.
  - UPDATED: Merged SDK + binary blobs 384_81918 for RT-AC86U.
  - UPDATED: Merged SDK + binary blobs 384_81902 for RT-AC5300.
  - UPDATED: Merged SDK + binary blobs 385_20490 for RT-AC68U.
  - UPDATED: Merged binary blobs 385_20490 for RT-AC3100.
  - UPDATED: Merged binary blobs 384_81918 for RT-AC88U.
  - UPDATED: Merged SDK + binary blobs 384_8563 for RT-AX58U.
  - UPDATED: amtm to 3.1.7.
  - UPDATED: Root certificate bundle to June 3rd 2020.
  - UPDATED: OUI database used by the webui.
  - UPDATED: Dropbear 2020.80 (themiron)
  - UPDATED: nano to 4.9.3.
  - CHANGED: Optimized OpenVPN routing policy storage (this change
             is NOT backward compatible with previous firmwares)
  - FIXED: ssh/scp client would fail to connect while negotiating
           a chacha20 connection (themiron)



384.13_10 (28-June-2020)
  This release will most likely be the last release for the
  RT-AC87U and RT-AC3200, due to limited upstream support.

  - UPDATED: amtm to 3.1.7.
  - UPDATED: Root certificate bundle to June 3rd 2020.
  - UPDATED: OUI database used by the webui.
  - UPDATED: Dropbear 2020.80 (themiron)
  - UPDATED: Wireless driver from 382_52230 for RT-AC87U and
             RT-AC3200 (should in theory address Kr00k)
  - FIXED: ssh/scp client would fail to connect while negotiating
           a chacha20 connection (themiron)

Downloads are here.
Changelog is here.
Updated rt ac 88 u smooth as silk and running beautifully thanks again Eric next stop PayPal for some beer money for your hard work
 
Yeah: Had it daily for over last week. To resolve had to use "UU" on amtm..."U" didn't resolve. Almost reported it a few times...then sidetracked. Now knowing someone else has this, will report on the AMTM forum.
Logged into amtm again and a tiny update was available. Updated, and rebooted my router. Now everything seems to be fine, so far.
 
Logged into amtm again and a tiny update was available. Updated, and rebooted my router. Now everything seems to be fine, so far.
I logged an error report on amtm forum. Minor update for me again today "-> V". I will perform a "U" on amtm 2-3x times a day...minor updates on at least one of those daily checks. The "U" update always fails, need to perform a "UU". Started in the time period of 384.18 alpha/beta.
 
@RMerlin does this means that 384.18 for RT-AC68U includes these ASUS fixes?
Code:
ASUS RT-AC68U Firmware version 3.0.0.4.385.20490
- Improved connection stability.
- Optimized CPU utilization.
- Fixed some UI bugs.
- Fixed login bugs.

It should, assuming these bugs ever existed in the first place in my firmware. I have no idea what they are referring to specifically.

1 A Chinese language menu/button item has appeared just under Adaptive QoS, which shows on hover "UUAccelerator.asp", only on ac-86u. It has the same icon as Adaptive QoS. My ac86u is likely Chinese sourced, but I always operate it in English.

It means you have a router from China, in which case the router will enable support for this Chinese-only service. The code to enable/disable that feature in the webui is closed source, and outside of my control.

@RMerlin What is "Remapping interrupts" appeared on every boot after updating 384.17-> 384.18?

I don't know. You'd have to ask a Linux kernel engineer. In short: it's normal.

Q: when check for new firmware (Check Update) why is firewall restarted?

I don't know. I assume it's because the check also handles TrendMicro signature updates.

this might be a dumb question but in regards to "UPDATED: Merged GPL 384_8563 for AX models.". Does this mean that the AX88U firmware on ASUS's website is still newer since it is "Version 3.0.0.4.384.9107".

Yes.
 
I have no idea what they are referring to specifically.
Same here, that is why i am asking :)
I was mostly intrigued by "Optimized CPU utilization" statement, wondering could it help my AC68 to run 200/200 speedtest from SpeedtestMerlin properly.
Plus, on 19th they released
Code:
ASUS RT-AC68U Firmware version 3.0.0.4.385.20585
- Fixed Let's encrypt certification renew bugs.
- Improved web history page loading speed.
- Fixed OpenVPN related bugs
Again - go figure what "related bugs" and "renew bugs" they are talking about exactly. Is it really too hard for them to be a bit more descriptive?
Or they are going full PlayStore path here where almost for every app new version has "bug fixes and performance enhancements".
"Improved web history page loading speed" likely only refers to this specific case.
 
Again - go figure what "related bugs" and "renew bugs" they are talking about exactly. Is it really too hard for them to be a bit more descriptive?

Asus's changelogs are still among the most detailed ones available. Check out Netgear, where they won't even acknowledge specific CVEs when reporting a bland "fixed various bugs" in their changelogs.
 
AX88U from Beta1 to 384.18. when I enable VPNC1 it kills my internet connection. if I enable VPNC2 it is fine. Not sure why that is.
 
I doubt where or what i'm got lost ..."RT-AX58U_384.18_0" dirty firmware upgrade, over beta.

E8wg.png
 
Eject USB (do not have to remove it physically), then try again...

Thanks, it worked.

RT-AX58U AIMESH (Lyra), QoS Tradicional ,NAS/SAMBA , DLNA , ENTWARE, SWAP, TRASMISSION, ADGUARHOME, FTP, WAKE ON LAN/WAN, Everything seems perfect.
 
Might sound dumb asking, but since I don't really quite understand the versions of GPL and stuff I'm gonna ask if 384.13_10 includes fixes for RT-AX58U that were introduced with firmware 3.0.0.4.384.9354 ?

Merlin's changelog says "UPDATED: Merged GPL 384_8563 for AX models." and official release states it's version 3.0.0.4.384.9354".

So, if I'm understanding the versions right, Merlin's release doesn't include fixes included in official release. Because I can't use Merlin until it gets the IPTV fixes that I explicitly need and I need to know when Merlin's version will include it so I can migrate to Merlin's firmware...
 
Might sound dumb asking, but since I don't really quite understand the versions of GPL and stuff I'm gonna ask if 384.13_10 includes fixes for RT-AX58U that were introduced with firmware 3.0.0.4.384.9354 ?

Merlin's changelog says "UPDATED: Merged GPL 384_8563 for AX models." and official release states it's version 3.0.0.4.384.9354".

So, if I'm understanding the versions right, Merlin's release doesn't include fixes included in official release. Because I can't use Merlin until it gets the IPTV fixes that I explicitly need and I need to know when Merlin's version will include it so I can migrate to Merlin's firmware...
possibly 384.19
 
- UPDATED: Merged binary blobs 385_20490 for RT-AC3100.
- UPDATED: Merged binary blobs 384_81918 for RT-AC88U.

@RMerlin Is the listed GPL version for the AC88U correct?

I ask because the AC3100 and AC88U are virtually identical and ASUS switched to the 385.20xxx versioning for their firmware for the AC88U.

Also if the AC88U didn’t include the changes from 385_20490, then I wouldn’t expect to see the option to export the router certificate in 384.18, since it was added in 385.20490, but it’s there.

Basically what changes are actually in the 384_81918 GPL for the AC88U? Is it equivalent to 385_20490?
 
I understand not everyone is interested in participating in the alpha and beta threads prior to a release, but many of these questions were answered during the past month or so about the GPL/SDK/binary blob versions and the challenges Merlin faces getting multiple models in sync with the ASUS public releases, when ASUS does not release GPLs on a predictable schedule.

Believe what the man wrote in his change logs. He means what he says. ;)
 
Don't know for sure if it's new behavior, but on my 68U with DHCP-WAN: Traffic Monitor on Network Map and Traffic Analyzer count LAN-Traffic as WAN-Traffic. I'm transferring something to my NAS using WiFi at the moment and upload on Traffic Monitor page shows data written to hardwired NAS as "Up" category, on Traffic Analyzer wireless and wired are displayed correctly, but wired is mirrored to internet (WAN).

Tried a download from NAS now, same mirrored effect on WAN. Like the internet (WAN) gets its data from the wired ports of the switch instead of only ETH0.
 
Last edited:
Status
Not open for further replies.

Sign Up For SNBForums Daily Digest

Get an update of what's new every day delivered to your mailbox. Sign up here!
Top