Release [Fork] Asuswrt-Merlin 374 LTS release 46E8 (Superseded)

[john9527]

LATEST RELEASE: Update-46E8
24-December-2020
Merlin fork 374.43_46E8j9527
============================

Update-46E8 Highlights

• Update OpenVPN to release 2.5 (see additional notes)
• Fix OpenVPN configurations for some service providers (see additional notes)
• Update OpenSSL to 1.1.1i
• Update libmnl and lz4
• Add new OpenVPN options stub/stubv2 and tls-crypt-v2
• OpenVPN try to negotiate CHACHA20-POLY1305 cipher if supported by the remote end
  The CHACHA20-POLY1305 cipher will be added to the default cipher negotiation following a factory default reset. You may also manually add it to the cipher negotiation list.
• Update IPSET userspace to release 7.6
• Update CA bundle to 2020 December 9th version
• New nvram option to attempt ntp sync without internet access
• Move WSDD start to eliminate startup errors

Additional Notes on OpenVPN

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
  

  Using PIA DNS in Custom Configurations - Knowledgebase / Technical / Application Settings and Features / DNS - PIA Support Portal

  www.privateinternetaccess.com
• 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"

Downloads
Latest public release: https://1drv.ms/f/s!Ainhp1nBLzMJgXEJCQVqKPjosiia

Full ChangeLog: Changelog.txt in the download directory

Overview/Installation: LTS_OVERVIEW.pdf in the download directory

Previous release thread:

Release - [Fork] Asuswrt-Merlin 374 LTS release 45EC

The next release 46E8 is now available https://www.snbforums.com/threads/fork-asuswrt-merlin-374-lts-release-46e8.68757/ LATEST RELEASE: Update-45EC 19-November-2020 Merlin fork 374.43_45ECj9527 ============================ Picks up a few fixes for problems reported since the last release...

www.snbforums.com

SHA256
(Default Build - All supported routers)
2ded0f20023cf36f3ddfa90dd2be9a29f53805bb2f73ed8ab43126cd7f837f8b RT-N16_374.43_46E8j9527.trx
b3850ce7e0a8e4ec0566da29027ce8c2e16a1155640f636817fe0605624c8734 RT-AC66U_374.43_46E8j9527.trx
4de9128ac1fd3b27abf57c159effe42ac71aae4c2390a10c5f6458cead6c5a7a RT-N66U_374.43_46E8j9527.trx
011e7e29560f120613a4eb33038d72441495a9fa4306d56e47c94d057d397a49 RT-AC68U_374.43_46E8j9527.trx
f5e63d7a6f2d1f0d5a8c49620f2c43379a306df4b813e2ab4ad306503932cba8 RT-AC56U_374.43_46E8j9527.trx

 

[john9527]

Reserved

 

[MysticGold04]

@john9527
Hi John, Thanks for this build of firmware. I did not see any other feedback threads, so I wanted to post here to say thanks.

I did notice after configuring the local web interface for https that the cert it created expired 12/31/2020. Is that by design or will it update the cert once connected to my ISP. (I'm configuring in offiline mode)

 

[dave14305]

@john9527
Hi John, Thanks for this build of firmware. I did not see any other feedback threads, so I wanted to post here to say thanks.

I did notice after configuring the local web interface for https that the cert it created expired 12/31/2020. Is that by design or will it update the cert once connected to my ISP. (I'm configuring in offiline mode)

I think it was just dumb luck that the default router time is Jan 1 2011 (adjusted to your time zone) and if NTP isn’t synced, the router will generate a cert with 10 year expiration (Jan 1 2021).

EDIT: But maybe it’s time to advance the default RC_BUILDTIME by a decade.

 

[john9527]

EDIT: But maybe it’s time to advance the default RC_BUILDTIME by a decade.

Hmm....guess the fork has been around a while Updated the default to 01-01-2020 for the next release.

As an FYI.....expire date for the SSL certs will be 10 years if the clock is not set.....13 months if the clock has been set, to meet an Apple initiative for expiring certs.

 

[L&LD]

@john9527, simply curious why not 01-01-2021?

 

[john9527]

@john9527, simply curious why not 01-01-2021?

I just like even numbers And it's exactly 50 years from the start of epoch time.

 

[atkinsom]

Just upgraded and works like a charm. No hiccups and the VPN server still works like a charm. Thanks John

 

[atirage21]

On AC56U with last two master release is slower VPN in compare to 44EAj9527. Only on 44EAj9527 is not problem with playing more video on same time. Videos are teared on newer realises if are played in same time. Also checking of connection speed have less results about 10 - 20 %. (from from 50 mb/s is only 40 or 45 mb/s through my VPN Surfshark with last two releases of firmware).

 

[bjs]

I have an RT-AC66U and I tried upgrading from 45EC to 46E8.

The router is connected to a NBN HFC cable internet box to access the internet.

After upgrade, clients could connect to the router, and the router showed Internet Status on, and that it had automatically obtained IP address/DNS. Also the ISP provider website showed that the status as "Connected".

But, the clients, both wifi and wired, could not access the internet. I forgot to try any pings/traces from the router admin console

I rechecked the sha256 was OK and tried reflashing the router with 46E8 again and rebooting it and HFC box multiple times, but still no internet access for clients.

I've downgraded to 45EC and clients can access the internet again.

Any ideas?

 

[djrem3000]

Hi @john9527,
I would like to pay your atention to some old major issue present in RT-N66U RT-AC66U (in most firmwares, including your fork). I had a conversation with Asus support, they have confirmed the issue, but unfortunately stated, that the official support for RT-N66U is over therefore they are not going to solve it.

Here is the issue description:
There are plenty of complaints on the web stating that some Android phones are causing RT-N66U and RT-AC66U routers to crash and reboot while the phone is trying to connect via WIFI (not everytime, but quite often). I'm experiencing this issue either, and it is a nightmare (i have two Oneplus6 phones in my family, they are constantly crashing the router).
In my case the phone is Oneplus 6 (latest updates), but there were other Android phones present which cases specified Asus routers to reboot (e.g. HTC U12, Oneplus 7T and etc)

Here are some examples of such issues on the web:

https://www.reddit.com/r/OnePlus6/comments/8suqm8

https://www.snbforums.com/threads/a...hen-android-phone-connects-to-its-wifi.48421/

There are no logs in syslog on the router regarding this issue, guys from SMB forum have connected a serial TTL cable inside a router and have seen, that it is causing the Linux kernel crash (see the link above).
I have registered issue to Asus support, and after long investigations they have concluded:
"Most likely the issue is in the incompatibility of the operating mode of the problem phone and the driver of the wireless module of the router. Unfortunately, RT-N66U / RT-AC66U models are EOL, support is discontinued, firmware updates are not planned except for those previously planned. "

Please note, that the issue is present in Asus official firmware (latest), Asus Merlin version (deprecated), your fork and etc.

Is there anything you can do in this case?

 

[ColinTaylor]

Please note, that the issue is present in Asus official firmware (latest), Asus Merlin version (deprecated), your fork and etc.

This was discussed at great length in the previous thread, e.g. http://www.snbforums.com/threads/fork-asuswrt-merlin-374-43-lts-releases-archive.18914/post-619134

 

[djrem3000]

This was discussed at great length in the previous thread, e.g. http://www.snbforums.com/threads/fork-asuswrt-merlin-374-43-lts-releases-archive.18914/post-619134

Yes, it was discussed multiple times already, i know about it, but as far as i'm concerned no permanent solution was found Only the temporal "Disable NAT acceleration" option. This solution works, but it is drastically decreases router's performance
Please note, that very first complaints were dated on 2018, still no solution found

 

[fatspirit]

Yes, it was discussed multiple times already, i know about it, but as far as i'm concerned no permanent solution was found

Therefore the only permanent solution is a new router.

 

[djrem3000]

Therefore the only permanent solution is a new router.

As far as i understand, we are not 100% aware of the real reason for these crashes. The permanent solution could be the new updated Linux kernel as an e.g. or modified wifi driver, no deep investigation was made. Yep, the simplest solution would ALWAYS be to change the router, no doubts Anyways, i have asked the question @john9527 if he has some thoughts about it. If he confirms there are no other ways, then we can consider it.

 

[Andi P]

Hi John,

I hope you are doing well.

I just came across an article in a German computer science newspaper about dnsmasq and newly discovered vulnerabilities.
Some reference is here: https://kb.cert.org/vuls/id/434904

It is stated, dnsmasq 2.83 is the fixed version. A quick check on my AC68U showed, the dnsmasq version of the latest firmware is 2.82.

So finally the questions: Do you have plans to update dnsmasq to 2.83 in the next releases?

Many thanks
Andi

 

[ColinTaylor]

So finally the questions: Do you have plans to update dnsmasq to 2.83 in the next releases?

I think that goes without saying as that is the primary purpose of this fork:

https://github.com/john9527/asuswrt-merlin

The fork does include

• Maintenance for documented security issues
• Maintenance for supporting open source components (such as dnsmasq, miniupnpd, etc)

And from the change log:

* CHANGED: dnsmasq: update to 2.82
* CHANGED: dnsmasq: update to 2.81 final
* CHANGED: dnsmasq: update to 2.81rc4-g3f60ecd
* CHANGED: dnsmasq: ASUS/Merlin custom modifications 2.81
* CHANGED: dnsmasq: rebase to 2.81rc3-g1627d57
- CHANGED: dnsmasq: update to 2.80-g456a319
* CHANGED: dnsmasq: update to 2.80-122392e snapshot
* CHANGED: dnsmasq: update to 2.80 final including custom mods
* CHANGED: dnsmasq: update to 2.80test7
* CHANGED: dnsmasq: update to 2.80test6
* CHANGED: dnsmasq: update to 2.80-51e4eee snapshot
* CHANGED: dnsmasq: update to 2.78 final (with CVE fixes)
* CHANGED: Revert "dnsmasq: update to 2.77rc3"
* CHANGED: dnsmasq: mark as 2.76 forked version
* CHANGED: dnsmasq: update to 2.77rc3
- CHANGED: dnsmasq: update to 2.76final
- CHANGED: Update dnsmasq to 2.75 final
- CHANGED: Updated dnsmasq to 2.73rc9
- CHANGED: dnsmasq update to version 2.73rc1.patch
- CHANGED: Updated dnsmasq to 2.72 (ASUS master 376.44) - fixes DHCP leases display
- CHANGED: Updated dnsmasq to 2.71

 

[john9527]

So finally the questions: Do you have plans to update dnsmasq to 2.83 in the next releases?

I've been working with the 2.83 release this morning. It's posting some unexpected errors in the syslog that I need to spend more time looking at (it didn't just 'drop in' like previous releases).

 

[dave14305]

I've been working with the 2.83 release this morning. It's posting some unexpected errors in the syslog that I need to spend more time looking at (it didn't just 'drop in' like previous releases).

There's a lot of log noise being reported at OpenWRT also.

Security Advisory 2021-01-19-1 - dnsmasq multiple vulnerabilities

Multiple flaws (7 CVEs) has been found in the dnsmasq package. Dnsmasq has two sets of vulnerabilities, one set of memory corruption issues handling DNSSEC and a second set of issues validating DNS responses. These vulnerabilities could allow an attacker to corrupt memory which can lead to...

forum.openwrt.org

 

[john9527]

There's a lot of log noise being reported at OpenWRT also.

Security Advisory 2021-01-19-1 - dnsmasq multiple vulnerabilities

Multiple flaws (7 CVEs) has been found in the dnsmasq package. Dnsmasq has two sets of vulnerabilities, one set of memory corruption issues handling DNSSEC and a second set of issues validating DNS responses. These vulnerabilities could allow an attacker to corrupt memory which can lead to...

forum.openwrt.org

Thanks for the pointer....exactly what I am seeing as well....
May be time to wait for the first point release.

Jan 20 13:46:18 dnsmasq[16246]: failed to send packet: Network is unreachable
Jan 20 13:46:18 dnsmasq[16246]: failed to send packet: Address family not supported by protocol

DNSSEC seems to be having problems as well...Using Quad9 servers...

Jan 20 14:03:37 dnsmasq[20916]: Insecure DS replies received, do upstream DNS servers support DNSSEC?
Jan 20 14:03:41 dnsmasq[22358]: Insecure DS replies received, do upstream DNS servers support DNSSEC?
Jan 20 14:03:41 dnsmasq[20916]: Insecure DS replies received, do upstream DNS servers support DNSSEC?
Jan 20 14:03:42 dnsmasq[22358]: Insecure DS replies received, do upstream DNS servers support DNSSEC?
Jan 20 14:03:43 dnsmasq[22358]: Insecure DS replies received, do upstream DNS servers support DNSSEC?
Jan 20 14:03:44 dnsmasq[22358]: Insecure DS replies received, do upstream DNS servers support DNSSEC?
Jan 20 14:03:45 dnsmasq[22401]: Insecure DS replies received, do upstream DNS servers support DNSSEC?
Jan 20 14:03:45 dnsmasq[20916]: Insecure DS replies received, do upstream DNS servers support DNSSEC?
Jan 20 14:03:46 dnsmasq[22401]: Insecure DS replies received, do upstream DNS servers support DNSSEC?