[Fork] Asuswrt-Merlin 374.43 LTS releases (Archive)

[john9527]

Hello all....

My Christmas/New Year has got off to a rocky start with a family health emergency, hence my absence over the last couple of weeks. Unfortunately, it's going to keep my busy for the foreseeable future, so fork updates are going to be a bit slower going forward. (It's going to be a good therapy for me though to keep it going )

Right now, I've moved the 37E9/37L9 release I was preparing before Christmas to the public download. Please check the Changelog for the details (I'll try and catch up with a summary when I can).

I've also updated the stubby-resolvers.csv (use update-stubby-resolvers.sh at the command line) to include the new AdGuard DoT support. It's untested right now, so possibly someone could try them out and report back. ( @chief_os thanks for the pointer)

Thanks everyone.

 

[john9527]

Would you consider adding an option to the LAN DHCP page to advertise the router IP as the NTP server under option 42 if the SNTP server is enabled?

This is a good idea....I'll add it to the work queue.

 

[chief_os]

use update-stubby-resolvers.sh at the command line

maybe, command should looks like
stubby-update-resolvers.sh

 

[dave14305]

My Christmas/New Year has got off to a rocky start with a family health emergency, hence my absence over the last couple of weeks. Unfortunately, it's going to keep my busy for the foreseeable future, so fork updates are going to be a bit slower going forward.

Sending positive thoughts your way for 2019!

 

[atkinsom]

Hello all....

My Christmas/New Year has got off to a rocky start with a family health emergency, hence my absence over the last couple of weeks. Unfortunately, it's going to keep my busy for the foreseeable future, so fork updates are going to be a bit slower going forward. (It's going to be a good therapy for me though to keep it going )

Wishing you and the family the best. Hopefully all will work out well for your family. Take care.

 

[MysticGold04]

Hello all....

My Christmas/New Year has got off to a rocky start with a family health emergency, hence my absence over the last couple of weeks. Unfortunately, it's going to keep my busy for the foreseeable future, so fork updates are going to be a bit slower going forward. (It's going to be a good therapy for me though to keep it going )

Right now, I've moved the 37E9/37L9 release I was preparing before Christmas to the public download. Please check the Changelog for the details (I'll try and catch up with a summary when I can).

I've also updated the stubby-resolvers.csv (use update-stubby-resolvers.sh at the command line) to include the new AdGuard DoT support. It's untested right now, so possibly someone could try them out and report back. ( @chief_os thanks for the pointer)

Thanks everyone.

Many thanks, John for the time you are able to spend on this project. it is awesome stuff. I hope and pray all works out well with your family.

 

[john9527]

Here's the release summary for 37E9/37L9

LATEST RELEASE: Update-37E9/37L9
15-December-2018
Merlin fork 374.43_37E9j9527
Download http://bit.ly/1YdgUcP
============================

Key Changes:

• Fix CVE-2018-17022 buffer overflow exposure
  This is the only recent CVE applicable to this fork
• Update miniupnpd to 20181205
• Update miniupnpc to 20180507
• Add TEE iptables module for ARM routers (load via modprobe)
• Ensure umount usb is captured by stopping the logger after umount
• Push LAN and Search domains for OpenVPN server (Merlin backport)
• Improve local name resolution startup for IPv6 addresses
• Avoid unneccessary dnsmasq/stubby restart when rebooting
• Upstream fix for getdns/stubby getentropy failure
  Note that this fork did not encounter this problem since it includes haveged in the base firmware

SHA256

(Default Build - All supported routers)
ae55ecb416cf384d6baf3c562ccc07e004e7455f7c3843ebcdaa7c0b689444e2  RT-N16_374.43_37E9j9527.trx
fb4461466190f5d7741ad23b6d625d7e80b6eee31bdbe4bd9d48b0bba6196761  RT-AC66U_374.43_37E9j9527.trx
d83aadbdcc6287ad22712c66ceba608722d679b1b792bb670d75044262fc8ab1  RT-N66U_374.43_37E9j9527.trx
e2d72d84c11e9955b43d6470d7ea791bc930a93c8bb3105232bf234a0e723765  RT-AC68U_374.43_37E9j9527.trx
09577bb1350e4dce8e670552befdbaff60f9eb22127e130b36d6b4f963fa5cdc  RT-AC56U_374.43_37E9j9527.trx

(Legacy Only Builds)
8dd549143e765dc927f8ca280cf3987e69878c38d788f838cd45dbd14ebb90a9  RT-AC68U_3.0.0.4_374.43_2-37L9j9527.trx
17aea999eb0818131800c55a6d1fa6a3a1605b77690749520260a974f0c2dc30  RT-AC56U_3.0.0.4_374.43_2-37L9j9527.trx
66163bd8a52c27bf8ddfb4049e2730cb19e6eb1a339ae18bdfede28ab6297ea3  RT-N16_3.0.0.4_374.43_2-37L9j9527.trx
600813d916a1eaaf9b815197d5f3074bc8e7f56556332be052f43890762aa933  RT-AC66U_3.0.0.4_374.43_2-37L9j9527.trx
72e9986b9431e5755ed3e7daedebe7222dbdcae7d148461151e54947011ff3e8  RT-N66U_3.0.0.4_374.43_2-37L9j9527.trx

 

[Odkrys]

Upstream fix for getdns/stubby getentropy failure
Note that this fork did not encounter this problem since it includes haveged in the base firmware

As far as I know, this getdns getentropy problem caused by glibc.
getrandom and getentropy merged in glibc 2.25.
Entware aarch64 is using glibc 2.27 while armv7 is using glibc 2.23.
So compiler thought that system has getentropy but actually our linux didn't have it.

configure:15605: checking for getentropy
configure:15605: aarch64-openwrt-linux-gnu-gcc -o conftest -O2 -pipe -mcpu=cortex-a53+crypto -fno-caller-saves -fno-plt -fhonour-copts -Wno-error=unused-but-set-variable -Wno-error=unused-result   -Wall -Wextra -D_BSD_SOURCE -D_DEFAULT_SOURCE -I/krys/Entware/staging_dir/target-aarch64_cortex-a53_glibc-2.27/opt/include -I/krys/Entware/staging_dir/toolchain-aarch64_cortex-a53_gcc-7.3.0_glibc-2.27/include  -I/krys/Entware/staging_dir/target-aarch64_cortex-a53_glibc-2.27/opt/include -L/krys/Entware/staging_dir/target-aarch64_cortex-a53_glibc-2.27/opt/lib -Wl,-rpath,/opt/lib -Wl,-rpath-link=/krys/Entware/staging_dir/target-aarch64_cortex-a53_glibc-2.27/opt/lib -Wl,--dynamic-linker=/opt/lib/ld-linux-aarch64.so.1 -L/krys/Entware/staging_dir/toolchain-aarch64_cortex-a53_gcc-7.3.0_glibc-2.27/lib  -L/krys/Entware/staging_dir/target-aarch64_cortex-a53_glibc-2.27/opt/lib conftest.c -lssl -lcrypto -lpthread  >&5
configure:15605: $? = 0
configure:15605: result: yes

As a result getdns compiled without src/compat/getentropy_linux.c (This has various fallback i.e. getentropy, getrandom, urandom).
This is the reason why the problem only happened on HND routers.

 

[john9527]

As a result getdns compiled without src/compat/getentropy_linux.c (This has various fallback i.e. getentropy, getrandom, urandom).
This is the reason why the problem only happened on HND routers.

Thanks for setting me straight!

 

[bbunge]

John, How can I disable haveged? Will disable this break stubby/getdns?

 

[john9527]

John, How can I disable haveged? Will disable this break stubby/getdns?

Why? Right now it's started automatically as part of the router boot sequence. There's no easy way to stop it.

It originally went in for dnscrypt support. dnscrypt would fail to start if a certain entropy floor value was not available, and the router base firmwarehad a low entropy at boot. I had assumed something was similar for stubby. My guess now is it wouldn't break without it, but security may be not as good.

 

[john9527]

Would you consider adding an option to the LAN DHCP page to advertise the router IP as the NTP server under option 42 if the SNTP server is enabled?

Anybody see a reason to not automatically enable this option if you turn on the NTP server? (Instead of a separate option)

 

[Gravityz]

@john,

i noticed that the mac adresses of the wifi(wireless-WDS page) correspond with the one the router and the box.
i also see a mac address on the WAN-special requirement from ISP and that one is totally different(looks like a fake one to please the isp modem)
is this correct?

also some time ago i replaced my faulty RT-AC66U(Rev B0) with a new RT-AC66U(Rev A1)
at that time i did not know better so i installed new firmware and restored a cfg made from the old one)
now i read that is not the smartest thing to do so i want to correct this.
it is running fine but i want to make sure nothing HW related from the old router was copied onto the new router

is this the correct procedure to fix this

nvram-save to save config
factory reset router
run #a script to get max power again
flash latest firmware(currently at E4, going to E9)
factory reset again with new firmware
nvram-restore


thanks

 

[john9527]

i noticed that the mac adresses of the wifi(wireless-WDS page) correspond with the one the router and the box.

This is normal, LAN(router) and 2.4GHz share the same MAC, 5GHz is that MAC+4

i also see a mac address on the WAN-special requirement from ISP and that one is totally different(looks like a fake one to please the isp modem)
is this correct?

Depends on your ISP....it really is a special ISP requirement.

also some time ago i replaced my faulty RT-AC66U(Rev B0) with a new RT-AC66U(Rev A1)
at that time i did not know better so i installed new firmware and restored a cfg made from the old one)
now i read that is not the smartest thing to do so i want to correct this.

Would be a good idea....at least the 5GHz wireless is different between the two revs.

it is running fine but i want to make sure nothing HW related from the old router was copied onto the new router

is this the correct procedure to fix this

nvram-save to save config
factory reset router
run #a script to get max power again
flash latest firmware(currently at E4, going to E9)
factory reset again with new firmware
nvram-restore

Should work with the following caveats
Really don't need the first factory reset.
- I never really liked the #a mod since it does violate regs (both FCC/EU and EU). Are you really sure you are seeing a real benefit from it? In any event,, if you decide to still use it, it should probably be the last thing you do.
- I haven't been keeping up the nvram tool even with respect to this fork. There will likely be a few settings that are defaulted after the restore if you changed them.

 

[Gravityz]

Thanks John,

will try it out first thing in the morning(when everybody is gone)
also will test if i really need the #a.
a couple of years agon it made a lot of difference but maybe the difference is slim now.

This is normal, LAN(router) and 2.4GHz share the same MAC, 5GHz is that MAC+4

Depends on your ISP....it really is a special ISP requirement.

Would be a good idea....at least the 5GHz wireless is different between the two revs.

Should work with the following caveats
Really don't need the first factory reset.
- I never really liked the #a mod since it does violate regs (both FCC/EU and EU). Are you really sure you are seeing a real benefit from it? In any event,, if you decide to still use it, it should probably be the last thing you do.
- I haven't been keeping up the nvram tool even with respect to this fork. There will likely be a few settings that are defaulted after the restore if you changed them.

 

[Michael Wells]

I currently use Tomato, and was thinking of going with this build, on my rt-N66U router, but wanted to know if it incorporates
website monitoring, like tomato has ??

 

[john9527]

I currently use Tomato, and was thinking of going with this build, on my rt-N66U router, but wanted to know if it incorporates
website monitoring, like tomato has ??

If you mean maintaining a list of visited web addresses, sorry but no.....

 

[john9527]

Sorry everyone, but I've just had to push an update to 37EA/37LA.

While working with Merlin on a problem in another thread, I discovered that an architecture change in the latest ASUS code affected a backport I did from his builds. Net result was that the VPN DNS servers were now not being used in the VPN client (Accept DNS Configuration settings).

In addition to the above, it also contains a change to advertise the router IP as the NTP server under DHCP option 42 if the SNTP server is enabled (@dave14305 )

LATEST RELEASE: Update-37EA/37LA
9-January-2019
Merlin fork 374.43_37EAj9527
Download http://bit.ly/1YdgUcP
============================

Key Changes:

• Fix a regression in 37E9 that prevented pushed VPN DNS servers from being used in the client
• Advertise the router IP as the NTP server under DHCP option 42 if the SNTP server is enabled

SHA256

(Default Build - All supported routers)
3100ccc623883a3847bb8fe2199b85da1642c837a4408dee17fd10eee04b4498  RT-AC56U_374.43_37EAj9527.trx
692d026824f53da1baaf5650d597a3b311c6441cb69b81d642819ae7e9ca8651  RT-AC66U_374.43_37EAj9527.trx
71832d71513a77e5fb770c239b63c690eeb9dc9bc61b397d7b787e4a68ccf82b  RT-AC68U_374.43_37EAj9527.trx
42afac22c739d95bfce6e81829f64004277fa63df5b802db05b5870d2a9f9f5d  RT-N16_374.43_37EAj9527.trx
b4362dd7586aeee23857fbec79a7b2a053aa8aefa618adc95f0ba293b6f5dcd8  RT-N66U_374.43_37EAj9527.trx

(Legacy Only Builds)
4f7e6f7da32dda771f5da3a13d2b83dae779a57b387ebddf421f8476c0211297  RT-AC68U_3.0.0.4_374.43_2-37LAj9527.trx
9a788110538a5c297b7fe2b9906df8d2f62c1ebca1b8b8ad6b6724f593158949  RT-AC56U_3.0.0.4_374.43_2-37LAj9527.trx
21e6699f3e81281e182f2b2f078b0ad8938552c3d136db9dd93c2796537158d4  RT-N16_3.0.0.4_374.43_2-37LAj9527.trx
1b6ffd3b3dd82058e24304e8fa573ce718040264c097926d87a4050a0c473076  RT-AC66U_3.0.0.4_374.43_2-37LAj9527.trx
9e0f13fa7c0919951c7ace011d0bb66ffef9378d940626a8ea0de1835730227c  RT-N66U_3.0.0.4_374.43_2-37LAj9527.trx

 

[dave14305]

Advertise the router IP as the NTP server under DHCP option 42 if the SNTP server is enabled

Installed easily enough. Enabled SNTP on the Admin page. Checked dnsmasq.conf and didn't see the option added. Manually restarted dnsmasq in ssh and it showed up. Still looking for a client that actually respects that option.

 

[ColinTaylor]

Still looking for a client that actually respects that option.

Yes, that's what I was wondering. (Not that I'm objecting to having the option 42 anyway)