What's new

Release [Fork] Asuswrt-Merlin 374 LTS release 46E9 (DNSpooq)

  • 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.

john9527

Part of the Furniture
LATEST RELEASE: Update-46E9
1-February-2021
Merlin fork 374.43_46E9j9527
============================

Update-46E9 Highlights

  • Update DNSMASQ to release 2.84 addressing DNSPOOQ vulnerabilities
  • Update NETTLE to release 3.7 for latest DNSMASQ cipher support
  • Allow custom nvram setting ‘ntp_force’ (starts ntp client without WAN connection) to work with all router configurations without the need for custom scripts
  • Fixed a problem showing the selected DoT servers in the gui
  • Fixed a problem when disabling the use of the VPN DNS servers in the OpenVPN client
  • Fixed a problem when displaying wireless status under Tools
  • Removed deprecated entware-setup.sh in favor of amtm
  • Additional buffer overflow protections in httpd
  • Updated default system time to 01 January 2020
  • Miscellaneous backports from Merlin 386 (see Changelog for details)
  • Note this release does NOT include support for the RT-AC68 V3. See the LTS Beta thread for this support.

Additional Notes on OpenVPN (Starting with release Update-46)

From the OpenVPN 2.5.0 release notes

CONNECTIVITY TO SOME VPN SERVICE PROVIDER MAY BREAK
  • Connecting with an OpenVPN 2.5 client to at least one commercial VPN service that implemented their own cipher negotiation method that always reports back that it is using BF-CBC to the client is broken in v2.5. This has always caused warning about mismatch ciphers. We have been in contact with some service providers and they are looking into it. This is not something the OpenVPN community can fix. If your commercial VPN does not work with a v2.5 client, complain to the VPN service provider.
As a result, the deprecated 'Cipher Negotiation Disable' (ncp-disable) option has NOT been removed from the gui. A syslog warning msg will be generated, but at present it still can be used to force a specific cipher with the Legacy/Fallback Cipher setting.

Some notes/info for users of OpenVPN service providers
  • Private Internet Access (PIA) has started pushing DNS servers with private addresses (10.0.0.241 - 10.0.0.244) when connecting to their next gen servers. In previous releases, these addresses would work fine when 'Redirect Internet traffic' is set to 'All'. However, when using 'Policy Rules' for policy based routing, these DNS servers would not be accessable. If 'Accept DNS Configuration' was then also set to 'Exclusive', all DNS lookups and therefore internet access will fail. Attempting to manually add a route through OpenVPN would also not be successful.

    This release will correctly process a route added in the 'Custom Configuration' section to allow access to these private DNS servers. You may check DNSMASQ or the OpenVPN PUSH_REPLY message to determine which server PIA is sending to the router. For example, adding

    route 10.0.0.243 255.255.255.255

    will allow access to the PIA DNS+Streaming private address DNS server which seems to be the default server.

    Further info on the PIA next gen DNS can be found at
  • Some providers have also started pushing IPv6 route information when connecting to their servers. The current router OpenVPN does not support IPv6 and if you are running dual stack you may experience problems. The following will now automatically be added to the configuration for the OpenVPN clients

    pull-filter ignore "ifconfig-ipv6"
    pull-filter ignore "route-ipv6"

Full ChangeLog: Changelog.txt in the download directory

Overview/Installation: LTS_OVERVIEW.pdf in the download directory

Previous release threads:
Update-46E8

Update-45EC

SHA256
(Default Build - All supported routers)
a05c160a82985ba87c13cf9802dbe7b9ccd46fd61b22fc77103e51f10f09ff11 RT-N16_374.43_46E9j9527.trx
33e01d91a4a60b86f09775d270900fa3afe92b488a4ca20e852d8b2f36586dc4 RT-AC66U_374.43_46E9j9527.trx
eb565b9b56f1fb0ab1acb7e149fed683fe677051016056643489ebd352df1840 RT-N66U_374.43_46E9j9527.trx
d0812f7f1a60b20be83b4008d5ba8f5a2efa020c8bf68b2f38234293a6279a10 RT-AC68U_374.43_46E9j9527.trx
29e0047a60223ec9f1dd56d81a1d6adbe00a1a8fb77b0e27d19c759945308f83 RT-AC56U_374.43_46E9j9527.trx
 
Updated to fork 374.43_46E9j9527 on my RT-N16. seems to be running stable. Love how quickly the DNSpooq security issue was addressed. Thanks for your continued work supporting this router, keeping it relevant. Would have moth-balled/doorstopped it years ago.
 
Last edited:
Just updated my AC66U (MIPS) from 46E8 to 46E9. As usual, no drama and all seems well. @john9527, thanks so much for getting this release out with the updated dnsmasq, and for all the work you put in to keep this valuable firmware build alive.
 
This release 46E9 is good (more better than last two realises was) on my RT-AC56U with good performance and stability. Thank you!
 
Thank you. I dirty flashed from E8 to E9 and about 4 minutes later the AC68U lost DNS resolution and still displayed E8. I thought it was a glitch and reflashed again and it worked.
 
I've been using this fork on an old AC68U at a vacation home with no issues except for a few dead zones in the outer reaches of the house. I brought up an old N66W for the bottom floor to help improve coverage and overall it's been good except I've noticed issues with "handoffs" of devices that are being used on one router and then go to another part of the house where the other router is stronger. Would this be improved by going to the stock firmware and using AiMesh or is this just a symptom of the multi-node network?
 
I've been using this fork on an old AC68U at a vacation home with no issues except for a few dead zones in the outer reaches of the house. I brought up an old N66W for the bottom floor to help improve coverage and overall it's been good except I've noticed issues with "handoffs" of devices that are being used on one router and then go to another part of the house where the other router is stronger. Would this be improved by going to the stock firmware and using AiMesh or is this just a symptom of the multi-node network?
I am not sure about your router, but on RT-N66U, I use this option and works well, if the signal is weak, it disconnect the device forcing it to connect to the better Access Point.
1613605515690.png
 
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