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

[RMerlin]

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.

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.

 

[Hawk]

Eric, can we consider this release as a present for Canada day for our routers

Anyway thank you Eric, though Canada day is bit far but have a safe one.

 

[Deleted member 22229]

Just flashed over the Beta to 384.18 final. As always Thanks Merlin.

 

[Jack Yaz]

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)

 

[MDM]

Dirty flash from beta to 384.13_10, all green.

 

[motox22a]

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

 

[JohnSmith]

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]

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]

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]

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

 

[AntonK]

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

 

[Billy Chaney]

Flashed and all is well.

 

[Mutzli]

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]

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?

 1  open     Diversion     v4.1.12       -> v

 

[Mutzli]

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?

 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]

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]

Smooth update on RT-AC87u

Really big Thanks RMerlin

 

[Morac]

Okay so far on my AC88U after a dirty upgrade from 384.17 about 8 hours ago.

 

[TheUntouchable]

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

 

[MysticGold04]

After 8+ days of uptime on beta1, I updated to 384.18. Been up 30 min so far, no issues. Thanks @RMerlin!!