Menu
What's new
By:
Filters Better Search

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

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

followmsi said:
Here you are .. (removed " resolvconf: "/tmp/resolv.conf" " already )
Click to expand...
John by default sets the TLS min version to 1_3 and the ciphers to match. Why change to 1_2?

edit: re-read previous posts after more coffee. Never mind.

but make sure ciphers are still valid with Cloudflare
 
dave14305 said:
John by default sets the TLS min version to 1_3 and the ciphers to match. Why change to 1_2?
Click to expand...
Stubby uses chiperlist for tls 12 and ciphersuite for tls 13.

I added tls min version to make connection stable with 1.1.1.1.

No idea why John stock config (tls min ver 13) is not working (anymore).

That's why I am asking here :)

EDIT:
DNS resolution works with tls min ver 13 .. but quite unstable .. get DNS timeout.

EDIT2 ..
Take your coffee first :)
Has chipersuite changed for cloudflare ?
Do you have correct chipersuite to use tls 13 with 1.1.1.1 ?

Thanks
 
Last edited:
followmsi said:
Stubby uses chiperlist for tls 12 and ciphersuite for tls 13.

I added tls min version to make connection stable with 1.1.1.1.

No idea why John stock config (tls min ver 13) is not working (anymore).

That's why I am asking here :)

EDIT:
DNS resolution works with tls min ver 13 .. but quite unstable .. get DNS timeout.

EDIT2 ..
Take your coffee first :)
Has chipersuite changed for cloudflare ?
Do you have correct chipersuite to use tls 13 with 1.1.1.1 ?

Thanks
Click to expand...
Running Merlin 384.13 at the moment, but it's an interesting test to prove or disprove if it's the fork or not.
Code: 
echo | openssl11 s_client -tls1_3 -verify 1 -CAfile /rom/etc/ssl/certs/ca-certificates.crt -connect 1.1.1.1:853
If I run this command repeatedly in SSH, most times it fails but once in a while it succeeds with a TLS1.3 connection.
Good:
Code: 
# echo | openssl11 s_client -tls1_3 -verify 3 -CAfile /rom/etc/ssl/certs/ca-certificates.crt -connect 1.1.1.1:853
verify depth is 3
CONNECTED(00000004)
Can't use SSL_get_servername
depth=2 C = US, O = DigiCert Inc, OU = www.digicert.com, CN = DigiCert Global Root CA
verify return:1
depth=1 C = US, O = DigiCert Inc, CN = DigiCert ECC Secure Server CA
verify return:1
depth=0 C = US, ST = California, L = San Francisco, O = "Cloudflare, Inc.", CN = cloudflare-dns.com
verify return:1
---
Certificate chain
 0 s:C = US, ST = California, L = San Francisco, O = "Cloudflare, Inc.", CN = cloudflare-dns.com
   i:C = US, O = DigiCert Inc, CN = DigiCert ECC Secure Server CA
 1 s:C = US, O = DigiCert Inc, CN = DigiCert ECC Secure Server CA
   i:C = US, O = DigiCert Inc, OU = www.digicert.com, CN = DigiCert Global Root CA
---
Server certificate
-----BEGIN CERTIFICATE-----
<snip>
-----END CERTIFICATE-----
subject=C = US, ST = California, L = San Francisco, O = "Cloudflare, Inc.", CN = cloudflare-dns.com

issuer=C = US, O = DigiCert Inc, CN = DigiCert ECC Secure Server CA

---
No client certificate CA names sent
Peer signing digest: SHA256
Peer signature type: ECDSA
Server Temp Key: X25519, 253 bits
---
SSL handshake has read 2786 bytes and written 279 bytes
Verification: OK
---
New, TLSv1.3, Cipher is TLS_CHACHA20_POLY1305_SHA256
Server public key is 256 bit
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
Early data was not sent
Verify return code: 0 (ok)
---
---
Post-Handshake New Session Ticket arrived:
SSL-Session:
    Protocol  : TLSv1.3
    Cipher    : TLS_CHACHA20_POLY1305_SHA256
    Session-ID: <snip>
    Session-ID-ctx:
    Resumption PSK: <snip>
    PSK identity: None
    PSK identity hint: None
    SRP username: None
    TLS session ticket lifetime hint: 21600 (seconds)
    TLS session ticket:
<snip>
    Start Time: 1574438878
    Timeout   : 7200 (sec)
    Verify return code: 0 (ok)
    Extended master secret: no
    Max Early Data: 0
---
read R BLOCK
DONE
Bad:
Code: 
# echo | openssl11 s_client -tls1_3 -verify 3 -CAfile /rom/etc/ssl/certs/ca-certificates.crt -connect 1.1.1.1:853
verify depth is 3
CONNECTED(00000004)
1024:error:1409442E:lib(20):func(148):reason(1070):NA:0:SSL alert number 70
---
no peer certificate available
---
No client certificate CA names sent
---
SSL handshake has read 7 bytes and written 215 bytes
Verification: OK
---
New, (NONE), Cipher is (NONE)
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
Early data was not sent
Verify return code: 0 (ok)
---
So I suspect not every endpoint behind 1.1.1.1 is supporting TLS 1.3 yet. Therefore, overriding the TLS min version to 1.2 will allow Stubby to use TLS 1.3 when it randomly connects to an endpoint capable of 1.3, and will continue to function when reaching one that cannot do 1.3.

Something must have changed on Cloudflare's backend recently, at least in the geographies of those of us who see the issue.
 
Last edited:
dave14305 said:
Running Merlin 384.13 at the moment, but it's an interesting test to prove or disprove if it's the fork or not.
Code: 
echo | openssl11 s_client -tls1_3 -verify 1 -CAfile /rom/etc/ssl/certs/ca-certificates.crt -connect 1.1.1.1:853
If I run this command repeatedly in SSH, most times it fails but once in a while it succeeds with a TLS1.3 connection.
Good:
Code: 
# echo | openssl11 s_client -tls1_3 -verify 3 -CAfile /rom/etc/ssl/certs/ca-certificates.crt -connect 1.1.1.1:853
verify depth is 3
CONNECTED(00000004)
Can't use SSL_get_servername
depth=2 C = US, O = DigiCert Inc, OU = www.digicert.com, CN = DigiCert Global Root CA
verify return:1
depth=1 C = US, O = DigiCert Inc, CN = DigiCert ECC Secure Server CA
verify return:1
depth=0 C = US, ST = California, L = San Francisco, O = "Cloudflare, Inc.", CN = cloudflare-dns.com
verify return:1
---
Certificate chain
 0 s:C = US, ST = California, L = San Francisco, O = "Cloudflare, Inc.", CN = cloudflare-dns.com
   i:C = US, O = DigiCert Inc, CN = DigiCert ECC Secure Server CA
 1 s:C = US, O = DigiCert Inc, CN = DigiCert ECC Secure Server CA
   i:C = US, O = DigiCert Inc, OU = www.digicert.com, CN = DigiCert Global Root CA
---
Server certificate
-----BEGIN CERTIFICATE-----
<snip>
-----END CERTIFICATE-----
subject=C = US, ST = California, L = San Francisco, O = "Cloudflare, Inc.", CN = cloudflare-dns.com

issuer=C = US, O = DigiCert Inc, CN = DigiCert ECC Secure Server CA

---
No client certificate CA names sent
Peer signing digest: SHA256
Peer signature type: ECDSA
Server Temp Key: X25519, 253 bits
---
SSL handshake has read 2786 bytes and written 279 bytes
Verification: OK
---
New, TLSv1.3, Cipher is TLS_CHACHA20_POLY1305_SHA256
Server public key is 256 bit
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
Early data was not sent
Verify return code: 0 (ok)
---
---
Post-Handshake New Session Ticket arrived:
SSL-Session:
    Protocol  : TLSv1.3
    Cipher    : TLS_CHACHA20_POLY1305_SHA256
    Session-ID: <snip>
    Session-ID-ctx:
    Resumption PSK: <snip>
    PSK identity: None
    PSK identity hint: None
    SRP username: None
    TLS session ticket lifetime hint: 21600 (seconds)
    TLS session ticket:
<snip>
    Start Time: 1574438878
    Timeout   : 7200 (sec)
    Verify return code: 0 (ok)
    Extended master secret: no
    Max Early Data: 0
---
read R BLOCK
DONE
Bad:
Code: 
# echo | openssl11 s_client -tls1_3 -verify 3 -CAfile /rom/etc/ssl/certs/ca-certificates.crt -connect 1.1.1.1:853
verify depth is 3
CONNECTED(00000004)
1024:error:1409442E:lib(20):func(148):reason(1070):NA:0:SSL alert number 70
---
no peer certificate available
---
No client certificate CA names sent
---
SSL handshake has read 7 bytes and written 215 bytes
Verification: OK
---
New, (NONE), Cipher is (NONE)
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
Early data was not sent
Verify return code: 0 (ok)
---
So I suspect not every endpoint behind 1.1.1.1 is supporting TLS 1.3 yet. Therefore, overriding the TLS min version to 1.2 will allow Stubby to use TLS 1.3 when it randomly connects to an endpoint capable of 1.3, and will continue to function when reaching one that cannot do 1.3.

Something must have changed on Cloudflare's backend recently, at least in the geographies of those of us who see the issue.
Click to expand...

Thanks for testing and proving the current situation !

Would love to have openssl11 binary in Johns fork as well .. maybe at some point - when he is back :)

With TLS min version 1.2 the connection to 1.1.1.1 is rock stable .. like it used to be before.
Realized the DNS drops since a few days/weeks only .. TLS min version 1.3 was stable all the time before.

We may open ticket at cloudflare .. ? :)
No idea .. or we just try again after some days/weeks .. maybe it magically works after some time.

What is also a bit strange ..
Using (stable) tls min vers 12 the 1.1.1.1 test page (https://1.1.1.1/help) becomes "unstable".
The page shows "NO" for DoT connection .. sometimes the check works.

If I switch back to (unstable) tls min vers 13 the webpage shows always "YES" for DoT connection.
All tests are successful .. never failing tests for DoT .. even DNS get timeouts :)

Cheers
 
Until the CloudFlare situation stabilizes, I would recommend that anyone using DoT on the fork use this stubby.postconf:
Code: 
#!/bin/sh

. /usr/sbin/helper.sh

CONFIG="$1"

pc_delete "tls_min_version: GETDNS_TLS1_3" "$CONFIG"
This will use the stubby default GETDNS_TLS1_2. Better than a stubby.yml.add which would end up with 2 different tls_min_version directives in the same file.
 
Changelog
---------
374.43_40EBj9527 (21-November-2019) ARM SDK, MIPS,ARM KRACK
- CHANGED: dnsmasq: update to 2.80-g456a319

374.43_40EAj9527 (11-November-2019) ARM SDK, MIPS,ARM KRACK
- CHANGED: openvpn: update to 2.4.8
- FIXED: webui: allow empty local IP for IPv6 firewall rule
Click to expand...
No Stubby fixes, but happy to see he's still working on it when he wants to. :)
 
There is no good reason to set a minimal version to 1.3. TLS 1.2 is considered secure, and it's the most widely supported protocol at the moment. Let Stubby (or rather, OpenSSL) negotiate with the remote end which protocol to use. If they support 1.3, it will be used, otherwise it will downgrade to 1.2, and you will still be fine and secure.
 
Hmm. New update in dev. Must install.
 
dave14305 said:
So I suspect not every endpoint behind 1.1.1.1 is supporting TLS 1.3 yet. Therefore, overriding
Something must have changed on Cloudflare's backend recently, at least in the geographies of those of us who see the issue.
Click to expand...
I couldn't remotely prove it but that was my thought. I might try toggling that tls 1.2 setting a little later on.
 
dave14305 said:
Until the CloudFlare situation stabilizes, I would recommend that anyone using DoT on the fork use this stubby.postconf:
Code: 
#!/bin/sh

. /usr/sbin/helper.sh

CONFIG="$1"

pc_delete "tls_min_version: GETDNS_TLS1_3" "$CONFIG"
This will use the stubby default GETDNS_TLS1_2. Better than a stubby.yml.add which would end up with 2 different tls_min_version directives in the same file.
Click to expand...

Thank you. This timeout problem has been driving me nuts. All of a sudden using DoT with 1.1.1.1 has been producing random timeouts in Chrome. DoT disabled the issue disappears. Thought it was something on my end. I'll be giving this fix a try.
 
cvx01 said:
Thank you. This timeout problem has been driving me nuts. All of a sudden using DoT with 1.1.1.1 has been producing random timeouts in Chrome. DoT disabled the issue disappears. Thought it was something on my end. I'll be giving this fix a try.
Click to expand...
@followmsi and @Rahul_K figured out how to stabilize it. I just dug deeper to figure out why it worked. A community effort! :)
 
dave14305 said:
@followmsi and @Rahul_K figured out how to stabilize it. I just dug deeper to figure out why it worked. A community effort! :)
Click to expand...

@followmsi, @Rahul_K thank you both as well. Good to see this community still alive while John is away.

@dave14305 - Thanks for the earlier post on 374.43_40EBj9527. That was going to be my next question, but you've already answered it. :)
 
Ran across this post searching for another issue. Is this perhaps related?

When adding pc_delete "tls_min_version: GETDNS_TLS1_3" Cloudflare complains and says "You are not using secure transport for your DNS". If I remove that line, test says "You are using encrypted DNS transport with 1.1.1.1". Note, I am only using DoT, no DNSSEC enabled in either scenario. Assume this is just because 1.3 isn't being used?
 
cvx01 said:
Ran across this post searching for another issue. Is this perhaps related?

When adding pc_delete "tls_min_version: GETDNS_TLS1_3" Cloudflare complains and says "You are not using secure transport for your DNS". If I remove that line, test says "You are using encrypted DNS transport with 1.1.1.1". Note, I am only using DoT, no DNSSEC enabled in either scenario. Assume this is just because 1.3 isn't being used?
Click to expand...
Run
Code: 
stubby -C /etc/stubby.yml -i
to make sure the final stubby config file is valid. If the site doesn’t think you’re using secure dns (DoT), then stubby isn’t working perhaps. Post your stubby.yml if you get errors back from the command.
Edit: Even with DoT enabled on Merlin with Cloudflare and confirmed with tcpdump, the Cloudflare sites don’t think I’m using DoT. Can’t take those testing sites seriously anymore, if we ever could in the first place.
 
Last edited:
dave14305 said:
@followmsi and @Rahul_K figured out how to stabilize it. I just dug deeper to figure out why it worked. A community effort! :)
Click to expand...
cvx01 said:
Ran across this post searching for another issue. Is this perhaps related?

When adding pc_delete "tls_min_version: GETDNS_TLS1_3" Cloudflare complains and says "You are not using secure transport for your DNS". If I remove that line, test says "You are using encrypted DNS transport with 1.1.1.1". Note, I am only using DoT, no DNSSEC enabled in either scenario. Assume this is just because 1.3 isn't being used?
Click to expand...
I’ve updated the firmware to 40EB and reinstated cloudflare DoT with the tls 1.3 setting stripped from the stubby configuration. Working pretty good so far through about six hours.

@cvx01 I also coincidentally tested at the cloudflare site after I was up and running and didn’t have that issue.
 
jrmwvu04 said:
I’ve updated the firmware to 40EB and reinstated cloudflare DoT with the tls 1.3 setting stripped from the stubby configuration. Working pretty good so far through about six hours.

@cvx01 I also coincidentally tested at the cloudflare site after I was up and running and didn’t have that issue.
Click to expand...

It is the weirdest thing, this morning I hit https://1.1.1.1/help 5 times in a row doing nothing more than hitting refresh, attempts 1-4 state DoT = No. On the 5th attempt forward it will now continually state I’m using DoT. Same with the other site yesterday.
 
dave14305 said:
Run
Code: 
stubby -C /etc/stubby.yml -i
Click to expand...

Result: Config file syntax is valid. I’m also leaning toward these sites being the issue, just seems odd it would recognize DoT after several attempts. Also odd it says I’m using DNSSEC, when I have that turned off in the UI.

I will say, regardless of the the other anomaly above, the fix no doubt solves the ERR_NAME_RESOLUTION_FAILED in Chrome. Zero issues since the fix was applied.
 
Last edited:
cvx01 said:
Result: Config file syntax is valid. I’m also leaning toward these sites being the issue, just seems odd it would recognize DoT after several attempts. Also odd it says I’m using DNSSEC, when I have that turned off in the UI.

I will say, regardless of the the other anomaly above, the fix no doubt solves the ERR_NAME_RESOLUTION_FAILED in Chrome. Zero issues since the fix was applied.
Click to expand...
Sounds a lot like the 1.3 issue - depending on which backend server you reach you get a different result. Cloudflare growing pains.
 
cvx01 said:
Result: Config file syntax is valid. I’m also leaning toward these sites being the issue, just seems odd it would recognize DoT after several attempts. Also odd it says I’m using DNSSEC, when I have that turned off in the UI.

I will say, regardless of the the other anomaly above, the fix no doubt solves the ERR_NAME_RESOLUTION_FAILED in Chrome. Zero issues since the fix was applied.
Click to expand...
I noticed that as well, the DNSSEC thing. I chalked it up to careful wording. It reads, “Your resolver validates DNS responses with DNSSEC.” which is I guess technically correct even if you’re not configured to use it.
 
Hey guys, it's my first time flashing a custom firmware to my N66U... I have some questions, I hope someone is able to answer.

Do I need to factory reset BEFORE flashing the firmware or only after is enough?

Can I flash this fork directly over the latest firmware (800+) or I need to downgrade to stock 374 before doing so?

I'm asking those questions because I did flashed over the latest firmware using asus recovering tool and everything went fine apparently (did a factory reset after), but the web interface is kinda messed up in some places, for exemple some horizontal tab menus are misplaced, there's text behind buttons etc. Is this normal for this fork? Maybe it's the browser's cache?
 
You must log in or register to reply here.

Similar threads

D
[Alpha] Gnuton 3006.102.2_2-gnuton1
Replies
0
Views
389
DJones
D
D
Release GNUton [Official Fork] 388.8_2 Release
2
Replies
35
Views
8K
bennor
B
RMerlin
Release Asuswrt-Merlin 386.14 is now available for AC models
11 12 13
Replies
240
Views
39K
Tech9
Tech9
D
Release GNUTON- 388.7_1 release [Official FORK]
Replies
4
Views
3K
MatteoPV
M
D
[Alpha] 3004.388.8_4-gnuton0_alpha1
Replies
0
Views
493
DJones
D
Similar threads
Thread starter Title Forum Replies Date
D Release GNUton [Official Fork] 388.8_2 Release Asuswrt-Merlin 35
D Release GNUTON- 388.7_1 release [Official FORK] Asuswrt-Merlin 4
J How do I use GNUton's fork for my DSL-AX82U please. Asuswrt-Merlin 6
M Asuswrt-Merlin with Nextcloud's share folder functionality Asuswrt-Merlin 1
visortgw Asuswrt Merlin 3006.102.3 Alpha1 for GT-BE98 Pro Asuswrt-Merlin 38
A ASUSwrt-Merlin connection to modem as Access Point and/or Bridge Asuswrt-Merlin 6
kaotic2499 Please add Asuswrt-merlin to GT-BE98 (Non-pro) version Asuswrt-Merlin 22
RMerlin Release Asuswrt-Merlin 3004.388.8_4 is now available Asuswrt-Merlin 160
RMerlin Release Asuswrt-Merlin 3006.102.2 is now available for Wifi 7 devices Asuswrt-Merlin 98
B Unable to establish VPN connection to my PiVPN (ovpn) from my Asus RT-AC86U running Asuswrt-Merlin 386.14 Asuswrt-Merlin 1

Similar threads

Latest threads

Support SNBForums w/ Amazon

If you'd like to support SNBForums, just use this link and buy anything on Amazon. Thanks!

Sign Up For SNBForums Daily Digest

Get an update of what's new every day delivered to your mailbox. Sign up here!

Members online

Total: 894 (members: 25, guests: 869)
Top