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

[maurer]

i also have it both + the error
sudo dpkg -l | grep automake
ii automake 1:1.15-6 all Tool for generating GNU Standards-compliant Makefiles
ii automake1.11 1:1.11.6-4 all Tool for generating GNU Standards-compliant Makefiles

 

[john9527]

i also have it both + the error

I think I see the problem.....the wget '.gitignore' can sometimes be too aggressive (I seem to remember I had a similar problem once before).
I pushed an update to the repro....do a git pull and see if it's fixed.

 

[treboR2Robert]

I read somewhere on SNB that this fork is limited to 2 vpn clients vs original merlin's 5.

Since then I have searched the forum high and low but can't find where i read it.

Does it mean I can setup openvpn SERVER on my N66U and only connect to it with 2 clients at once (i.e phone and a tablet)

Or does it mean I can only set up 2 external VPN connections using the N66U as a client (NordVPN and Hide My butt)

Confusing myself here.

I basically want to know if me and 3 family members can all use my openvpn SERVER (installed on N66U merlin LTS) when were out and about ?

Thanks

 

[john9527]

Or does it mean I can only set up 2 external VPN connections using the N66U as a client (NordVPN and Hide My butt)

This one....

(You may have read it in the first post 'Additional Information' section. I added it with the last release based on some questions in this thread).

EDIT: For the server, the number of clients is set by the VPN subnet/mask....default is 256 although I wouldn't recommend trying that many

 

[ColinTaylor]

@john9527 Is it possible to get stubby to provide more information about why it stops using one upstream server and switches to another? I had it setup with 1.1.1.1 as the primary and 9.9.9.9 as the secondary with access set to ordered but found that it was frequently switching between them for no apparent reason. I changed around the order of the two servers but it made no difference.

I had stubby_loglevel=7 but it just showed the normal messages. Below is a partial (heavily edited) extract of the log file that only indicates the times at which it switched. It goes on like this continuously. I'm happy to accept that it's a problem with the DNS servers rather than the router, but it would be nice to know what exactly the cause of the switching is.

[01:38:52.197584] STUBBY: 1.1.1.1
[01:52:23.024072] STUBBY: 9.9.9.9
[01:52:35.780419] STUBBY: 1.1.1.1
[01:55:25.336285] STUBBY: 9.9.9.9
[01:56:26.115771] STUBBY: 1.1.1.1
[01:57:26.615280] STUBBY: 9.9.9.9
[01:58:27.636661] STUBBY: 1.1.1.1
[01:59:39.202977] STUBBY: 9.9.9.9
[02:00:28.649195] STUBBY: 1.1.1.1
[02:01:29.290540] STUBBY: 9.9.9.9
[02:01:46.600614] STUBBY: 1.1.1.1
[02:02:30.082404] STUBBY: 9.9.9.9
[02:03:31.121325] STUBBY: 1.1.1.1
[02:03:51.926897] STUBBY: 9.9.9.9
[02:04:02.198679] STUBBY: 1.1.1.1
[02:05:32.135952] STUBBY: 9.9.9.9
[02:06:04.414373] STUBBY: 1.1.1.1
[02:06:32.882305] STUBBY: 9.9.9.9
[02:07:12.083805] STUBBY: 1.1.1.1
[02:07:33.708513] STUBBY: 9.9.9.9
[02:07:47.957283] STUBBY: 1.1.1.1
[02:08:34.254872] STUBBY: 9.9.9.9
[02:08:56.372612] STUBBY: 1.1.1.1
[02:09:34.813955] STUBBY: 9.9.9.9
[02:10:35.344851] STUBBY: 1.1.1.1
[02:11:35.847573] STUBBY: 9.9.9.9
[02:12:36.402346] STUBBY: 1.1.1.1
[02:13:52.656686] STUBBY: 9.9.9.9
[02:14:00.144435] STUBBY: 1.1.1.1
[02:15:38.139040] STUBBY: 9.9.9.9
[02:15:51.510883] STUBBY: 1.1.1.1
[02:17:39.578990] STUBBY: 9.9.9.9
[02:18:54.356181] STUBBY: 1.1.1.1
[02:19:36.694177] STUBBY: 9.9.9.9
[02:19:40.657891] STUBBY: 1.1.1.1
[02:20:09.952705] STUBBY: 9.9.9.9
[02:20:29.381667] STUBBY: 1.1.1.1
[02:24:43.910463] STUBBY: 9.9.9.9
[02:25:44.447161] STUBBY: 1.1.1.1
[02:26:05.798615] STUBBY: 9.9.9.9
[02:26:45.084328] STUBBY: 1.1.1.1
[02:31:46.620219] STUBBY: 9.9.9.9
[02:32:48.421845] STUBBY: 1.1.1.1
[02:33:13.472051] STUBBY: 9.9.9.9
[02:33:44.276246] STUBBY: 1.1.1.1
[02:34:38.879518] STUBBY: 9.9.9.9
[02:34:49.372601] STUBBY: 1.1.1.1
[02:35:49.879465] STUBBY: 9.9.9.9
[02:36:44.703579] STUBBY: 1.1.1.1
[02:39:41.985290] STUBBY: 9.9.9.9
[02:39:52.418790] STUBBY: 1.1.1.1
[02:41:57.243103] STUBBY: 9.9.9.9
[03:10:56.022503] STUBBY: 1.1.1.1
[03:32:30.592013] STUBBY: 9.9.9.9
[03:33:21.198951] STUBBY: 1.1.1.1
[03:36:16.773655] STUBBY: 9.9.9.9
[03:37:08.115546] STUBBY: 1.1.1.1
[03:39:00.807132] STUBBY: 9.9.9.9
[03:40:31.608426] STUBBY: 1.1.1.1
[03:47:48.155957] STUBBY: 9.9.9.9
[03:48:39.819292] STUBBY: 1.1.1.1
[03:50:17.019438] STUBBY: 9.9.9.9
[03:52:33.522719] STUBBY: 1.1.1.1
[03:54:01.500790] STUBBY: 9.9.9.9
[03:54:37.720206] STUBBY: 1.1.1.1
[03:57:14.819936] STUBBY: 9.9.9.9
[03:57:23.259641] STUBBY: 1.1.1.1
[03:58:03.502286] STUBBY: 9.9.9.9
[03:58:55.755527] STUBBY: 1.1.1.1
[03:59:13.537348] STUBBY: 9.9.9.9
[04:02:20.900235] STUBBY: 1.1.1.1
[04:02:36.451450] STUBBY: 9.9.9.9
[04:03:43.780949] STUBBY: 1.1.1.1
[04:06:41.657506] STUBBY: 9.9.9.9
[04:07:00.031230] STUBBY: 1.1.1.1
[04:09:02.734906] STUBBY: 9.9.9.9
[04:10:22.687763] STUBBY: 1.1.1.1
[04:10:54.576168] STUBBY: 9.9.9.9

 

[john9527]

@ColinTaylor

Wow, that does look excessive, and not what I am seeing.
First thing I would recommend is to set the loglevel back to the default of 4 (or maybe to 5). I'm not sure the loglevel=7 is really 'eveything' from my observations, but haven't had the chance to crawl through the code yet.

With it set to 4, I was seeing a fair amount (average about 10-15 a day) of TLS failures on Cloudflare with Cloudflare set as the first server, and Quad9 as the second. I then reversed them, and things got substantially quieter. Right now, I just loaded a new firmware build about 2 hours ago, and the log is clean.

 

[ColinTaylor]

Thanks John, I'll try it again (I have had it turned off). But with a lower log level I don't see anything in the log file. With the higher log level I'm not seeing any errors, no connection failures, it's just switching for no apparent reason. Hence me asking if there was a way of getting more information.

In the log below stubby had only been running for just over 4 hours but it had connected to 1.1.1.1 168 times and 9.9.9.9 112 times. EDIT: But the number of connections is not the same as the number of server switches.

[05:53:24.713946] STUBBY: 1.1.1.1                                  : Conn opened: TLS - Strict Profile
[05:53:24.780361] STUBBY: 1.1.1.1                                  : Verify passed : TLS
[05:53:34.803096] STUBBY: 1.1.1.1                                  : Conn closed: TLS - Resps=     2, Timeouts  =     0, Curr_auth =Success, Keepalive(ms)= 10000
[05:53:34.803361] STUBBY: 1.1.1.1                                  : Upstream   : TLS - Resps=   566, Timeouts  =     0, Best_auth =Success
[05:53:34.803487] STUBBY: 1.1.1.1                                  : Upstream   : TLS - Conns=   168, Conn_fails=     0, Conn_shuts=    153, Backoffs     =     0
[05:53:57.865446] STUBBY: 9.9.9.9                                  : Conn opened: TLS - Strict Profile
[05:53:57.943101] STUBBY: 9.9.9.9                                  : Verify passed : TLS
[05:54:03.400948] STUBBY: 9.9.9.9                                  : Conn closed: TLS - Resps=     8, Timeouts  =     0, Curr_auth =Success, Keepalive(ms)= 10000
[05:54:03.401211] STUBBY: 9.9.9.9                                  : Upstream   : TLS - Resps=   367, Timeouts  =     0, Best_auth =Success
[05:54:03.401339] STUBBY: 9.9.9.9                                  : Upstream   : TLS - Conns=   112, Conn_fails=     0, Conn_shuts=    112, Backoffs     =     0
[05:54:04.070813] STUBBY: 9.9.9.9                                  : Conn opened: TLS - Strict Profile
[05:54:04.143022] STUBBY: 9.9.9.9                                  : Verify passed : TLS

P.S. I've just started up stubby again and after less than 10 minutes it has switched servers 5 times.

 

[ColinTaylor]

Do not use Strict DNSSEC some regions where Cloudflare has its DNS servers does not work with Strict DNSSEC.

I am not using DNSSEC.

 

[treboR2Robert]

This one....

(You may have read it in the first post 'Additional Information' section. I added it with the last release based on some questions in this thread).

EDIT: For the server, the number of clients is set by the VPN subnet/mask....default is 256 although I wouldn't recommend trying that many

Perfect. Thanks

 

[john9527]

@ColinTaylor
It looks like you are really in Roundrobin mode (The Backoff counter is the number of times it was forced to try an alternate server, and yours are both zero).

Can you double check the round_robin_upstreams parm in /etc/stubby.yml ?

 

[ColinTaylor]

@ColinTaylor
It looks like you are really in Roundrobin mode (The Backoff counter is the number of times it was forced to try an alternate server, and yours are both zero).

Can you double check the round_robin_upstreams parm in /etc/stubby.yml ?

I thought about round robin but I would expect it to swap one for one, or maybe I'm assuming too much. Round robin is not set AFAICT:

# cat  /etc/stubby.yml
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: 256
edns_client_subnet_private: 1
round_robin_upstreams: 0
idle_timeout: 10000
tls_backoff_time: 900
appdata_dir: "/var/tmp/stubby"
listen_addresses:
  - 127.0.0.1@5453
upstream_recursive_servers:
# Quad 9 Secure Primary
  - address_data: 9.9.9.9
    tls_auth_name: "dns.quad9.net"
# Cloudflare Primary
  - address_data: 1.1.1.1
    tls_auth_name: "cloudflare-dns.com"

The problem is there's no consistency to it. I started stubby an hour ago, it switched 8 times in the first 7 minutes. Since then (50 minutes) it's been stubbornly stuck on 1.1.1.1 without changing.

 

[john9527]

The problem is there's no consistency to it. I started stubby an hour ago, it switched 8 times in the first 7 minutes. Since then (50 minutes) it's been stubbornly stuck on 1.1.1.1 without changing.

Yes, the switching does seem to be a bit quirky as I've been looking at it. It appears as if once it switches due to an error, it doesn't switch again until the another error occurs.

I didn't notice it before, but it also seems that the server list in the yml file should also be in 'reverse' order (last entry is the primary, not the first).

 

[ColinTaylor]

I didn't notice it before, but it also seems that the server list in the yml file should also be in 'reverse' order (last entry is the primary, not the first).

I've not found that (or maybe it's random). But the stubby I'm currently running definitely connected to 9.9.9.9 first.

# cat /var/tmp/stubby/stubby.log
[00:08:00.389157] STUBBY: Read config from file /etc/stubby.yml
[00:08:06.692468] STUBBY: 9.9.9.9                                  : Conn opened: TLS - Strict Profile
[00:08:06.770988] STUBBY: 9.9.9.9                                  : Verify passed : TLS
[00:08:09.931502] STUBBY: 9.9.9.9                                  : Conn closed: TLS - Resps=    19, Timeouts  =     0, Curr_auth =Success, Keepalive(ms)= 10000
[00:08:09.931764] STUBBY: 9.9.9.9                                  : Upstream   : TLS - Resps=    19, Timeouts  =     0, Best_auth =Success
[00:08:09.931891] STUBBY: 9.9.9.9                                  : Upstream   : TLS - Conns=     1, Conn_fails=     0, Conn_shuts=      1, Backoffs     =     0

 

[john9527]

I've not found that (or maybe it's random). But the stubby I'm currently running definitely connected to 9.9.9.9 first.

Yes, it connected in order (it looks like to test each defined server)...but then it settled on the last one.

 

[maurer]

I think I see the problem.....the wget '.gitignore' can sometimes be too aggressive (I seem to remember I had a similar problem once before).
I pushed an update to the repro....do a git pull and see if it's fixed.

different errors but still wget is the issue

Spoiler: error log

make[4]: Leaving directory '/home/debian/asuswrt-merlin-374.43_2-update/release/src/router/zlib'
make -C wget
make[4]: Entering directory '/home/debian/asuswrt-merlin-374.43_2-update/release/src/router/wget'
CDPATH="${ZSH_VERSION+.}:" && cd . && /bin/bash /home/debian/asuswrt-merlin-374.43_2-update/release/src/router/wget/build-aux/missing aclocal-1.15 -I m4
configure.ac:499: warning: macro 'AM_PATH_GPGME' not found in library
configure.ac:269: warning: gl_LIMITS_H is m4_require'd but not m4_defun'd
m4/gnulib-comp.m4:316: gl_INIT is expanded from...
configure.ac:269: the top level
configure.ac:269: warning: gl_LIMITS_H is m4_require'd but not m4_defun'd
m4/gnulib-comp.m4:316: gl_INIT is expanded from...
configure.ac:269: the top level
cd . && /bin/bash /home/debian/asuswrt-merlin-374.43_2-update/release/src/router/wget/build-aux/missing automake-1.15 --gnu
configure.ac:269: warning: gl_LIMITS_H is m4_require'd but not m4_defun'd
m4/gnulib-comp.m4:316: gl_INIT is expanded from...
configure.ac:269: the top level
configure.ac:785: error: required file 'tests/certs/interca.conf.in' not found
configure.ac:785: error: required file 'tests/certs/rootca.conf.in' not found
parallel-tests: error: required file 'build-aux/test-driver' not found
parallel-tests: 'automake --add-missing' can install 'test-driver'
Makefile:1422: recipe for target 'Makefile.in' failed
make[4]: *** [Makefile.in] Error 1
make[4]: Leaving directory '/home/debian/asuswrt-merlin-374.43_2-update/release/src/router/wget'
Makefile:3614: recipe for target 'wget' failed
make[3]: *** [wget] Error 2
make[3]: Leaving directory '/home/debian/asuswrt-merlin-374.43_2-update/release/src/router'
Makefile:185: recipe for target 'all' failed
make[2]: *** [all] Error 2
make[2]: Leaving directory '/home/debian/asuswrt-merlin-374.43_2-update/release/src-rt'
Makefile:2549: recipe for target 'bin' failed
make[1]: *** [bin] Error 2
make[1]: Leaving directory '/home/debian/asuswrt-merlin-374.43_2-update/release/src-rt'
Makefile:2619: recipe for target 'rt-n16' failed
make: *** [rt-n16] Error 2

 

[keeka]

I have a slightly different setup (I don't use individual client certs), but I just connected/disconnected several times in a row without a problem. There was no change in the VPN server between 33E7 and 34E3. I doubt that dnsmasq is playing into it.

One thing you might try since you are running an N66. Backup your jffs on 33E7. Then when you move to 34E3, reformat your jffs space and restore the backup from 33E7. (The jffs space on the N66 is allocated from space leftover after the firmware is loaded and a change in the firmware size can corrupt jffs).

Thanks John. So I downgraded firmware, disabled jffs, upgraded firmware to 34E3. Then enabled/formattted jffs and copied my custom dnsmasq config plus openvpn certs to the newly formatted jffs.

Initial connection is again fine. But subsequent openvpn sessions do not succeed.

Second attempt gets as far as:

openvpn[615]: <!-- external client IP -->:42821 TLS: Initial packet from [AF_INET]<!-- external client IP -->:42821, sid=11d18898 1c86f353
openvpn[615]: <!-- external client IP -->:42821 VERIFY OK: depth=1, <!--CA DN-->
openvpn[615]: <!-- external client IP -->:42821 VERIFY OK: depth=0, CN=client1
openvpn[615]: <!-- external client IP -->:42821 peer info: IV_VER=2.5_master
openvpn[615]: <!-- external client IP -->:42821 peer info: IV_PLAT=android
openvpn[615]: <!-- external client IP -->:42821 peer info: IV_PROTO=2
openvpn[615]: <!-- external client IP -->:42821 peer info: IV_NCP=2
openvpn[615]: <!-- external client IP -->:42821 peer info: IV_LZ4=1
openvpn[615]: <!-- external client IP -->:42821 peer info: IV_LZ4v2=1
openvpn[615]: <!-- external client IP -->:42821 peer info: IV_LZO=1
openvpn[615]: <!-- external client IP -->:42821 peer info: IV_COMP_STUB=1
openvpn[615]: <!-- external client IP -->:42821 peer info: IV_COMP_STUBv2=1
openvpn[615]: <!-- external client IP -->:42821 peer info: IV_TCPNL=1

Subsequent attempts then result in no more entries in the router's log and client's (android) vpn log doesn't progress beyond AF_INET...

I have a few non-default vpn server options (subnet, port and push a custom DHCP DNS):

daemon
topology subnet
server 192.168.10.0 255.255.255.0
local <!--external server ip-->
proto udp
port 4317
dev tun21
ncp-ciphers AES-128-GCM:AES-256-GCM:AES-128-CBC:AES-256-CBC
cipher AES-256-CBC
auth SHA256
comp-lzo adaptive
keepalive 15 60
verb 3
push "route 192.168.0.0 255.255.255.0"
duplicate-cn
push "redirect-gateway def1"
plugin /usr/lib/openvpn-plugin-auth-pam.so openvpn
duplicate-cn
ca ca.crt
dh dh.pem
cert server.crt
key server.key
status-version 2
status status 10

push "dhcp-option DNS 192.168.0.35"

I also have a static route defined for 192.168.250.0/24.


This all works 100% reliably on 33E7 and again when I downgrade from 34E3. Incidentally I don't think the jffs got corrupted going from 33E7 to 34E3.

Which diagnostic commands might reveal the differences in firewall/routing/vpn state between the two firmwares?

Thanks.

 

[n00b]

Is there anyway to log web history like the feature new ASUS Routers have? I would like to log and sort websites visited by devices, I tried opendns but it can't tell what device requests what URL.

 

[john9527]

@ColinTaylor

Continued poking at DoT, and still can't recreate the switching you were seeing. But here are a couple of things I learned.

• The loglevel=7 is working properly and does capture error events (I injected errors and they showed up properly in the log)
• The way ordered works, is as I suspected. Once a switch is made due to an error, it will stay on the next server until that server has an error. From the getdnsapi man https://www.getdnsapi.net/documentation/manpages/stubby/
  

  round_robin_upstreams 0 or 1
  If 1, round robin queries across all the configured upstream servers. Without this option stubby will use each upstream server sequentially until it becomes unavailable and then move on to use the next.

• One issue I see that I need to think about, is that stubby can start before the WAN is fully up (or when the WAN is restarted when changing the stubby options). When this happens, stubby starts logging errors against the selected servers until the WAN finishes coming up. What server it lands on when the WAN is 'restored' is a matter of chance.

Of course, most of this is not applicable if you select only one server.

 

[ColinTaylor]

@john9527 Thanks for the extra information.

I've been experimenting with it today, but as it can go for hours without switching at all it's taking a long time to come to any conclusions. This afternoon it switched a few times, but it's been stable for the past 2 hours.

Given the pattern of activity (even though it's rather vague) my gut feeling is that it's an issue with the upstream servers not responding quickly enough (possibly due to load). I suspect 9.9.9.9 is much worse than 1.1.1.1 in this respect.

This morning I tried changing the idle timeout from 10s to 1s and didn't experience any switching at all, but I only ran it like that for an hour or so so it's not conclusive. I'll keep looking at it and keep you updated with anything I find.

 

[ColinTaylor]

@john9527 Having changed back to using an idle timeout of 1s I've not seen any server switches. Looking at the log I noticed that "Conn_shuts=" was not changing whereas before it was incrementing on almost every connection.

That led me to this which exactly describes my problem. So I'm not sure there's a satisfactory solution at the moment.