Release [Fork] Asuswrt-Merlin 374 LTS release 48E7

[ualdrivr]

There have been numerous changes. Look in the changelog: https://github.com/john9527/asuswrt-merlin/blob/374.43_2-update/Changelog.txt

Thanks for the reply Colin. Maybe I didn't phrase the question correctly. I am looking to find our what is the difference between firmware with a "D" in it vs. an "E". i.e 47D9 vs. 48E7

 

[ColinTaylor]

The "D" versions are development builds for testing purposes only, they are not release versions. The "E" versions are the release versions.

 

[john9527]

The "D" versions are development builds for testing purposes only, they are not release versions. The "E" versions are the release versions.

Thanks for jumping in.....exactly right.

Maybe a bit of an overview of how I do the development would help. After I do a public release (E version), I checkout a new branch in git with a copy of that release. In this branch I do any new work (commits come and go, get modified, add fixes for testing on a reported problem, etc). When things look like they are working, I'll make a checkpoint to a 'D' release number that I can make available for some user testing. I also have a checkpoint now to go back to as I try additional changes.

When I'm ready to do a new public 'E' release, I merge in the 'D' commits to the main branch and do some final testing. Then start again....

 

[anotherengineer]

I suppose the old RT-N12 h/w ver: D1 isn't supported??

 

[john9527]

I suppose the old RT-N12 h/w ver: D1 isn't supported??

Sorry....N12 was never supported.

 

[pokazene_maslo]

Hi.

I installed this FW on my RT-N66U and it's working, however I'm unable to get DNS over TLS working. These are my settings:
DNS WAN settings:
Connect to DNS Server automatically: yes
Enable DNS over TLS support: yes
Exclude DoT servers with logs: yes
DoT server access: round robin
DoT Servers: dot.securedns.eu server, Fondation RESTENA, Cloudflare Primary, Cloudflare Secondary
DoT Local Port: 5453
Enable DNSSEC support: yes
DNSSEC validation method: dnsmasq
Enable DNS Rebind protection: no
Prevent client auto DoH: auto

I verified that my computer is set to use my routers IP address as DNS. DoH in Firefox browser is disabled. Despite all of this https://tenta.com/test/ reports:
DNS IP Address: 158.64.1.29
ISP: Fondation RESTENA
TLS Enabled: false

and https://www.cloudflare.com/ssl/encrypted-sni/ reports that Secure DNS is "you may not be using secure DNS"

Any idea what might be causing that DNS over TLS is not working?

Thanks a lot!

 

[ColinTaylor]

Any idea what might be causing that DNS over TLS is not working?

I suspect that it is working. The Cloudflare test only works when you're using their servers only. Remove dot.securedns.eu server and Fondation RESTENA and test it again.

 

[pokazene_maslo]

I suspect that it is working. The Cloudflare test only works when you're using their servers only. Remove dot.securedns.eu server and Fondation RESTENA and test it again.

If I leave only "Cloudflare Primary, Cloudflare Secondary" as DoT servers, the results still report DoT as non working:
couldflare's website still reports "you may not be using secure DNS"
tenta.com/test/ reports: 141.101.95.33; Cloudflare; Prague, Czechia; TLS enabled: false

 

[sto]

If I leave only "Cloudflare Primary, Cloudflare Secondary" as DoT servers, the results still report DoT as non working:
couldflare's website still reports "you may not be using secure DNS"
tenta.com/test/ reports: 141.101.95.33; Cloudflare; Prague, Czechia; TLS enabled: false

Try setting DNSSEC validation to Server Only and test the Cloudflare servers again. That works for me.

 

[john9527]

I have yet to find a DoT test that works consistently across all browsers. Maybe something with dnsmasq proxying the stubby/DoT traffic.
For example, this site https://www.cloudflare.com/ssl/encrypted-sni/ will also work with Firefox with DNSSEC server only, but fails with Chrome. No idea what tenta is doing.

One way to check is to monitor the WAN interface traffic over port 853. Another approach to get a comfort level would be to increase the stubby loglevel (nvram set stubby_loglevel=7, default is 4) and watch the traffic in the stubby log (/var/tmp/stubby/stubby.log). But be careful, it generates a LOT of logging.

 

[pokazene_maslo]

Try setting DNSSEC validation to Server Only and test the Cloudflare servers again. That works for me.

Setting DNSSEC validation to Server Only resolved the problem. Now https://www.cloudflare.com/ssl/encrypted-sni/ shows "You are using encrypted DNS transport with 1.1.1.1"
Tenta still shows DNS enabled: false.

Thank you!

I have yet to find a DoT test that works consistently across all browsers. Maybe something with dnsmasq proxying the stubby/DoT traffic.
For example, this site https://www.cloudflare.com/ssl/encrypted-sni/ will also work with Firefox with DNSSEC server only, but fails with Chrome. No idea what tenta is doing.

One way to check is to monitor the WAN interface traffic over port 853. Another approach to get a comfort level would be to increase the stubby loglevel (nvram set stubby_loglevel=7, default is 4) and watch the traffic in the stubby log (/var/tmp/stubby/stubby.log). But be careful, it generates a LOT of logging.

Maybe one solution is to integrate some DoT test into the Asuswrt-Merlin GUI?

 

[MysticGold04]

Could anyone provide guidance on assigning static IP addresses via file, or dnsmasq options instead of the GUI? I was able to do this easily on DDWRT, but the format seems to be different for this firmware.

Would the info in this post work?

Backup Manual DHCP List?

Is there a way to backup the Manually Assigned IP entries via the command-line? And if so, how? Could I also assume that it could then be restored after doing a factory reset?

www.snbforums.com

 

[ColinTaylor]

Could anyone provide guidance on assigning static IP addresses via file, or dnsmasq options instead of the GUI? I was able to do this easily on DDWRT, but the format seems to be different for this firmware.

Would the info in this post work?

Backup Manual DHCP List?

Is there a way to backup the Manually Assigned IP entries via the command-line? And if so, how? Could I also assume that it could then be restored after doing a factory reset?

www.snbforums.com

Yes the information in that thread/post should still be applicable to John's firmware. Of course such file entries will not show up in the GUI and you'd need to make sure they don't conflict with any that are defined in the GUI.

 

[MysticGold04]

So I created a static lease text file, removed my GUI leases and got this:

24 15:23:54 dnsmasq[1693]: bad hex constant at line 1 of /jffs/static_leases
Apr 24 15:23:54 dnsmasq[1693]: bad hex constant at line 2 of /jffs/static_leases
Apr 24 15:23:54 dnsmasq[1693]: bad hex constant at line 3 of /jffs/static_leases
Apr 24 15:23:54 dnsmasq[1693]: bad hex constant at line 4 of /jffs/static_leases
Apr 24 15:23:54 dnsmasq[1693]: bad hex constant at line 5 of /jffs/static_leases
Apr 24 15:23:54 dnsmasq[1693]: bad hex constant at line 6 of /jffs/static_leases
Apr 24 15:23:54 dnsmasq[1693]: bad hex constant at line 7 of /jffs/static_leases
Apr 24 15:23:54 dnsmasq[1693]: bad hex constant at line 8 of /jffs/static_leases
Apr 24 15:23:54 dnsmasq[1693]: bad hex constant at line 9 of /jffs/static_leases
Apr 24 15:23:54 dnsmasq[1693]: bad hex constant at line 10 of /jffs/static_leases
Apr 24 15:23:54 dnsmasq[1693]: bad hex constant at line 11 of /jffs/static_leases
Apr 24 15:23:54 dnsmasq[1693]: bad hex constant at line 12 of /jffs/static_leases
Apr 24 15:23:54 dnsmasq[1693]: bad hex constant at line 13 of /jffs/static_leases
Apr 24 15:23:54 dnsmasq[1693]: bad hex constant at line 14 of /jffs/static_leases
Apr 24 15:23:54 dnsmasq[1693]: bad hex constant at line 15 of /jffs/static_leases
Apr 24 15:23:54 dnsmasq[1693]: bad hex constant at line 16 of /jffs/static_leases
Apr 24 15:23:54 dnsmasq[1693]: bad hex constant at line 17 of /jffs/static_leases
Apr 24 15:23:54 dnsmasq[1693]: bad hex constant at line 18 of /jffs/static_leases
Apr 24 15:23:54 dnsmasq[1693]: bad hex constant at line 19 of /jffs/static_leases
Apr 24 15:23:54 dnsmasq[1693]: bad hex constant at line 20 of /jffs/static_leases
Apr 24 15:23:54 dnsmasq[1693]: bad hex constant at line 21 of /jffs/static_leases
Apr 24 15:23:54 dnsmasq[1693]: bad hex constant at line 22 of /jffs/static_leases
Apr 24 15:23:54 dnsmasq[1693]: bad hex constant at line 23 of /jffs/static_leases
Apr 24 15:23:54 dnsmasq[1693]: bad hex constant at line 24 of /jffs/static_leases
Apr 24 15:23:54 dnsmasq[1693]: bad hex constant at line 25 of /jffs/static_leases
Apr 24 15:23:54 dnsmasq[1693]: bad hex constant at line 26 of /jffs/static_leases
Apr 24 15:23:54 dnsmasq[1693]: bad hex constant at line 27 of /jffs/static_leases
Apr 24 15:23:54 dnsmasq[1693]: bad hex constant at line 28 of /jffs/static_leases
Apr 24 15:23:54 dnsmasq[1693]: bad hex constant at line 29 of /jffs/static_leases
Apr 24 15:23:54 dnsmasq-dhcp[1693]: read /jffs/static_leases

any idea what that means?? I did run the dos2unix command to make sure all was good...

 

[ColinTaylor]

Can you show us a few lines from the file. The real data, not edited.

 

[ColinTaylor]

Ah, OK I see the problem. It should look like this:
<redacted>

 

[MysticGold04]

yep, I realized that once I posted, so I deleted my post... thank you!!

 

[elorimer]

I'm puzzling out a problem starting an OpenVPN server on this release on an ac56U.

I usually set up the servers to listen only on the WAN interface by including in the custom configuration file my ddns address:

local [myddnsname].asuscomm.com

With this included, the server fails to start, with a message that it cannot bind to this address. If I exclude that command, it starts fine.

 

[ColinTaylor]

My guess is that your DDNS address is not returning the correct WAN IP address. But I'm not sure why you're doing this in the first place as the VPN server only binds to the router's WAN IP already, so you're duplicating what it already does.

 

[elorimer]

I thought the OpenVPN server binds to all interfaces.