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

[bbunge]

Got more memory problems on 34E3 this morning, log attached (again hostnames removed). Slightly different to before in that no WAN, but the wifi stayed up and I could look at the logs and do a reboot from there.

I see 36E4 is out now so I'll just move to that and do as thorough a reset as I can - what is the right way to do that? "Factory Default" under Administration - Restore/Save/Upload Setting, or is there a better way? Before/after(/both) flashing?

Do you have a swap file?

Sent from my P01M using Tapatalk

 

[john9527]

Got more memory problems on 34E3 this morning, log attached (again hostnames removed). Slightly different to before in that no WAN, but the wifi stayed up and I could look at the logs and do a reboot from there.

Looking at the log, there's really no rhyme or reason as to the processes that are getting killed. That, coupled with the fact that it seems you are the only one reporting this type of problem, is leading me to think you may actually have a hardware problem. First thing would be to try and replace the power supply, as when those start getting weak it can lead to all sorts of strange problems.

 

[ColinTaylor]

A few DNS servers compared, attached

Unfortunately I found the normal usage of DNSbench did not produce representative times for DoT lookups. For example it said that Quad9 was noticeably faster than Cloudflare (which is true for normal DNS lookups) but when using DoT the reverse was true.

To get representative times you'd have to configure the router to use one specific DoT server and then run something like namebench against the router's IP address, remembering to choose only Cache Latency Test (100% miss). Then change the router's DoT server and repeat the process.

 

[john9527]

Edit- so far no errors in stubby log with the mod to stubby-
EDIT EDIT- scratch that- stubby errors...

But is your browsing better?

If it is, it would indicate that something is 'slow' in the connection to the DoT servers. Whether it's a limitation of MIPS, an overloaded server or something with your ISP routing I can't tell, but more likely one of the latter as @jrmwvu04 speculated.

 

[jrmwvu04]

But is your browsing better?

If it is, it would indicate that something is 'slow' in the connection to the DoT servers. Whether it's a limitation of MIPS, an overloaded server or something with your ISP routing I can't tell, but more likely one of the latter as @jrmwvu04 speculated.

To elaborate on this a bit, I manage another AC68 for a family member in addition to my own. Here where I am, I connect to a cloudflare server that is in the same city. At the other location, it connects to one in Toronto, Ontario, Canada. Not only not the same city, not the same country. Hundreds of miles away. And the performance is, as you might guess, poorer. Not bad, but definitely not as good as I see on my network. It stands to reason that YMMV as well.

 

[tyspeed42]

To elaborate on this a bit, I manage another AC68 for a family member in addition to my own. Here where I am, I connect to a cloudflare server that is in the same city. At the other location, it connects to one in Toronto, Ontario, Canada. Not only not the same city, not the same country. Hundreds of miles away. And the performance is, as you might guess, poorer. Not bad, but definitely not as good as I see on my network. It stands to reason that YMMV as well.

Mine does that also, hits a cloudfare server in Germany every once in awhile.

 

[Deleted member 27741]

But is your browsing better?

If it is, it would indicate that something is 'slow' in the connection to the DoT servers. Whether it's a limitation of MIPS, an overloaded server or something with your ISP routing I can't tell, but more likely one of the latter as @jrmwvu04 speculated.

It is the same at it was before, it seemed to be a bit more reliable at first and perhaps it is, but the problem still comes up. Where is the configuration file for stubby so I can fool around with the settings there if anyone knows.

 

[jrmwvu04]

It is the same at it was before, it seemed to be a bit more reliable at first and perhaps it is, but the problem still comes up. Where is the configuration file for stubby so I can fool around with the settings there if anyone knows.

/tmp/etc/stubby.yml - make permanent changes via /jffs/scripts/stubby.postconf

 

[john9527]

Where is the configuration file for stubby so I can fool around with the settings there if anyone knows.

In the next release I moved a couple of the key parameters into nvram (retries and timeout) to make it easier to experiment.

 

[jsbeddow]

Just to follow up on the mysterious SSH access button "not sticking" issue I described previously, it seems to have been caused by a setting in Skynet that is now on by default (but that caused no problem when I previously used the Merlin branch), to "disable insecure access". When I disabled that, no more problems getting the SSH access button to remain on.
Now I have a new problem: getting Diversion working properly again (despite a clearing of jffs, formatting the USB drive, and full reinstalltion from scratch). Any chance this might be caused by the DNS rebind protection setting? (I am not there right now to test it).

 

[blueshark]

Estrange! My nvram is 85% full and nothing installed to justify this amount.

Stubby.postconf make permanent change !?

 

[john9527]

Estrange! My nvram is 85% full and nothing installed to justify this amount.

https://www.snbforums.com/threads/asuswrt-merlin-380-59-ac68u-port-fwd-apply-fail.33895/#post-273422

Also, on the fork, if you are running an OpenVPN server or client, the certs and keys are stored in nvram by default. You need to manually move them over to jffs. See the Merlin_Fork_Options.txt file.

 

[blueshark]

https://www.snbforums.com/threads/asuswrt-merlin-380-59-ac68u-port-fwd-apply-fail.33895/#post-273422

Also, on the fork, if you are running an OpenVPN server or client, the certs and keys are stored in nvram by default. You need to manually move them over to jffs. See the Merlin_Fork_Options.txt file.

I am not running any vpn on router

 

[Deleted member 27741]

Running stubby.postconf, or any other postconf file I have from SSH results in what appears to be an error that shows up for each pc_replace line:
sed -i requires an argument

 

[john9527]

Running stubby.postconf, or any other postconf file I have from SSH results in what appears to be an error that shows up for each pc_replace line:
sed -i requires an argument

- post the postconf file
- run dos2unix in case it's been saved in Windows format by mistake

 

[john9527]

I am not running any vpn on router

Post the output of the command from the referenced post.....

This can also happen if you update from Merlin and don't do a factory reset.

 

[ColinTaylor]

Running stubby.postconf, or any other postconf file I have from SSH results in what appears to be an error that shows up for each pc_replace line:
sed -i requires an argument

You have to pass an argument to the postconf script when you run it.

./stubby.postconf /etc/stubby.yml

 

[Deleted member 27741]

Tried this command if that is what you were getting at:

/jffs/scripts/stubby.postconf /etc/stubby.yml

same error, for each pc_replace I get this:
sed -i requires an argument

Here is the text of the stubby.postconf file I am trying to run, file is in UTF-8 format:

EDIT: This script is corrected below (CONFIG=$1 added below helper.sh line) according to ColinTaylosr's comment below:

#!/bin/sh
logger -t $(basename $0) "STARTING SCRIPT, PARAMETER: $1"
/bin/sleep 1s
source /usr/sbin/helper.sh
CONFIG=$1
pc_replace "timeout: 2000" "timeout: 5000" $CONFIG
pc_replace "idle_timeout: 5000" "idle_timeout: 10000" $CONFIG
pc_replace "tls_query_padding_blocksize: 128" "tls_query_padding_blocksize: 256" $CONFIG
pc_replace "tls_connection_retries: 5" "tls_connection_retries: 2" $CONFIG

 

[ColinTaylor]

same error, for each pc_replace I get this:
sed -i requires an argument

Your script is missing this line just before the helper line:

CONFIG=$1

 

[Deleted member 27741]

That got it working. Ah, nothing like scripting with no freakin' idea what you're (and by you're I mean I'm) doing, AMIRIGHT?

EDIT- currently trying out this configuration for stubby, it is the most reliable I have tried so far-

tls_ca_file: "/rom/ca-bundle.crt"
resolution_type: GETDNS_RESOLUTION_STUB
dns_transport_list:
- GETDNS_TRANSPORT_TLS
tls_authentication: GETDNS_AUTHENTICATION_REQUIRED
tls_query_padding_blocksize: 128
edns_client_subnet_private: 1
round_robin_upstreams: 1
idle_timeout: 3000
appdata_dir: "/var/tmp/stubby"
listen_addresses:
- 127.0.0.1@5453
upstream_recursive_servers:
# Cloudflare Primary
- address_data: 1.1.1.1
tls_auth_name: "cloudflare-dns.com"
# Cloudflare Secondary
- address_data: 1.0.0.1
tls_auth_name: "cloudflare-dns.com"

This is the /jffs/scripts/stubby.postconf file I used to get the above configuration, my philosophy here was to go simple (hence deleting some lines) and rely mostly on defaults (though I found documentation on stubby configuration sparse at best)-

#!/bin/sh
logger -t $(basename $0) "STARTING SCRIPT, PARAMETER: $1"
/bin/sleep 1s
source /usr/sbin/helper.sh
CONFIG=$1
pc_replace "tls_query_padding_blocksize: 128" "tls_query_padding_blocksize: 128" $CONFIG
pc_replace "idle_timeout: 2000" "idle_timeout: 3000" $CONFIG
pc_delete "timeout: 2000" $CONFIG
pc_delete "tls_connection_retries: 5" $CONFIG
pc_delete "tls_backoff_time: 900" $CONFIG