What's new

Asuswrt-Merlin 380.57 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!

RMerlin

Asuswrt-Merlin dev
I'm unable to put much time on this project these days due to personal reasons, but I figured it was past time that I at least wrap up the current development code and issue an official release. Asuswrt-Merlin 380.57 is now available for all supported models. This release adds support for the RT-AC88U, RT-AC3100 and RT-AC5300.

A factory default reset is required specifically for the RT-AC68U, due to the switch to a new SDK + wireless driver. Some people reported having issues with the 2.4 GHz band with this new SDK - if that's your case, the only solution at this time is to revert back to 378.56_2.

Changes:
Code:
380.57 (24-Dec-2015)
    - NEW: Merged with 380_1031 GPL
    - NEW: Added RT-AC3100 and RT-AC5300 support
    - NEW: Added RT-AC68U HW Revision C1 support
    - NEW: Backup/Restore of the content of the JFFS
           partition (under Administration Restore/Save Settings)
    - NEW: Added DNSSEC support.  Can be enabled under LAN -> DHCP.
    - NEW: Added custom/postconf support for igmpproxy.conf.
    - CHANGED: Increased user account limit from 16 to 32 on
               the VPN server pages.
    - CHANGED: Updated e2fsprogs to 1.42.13
    - CHANGED: Increased maximum entries in Parental Control
               (time scheduler) to 32.
    - CHANGED: Updated miniupnpd to 1.9.20151119.
    - CHANGED: Updated Openssl to 1.0.2e.
    - CHANGED: Downgraded Dropbear to 2014.66, too many issues in
               the newer releases.
    - CHANGED: Improvements to VPN Status page
    - FIXED: CTF not automatically disabled when enabling IPTraffic.
    - FIXED: Openvpn clients 3 through 5 were all run on the first
             CPU core.  They are now properly alternated like the
             first two (odd on CPU1, even on CPU0)
    - FIXED: smb.log generated by networkmap could fill up RAM
    - FIXED: upnpc_xml.log generated by miniupnpc could fill up RAM
    - FIXED: Inconsistant names used on IPTraffic and Sysinfo page.
             Now, we give priority to any description manually entered
             on the networkmap, followed by static hostname, then any
             current (lease) hostname.
   - FIXED: MAC queries sent to the OUI database were broken due to
            changes on the IEEE website
   - FIXED: Applying changes to OpenVPN client page would start the
            client even if it was disabled/stopped.

Please keep discussions in this thread specifically to this release and its changes.


Downloads are here.
Changelog is here.
 
Last edited:
Thank you very much, and Merry Christmas :)
 
I do hope the personal reasons weighing heavily on you resolve in the best possible way, and I'm certain all other contributors to the forum would agree. Best wishes for 2016, and thanks not only for the work you've put into the firmware but also for your answers to so many of the topics posted.

EDIT: sorry, just seen "Please keep discussions in this thread specifically to this release and its changes.". Anyway, the sentiments remain despite my faux pas.
 
Hi Merlin, I have a RT-AC68U: could I proceed with a reset to factory default and a restore of the settings via NVRAM utility or shall I re-enter them manually?
 
I hope if (may god forbid) you are going through any bad personal issues it would hopefully pass fast and safely...

merry Christmas and happy new year in advance :)


I'm unable to put much time on this project these days due to personal reasons, but I figured it was past time that I at least wrap up the current development code and issue an official release. Asuswrt-Merlin 380.57 is now available for all supported models. This release adds support for the RT-AC88U, RT-AC3100 and RT-AC5300.

A factory default reset is required specifically for the RT-AC68U, due to the switch to a new SDK + wireless driver. Some people reported having issues with the 2.4 GHz band with this new SDK - if that's your case, the only solution at this time is to revert back to 378.56_2.

Changes:
Code:
380.57 (24-Dec-2015)
    - NEW: Merged with 380_1031 GPL
    - NEW: Added RT-AC3100 and RT-AC5300 support
    - NEW: Added RT-AC68U HW Revision C1 support
    - NEW: Backup/Restore of the content of the JFFS
           partition (under Administration Restore/Save Settings)
    - NEW: Added DNSSEC support.  Can be enabled under LAN -> DHCP.
    - NEW: Added custom/postconf support for igmpproxy.conf.
    - CHANGED: Increased user account limit from 16 to 32 on
               the VPN server pages.
    - CHANGED: Updated e2fsprogs to 1.42.13
    - CHANGED: Increased maximum entries in Parental Control
               (time scheduler) to 32.
    - CHANGED: Updated miniupnpd to 1.9.20151119.
    - CHANGED: Updated Openssl to 1.0.2e.
    - CHANGED: Downgraded Dropbear to 2014.66, too many issues in
               the newer releases.
    - CHANGED: Improvements to VPN Status page
    - FIXED: CTF not automatically disabled when enabling IPTraffic.
    - FIXED: Openvpn clients 3 through 5 were all run on the first
             CPU core.  They are now properly alternated like the
             first two (odd on CPU1, even on CPU0)
    - FIXED: smb.log generated by networkmap could fill up RAM
    - FIXED: upnpc_xml.log generated by miniupnpc could fill up RAM
    - FIXED: Inconsistant names used on IPTraffic and Sysinfo page.
             Now, we give priority to any description manually entered
             on the networkmap, followed by static hostname, then any
             current (lease) hostname.
   - FIXED: MAC queries sent to the OUI database were broken due to
            changes on the IEEE website
   - FIXED: Applying changes to OpenVPN client page would start the
            client even if it was disabled/stopped.

Please keep discussions in this thread specifically to this release and its changes.


Downloads are here.
Changelog is here.
 
Merlin, best to you and thank you for your hard work on this.

On Mediafire in the RT-AC88U folder, I see one file labeled "RC-AC88U_380.57_0.zip" and another labeled "RT-AC88U_380.57_0(2).zip" with a timestamp about 6 minutes later. Is this intentional or is one of them the right one to use?

Thanks!

Chris
 
Merlin, best to you and thank you for your hard work on this.

On Mediafire in the RT-AC88U folder, I see one file labeled "RC-AC88U_380.57_0.zip" and another labeled "RT-AC88U_380.57_0(2).zip" with a timestamp about 6 minutes later. Is this intentional or is one of them the right one to use?

Thanks!

Chris

Mediafire's web interface for file management is horrible. Sometimes files take minutes to appear, so in this case I probably reuploaded it before their servers finally registered the first upload.

First file should be fine, I'll delete the duplicate.
 
Mediafire's web interface for file management is horrible. Sometimes files take minutes to appear, so in this case I probably reuploaded it before their servers finally registered the first upload.

First file should be fine, I'll delete the duplicate.


It's already fixed! Thanks!
 
Hope that everything is going well for you now...and have a great holiday season!

My question is whether this is still true:

Reverted the memory buffering optimization for ARM devices, as people keep panicking over the lower amount of free RAM. You can manually re-enable the optimization by setting "drop_caches=0" in nvram.

I suspect so, but thought that I'd ask.

Thanks for the Christmas present!
 
Just flashed the 57 final all working good on the AC3100. Thanks Eric and have a great holiday. :)
 
Thanks merry christmas.
 
My question is whether this is still true:

Reverted the memory buffering optimization for ARM devices, as people keep panicking over the lower amount of free RAM. You can manually re-enable the optimization by setting "drop_caches=0" in nvram.

I suspect so, but thought that I'd ask.

Yes.
 
Should RT-AC68P be factory reseted after upgrading?

Thank you,

Yep read the first post. ( A factory default reset is required specifically for the RT-AC68U, due to the switch to a new SDK + wireless driver. ) Although it says 68U i can assume it's the same for all AC68 versions.
 
@Merlin.. I will be adding a name and icon for all my connected devices after i do this should the router be rebooted or not necessary ? I only ask because it seems a lot of people have issues with the network map after they start making custom changes.
 
Last edited by a moderator:
If I update to 380, can I go back later, and still flash John's or HGG's fork?
I thought I read a post a while back that once you go to 380 something gets locked, maybe I was dreaming. Anybody know?
 

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