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.

RMerlin

Asuswrt-Merlin dev
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.
 
Just flashed over the Beta to 384.18 final. As always Thanks Merlin. :)
 
Dirty flash from beta to 384.13_10, all green. :)
 
Just flashed two RT-AC86u from 384.17 to 384.18. VPN Client working. NAS/SAMBA (Master Browser) working. DLNA working.
No addons.
 
Upgrade RT-AX88U & RT-AC3100 from V384.17 Final to V384.18 Final via dirty firmware upgrade. 30+ devices (includes gaming, streaming, downloads, etc.) and all appears to be working for main AX88U & backup AC3100 routers.
 
Is it 384.13_10, or _9 @RMerlin ? The beta thread referenced _9 in the title

EDIT: Looks like _10 in the code, no worries! (updating YazFi to accomdate the nvram changes for VPN routing)

For sub-revisions, I generally use odd numbers for beta and even for release.
 
All working well here.

Unrelated question, I use AiProtect, & haven’t seen any threats reported/blocked for 12+ months now.
Previously AiProtect was very ‘chatty’, hundreds of blocks per day.
Does it simply mean Skynet & Diversion are doing such a good job that there’s nothing for AiProtect to do?
 
Updated both units, so far everything is working great. Thanks RMerlin !
 
Dirty flash from 384.18_beta1-g4b93a11fd1 to 384.18. Router's humming along, happy as can be :)
 
All working well here.

Unrelated question, I use AiProtect, & haven’t seen any threats reported/blocked for 12+ months now.
Previously AiProtect was very ‘chatty’, hundreds of blocks per day.
Does it simply mean Skynet & Diversion are doing such a good job that there’s nothing for AiProtect to do?
I had the same experience, nothing reported in AiProtect for several months. Last week I installed Suricata and it already logged 5 malicious IP addresses. Since then I turned off all Trend Micro stuff and installed Cake and Suricata to replace QoS and AiProtect.[/QUOTE]
 
After dirty update to fw 384.18 my Diversion line of amtm shows some strange "-> v" as if there were an update available. If I manage to get rid of it the "->v" keeps coming back if I go to Diversion and come back to amtm. Anyone else?

Code:
 1  open     Diversion     v4.1.12       -> v
 
After dirty update to fw 384.18 my Diversion line of amtm shows some strange "-> v" as if there were an update available. If I manage to get rid of it the "->v" keeps coming back if I go to Diversion and come back to amtm. Anyone else?

Code:
 1  open     Diversion     v4.1.12       -> v
I'm not 100% sure, but could have to do with Diversions new WebUI option. There was an optional update recently that added this option under d - 10. Diversion WebUI options enabled
 
I'm not 100% sure, but could have to do with Diversions new WebUI option. There was an optional update recently that added this option under d - 10. Diversion WebUI options enabled
I enabled the WebUI (d - 10), went to LAN - Diversion and updated from there but the situation remains.
 
Smooth update on RT-AC87u :)

Really big Thanks RMerlin ;)
 
Okay so far on my AC88U after a dirty upgrade from 384.17 about 8 hours ago.
 
I seem to have a problem with my AC88U on a dirty flash from the last stable with this firmware (384.18), the syslog is flooded with these messages:

Jun 29 08:46:10 RT-AC88U-DDF0 kernel: rtl_error retVal(14) data(0)
Jun 29 08:46:13 RT-AC88U-DDF0 kernel: rtl8365mbrtl8365mb initialized(14)(retry:10) failed
Jun 29 08:46:14 RT-AC88U-DDF0 kernel: rtk port_phyEnableAll Failed!(14)
Jun 29 08:46:14 RT-AC88U-DDF0 kernel: rtk port_macForceLink_set ext_Port0 Failed!(14)
Jun 29 08:46:14 RT-AC88U-DDF0 kernel: rtk port_macForceLink_set ext_Port0 link up Failed!(14)
Jun 29 08:46:14 RT-AC88U-DDF0 kernel: txDelay_user: 1
Jun 29 08:46:14 RT-AC88U-DDF0 kernel: # txDelay - TX delay value, 1 for delay 2ns and 0 for no-delay
Jun 29 08:46:14 RT-AC88U-DDF0 kernel: EXT_PORT:16 new txDelay: 1, rxDelay: 1
Jun 29 08:46:14 RT-AC88U-DDF0 kernel: rtk_port_rgmiiDelayExt_set(EXT_PORT:16): return 14
Jun 29 08:46:14 RT-AC88U-DDF0 kernel: current EXT_PORT:16 txDelay: 14, rxDelay: -1726734512
Jun 29 08:46:14 RT-AC88U-DDF0 kernel: rxDelay_user: 4
Jun 29 08:46:14 RT-AC88U-DDF0 kernel: # rxDelay - RX delay value, 0~7 for delay setupEXT_PORT:16 new txDelay: 1, rxDelay: 4
Jun 29 08:46:14 RT-AC88U-DDF0 kernel: rtk_port_rgmiiDelayExt_set(EXT_PORT:16): return 14
Jun 29 08:46:14 RT-AC88U-DDF0 kernel: current EXT_PORT:16 txDelay: 14, rxDelay: -1726734512
Jun 29 08:46:17 RT-AC88U-DDF0 rtl_fail:
rtkswitch fail access, restart.


Additional info: Using a LTE USB Modem for cold standby WAN. Also there is an open nat menu without a icon now.


EDIT: A simple hard reboot fixed all problems :D
 
Last edited:
After 8+ days of uptime on beta1, I updated to 384.18. Been up 30 min so far, no issues. Thanks @RMerlin!!
 
Status
Not open for further replies.

Latest threads

Sign Up For SNBForums Daily Digest

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