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

  • ATTENTION! As of November 1, 2020, you are not able to reply to threads 6 months after the thread is opened if there are more than 500 posts in the thread.
    Threads will not be locked, so posts may still be edited by their authors.
    Just start a new thread on the topic to post if you get an error message when trying to reply to a thread.
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.
 

det721

Part of the Furniture
Just flashed over the Beta to 384.18 final. As always Thanks Merlin. :)
 

Jack Yaz

Part of the Furniture
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)
 
M

motox22a

Guest
Just flashed two RT-AC86u from 384.17 to 384.18. VPN Client working. NAS/SAMBA (Master Browser) working. DLNA working.
No addons.
 

JohnSmith

Regular Contributor
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.
 

RMerlin

Asuswrt-Merlin dev
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.
 

Treadler

Very Senior Member
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?
 

Smokey613

Senior Member
Updated both units, so far everything is working great. Thanks RMerlin !
 

AntonK

Senior Member
Dirty flash from 384.18_beta1-g4b93a11fd1 to 384.18. Router's humming along, happy as can be :)
 

Mutzli

Very Senior Member
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]
 

Diamond67

Senior Member
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
 

Mutzli

Very Senior Member
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
 

Diamond67

Senior Member
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.
 

Zastoff

Very Senior Member
Smooth update on RT-AC87u :)

Really big Thanks RMerlin ;)
 

TheUntouchable

Regular Contributor
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:

MysticGold04

Regular Contributor
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.

Similar threads

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