[Beta] Asuswrt-Merlin 384.18 Beta / 384.13_9 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 beta 1 (and 384.13_9 for older models) is now available, except for the RT-AC88U (no up-to-date, compatible GPL release for that model).

The primary focus is on GPL updates, as well as a few component updates. Please refer to the Changelog for details.

Note that going back to a previous release after installing this new beta might require a factory default reset. I strongly recommend you do a backup of your settings before hand, so if you revert back to an older firmware version, you can just issue a factory default reset, and then reload your old settings.

Also, this will most likely be the final firmware release for the RT-AC87U and RT-AC3200 (unless something changes on Asus's end in terms of support for these models). I managed to update the wireless driver so this final release will contain Kr00k fixes.

Please stick posts in this thread to this specific beta release.
 

RMerlin

Asuswrt-Merlin dev
Reserved post.
 

QuikSilver

Very Senior Member

RMerlin

Asuswrt-Merlin dev
Is this a common occurrence for this model?
No. Usually the RT-AC88U and RT-AC3100 are totally in sync (as they are nearly identical), just that this time for some reason Asus didn't manage to update the GPL at the same time. I do have a GPL release from them that is newer than what's on their website, but it's not recent enough to be compatible with the rest of the GPL code used by all other models.

As I've mentioned in the past, users better get used to these types of occurrences to become more frequent as the number of supported models increases, and the amount of closed source code also increases. New releases will not always be available for every supported models.

@RMerlin Use sandard download link, or do you have separate repository for this release?
https://www.asuswrt-merlin.net/download is all you need to know for both release and beta downloads. Only alpha builds (which are not actual releases) are piled up in a separate Test Builds folder (also linked on that Download page).

I usually provide links in the initial post, but I didn't want to devote too much time crafting a complete release post like I used to do in the past. Just trying to reduce the amount of work I have to put into publishing releases, since most of this info is redundant anyway.
 

JohnD5000

Senior Member
Note that going back to a previous release after installing this new beta might require a factory default reset. I strongly recommend you do a backup of your settings before hand, so if you revert back to an older firmware version, you can just issue a factory default reset, and then reload your old settings.
What about the other way 384.17 to 384.18. Can we do a dirty update, or are there changes that a factory default reset install is recommended?
 

RMerlin

Asuswrt-Merlin dev
Is there any harm to keep saving direct to nvram with 0.0.0.0 with this change? https://github.com/RMerl/asuswrt-merlin.ng/commit/7a2857a293ea4c79203915da745046958e261527
YazFi manipulates the nvram variable directly for policy routing additions
No harm done, it will automatically be stripped away the next time the user saves his OpenVPN settings however. vpnrouting.sh still can understand both "" and 0.0.0.0.

What about the other way 384.17 to 384.18. Can we do a dirty update, or are there changes that a factory default reset install is recommended?
You can upgrade directly. The two important changes are:

- 384.18 now encrypts the user password for the RT-AC3100 and RT-AC5300, so downgrading to 384.17 = you won't be able to log back in.

- VPN policy rules now replace 0.0.0.0 with just an empty value to save nvram space - 384.17 will not be able to handle the empty value when creating the rules, so VPN clients may fail to properly configure their routes.

Rather than provide a bunch of "if/then" instructions in the changelog, I went with a blanket "don't downgrade without a factory default reset".
 

Jack Yaz

Part of the Furniture
No harm done, it will automatically be stripped away the next time the user saves his OpenVPN settings however. vpnrouting.sh still can understand both "" and 0.0.0.0.
Thanks!
 

RejZoR

Regular Contributor
@RMerlin
Will this release support the IPTV fixes ASUS put in the latest update for RT-AX58U ?

https://www.asus.com/us/Networking/RT-AX58U/HelpDesk_BIOS/

I'm kinda stuck in between official releases and your awesome firmware because of this bug fix which is a must, otherwise I can't even use the router at all. But I'd like to go to Merlin FW because of all the extra features and especially now that I mounted my router on the wall I need to turn off the LED's.
 

RMerlin

Asuswrt-Merlin dev
Will this release support the IPTV fixes ASUS put in the latest update for RT-AX58U ?
It will support whatever was in the GPL that was merged for that model - check the Changelog for the exact version.
 

yobocuruyo

Occasional Visitor
Hello @RMerlin Is it possible to configure the VPN for France country IP Range ? Right now I ended up putting 0.0.0.0 but I want to know if I can set a rule more specific to France country IP range.
 

RMerlin

Asuswrt-Merlin dev
Hello @RMerlin Is it possible to configure the VPN for France country IP Range ? Right now I ended up putting 0.0.0.0 but I want to know if I can set a rule more specific to France country IP range.
There are probably too many ASNs to cover a whole country.
 

RejZoR

Regular Contributor
It will support whatever was in the GPL that was merged for that model - check the Changelog for the exact version.
Took me a moment to figure out the numbers, but from the looks of it, not yet. 384.9354 is the official for AX58U. So, sometime in the future then I guess.
 

LimJK

Senior Member
Glad to report: Dirty Flashing 384.18_beta1 over 384.18_alpha1(June 13) on my AiMesh Router (RT-AX88U) + 2x AiMesh Nodes (RT-AC86U) with stock FW 3.0.0.4_384_81930, all seems good:
  • Very Stable Wifi with Fixed WiFi Control Channel & bandwidth (2.4GHz: Ch 11 20MHz, 5.0GHz: Ch 149 80MHz)
  • GUI Configuration: AiProtection, Asus DDNS (Let's Encrypt), OpenVPN Server (working with Tunnelblick (macOS Catalina) & OpenVPN Connect (iOS 13.5))
  • Scripts with Amtm 3.1.7FW: Diversion 4.1.12 uiDivStats 2.2.0 Skynet 7.1.8 connmon 2.6.0
Thank You!
 

ugandy

Senior Member
dirty flash over 384.17 ax88.
1 vpn server, 2 vpn client.
unbound, diversion, skynet, suricata, yazfi,ntpmerlin,...
no issues so far.
next: cake
 

bughit

Occasional Visitor
@RMerlin Please clarify some version details from the changelog.

Let's take RT-AC68U.

Given the following, from the changelog:
  • Merged GPL 384_81918 for mainline models.
  • Merged SDK + binary blobs 385_20490 for RT-AC68U (code is identical to 384_81846)
I have the following questions:
  • What is the SDK (soft dev kit) component? Is it distinct from GPL releases and binary blobs? Where does it come from?
  • RT-AC68U has GPL 384_81918 (which is from RT-AC86U)? Despite the lower version it's newer than 385_20433 from RT-AC68U?
  • What does "code is identical to 384_81846" mean? Which code (GPL, SDK, blobs)? And what is the significance/implication of this equivalence?
 
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