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

[JohnSmith]

Had a spare RT-AC66U A1 to make into another access point, so I wanted to test John's Fork. Had Merlin's 380.70 FW on it, setup as a spare router, so powered off, held in the reset button, and powered the unit back on to reinitialize. Ran the ASUS Firmware restoration tool, to install John's Fork 36E4. Initially could not get into the Web GUI via the defaults, but then I thought maybe the unit still had Merlin's 380.70 settings that I had it setup for as a spare router being used in the fork, sure enough it did. Logged in with that, ran a factory reset, and installed the unit as an AP.

Tested and all working well now!

 

[john9527]

I suppose no one else is getting the odd behavoir of the SSH button not "sticking", as I described in my post yesterday

post the output of

nvram show | grep sshd_

before and after making the enable change

 

[jsbeddow]

Ok, I will post that this evening. Thanks.

 

[john9527]

Ok, I will post that this evening. Thanks.

Another thought....if you are using key auth, double check that your key is of the right format (it has to be type ssh-rsa) and was entered correctly.

 

[john9527]

Any advice please?

The original problem (not being able to log in more that once to the OpenVPN server with usrname/password auth) was fixed in 36E4. Unfortunately, I inadvertently broke the non-username/password case, such that you need to manually add a 'script-security 2' statement to the custom config section.

If you wait a day, I'll be posting an update which fixes that second case (was waiting to see if anything else was reported)

 

[Deleted member 59835]

Hi John,

Thank you for all the work done!

Updated my RT-N66U to the latest build a couple of days ago and everything works fine!

 

[Deleted member 27741]

Hello guys- I feel like I am getting a lot (when I say a lot I mean I can get the error once every several minutes, or I can get the error to occur if I run through some bookmarks quickly) of DNS site not found errors. Strange thing is a reload of the webpage usually gets the site up again. I have tried multiple DoT servers and the problem seems pretty... random (happens with different pages at different times no rhyme or reason I can make out) and happens with all the servers I've tried. Cloudflare, Quad 9, Cleanbrowsing. Happens if 1 or more than 1 DoT server are selected. I don't get the error if I disable DoT and just go with 8.8.8.8 8.8.4.4. Is there anything I can look for in logs to find out the potential source of these DNS errors? Anyone else have the same issue?

 

[ColinTaylor]

Hello guys- I feel like I am getting a lot (when I say a lot I mean I can get the error once every several minutes, or I can get the error to occur if I run through some bookmarks quickly) of DNS site not found errors. Strange thing is a reload of the webpage usually gets the site up again. I have tried multiple DoT servers and the problem seems pretty... random (happens with different pages at different times no rhyme or reason I can make out) and happens with all the servers I've tried. Cloudflare, Quad 9, Cleanbrowsing. Happens if 1 or more than 1 DoT server are selected. I don't get the error if I disable DoT and just go with 8.8.8.8 8.8.4.4. Is there anything I can look for in logs to find out the potential source of these DNS errors? Anyone else have the same issue?

I experienced the same problem to a lesser extent using the UK Quad 9 DoT servers. For me the Cloudflare servers were much more reliable, but even they had the occasional problem. Using any of the other servers was a complete waste of time. Even though the router's local DNS cache can hide a lot of the problems with the upstream servers there's only so much it can do.

So given the poor reliability of the servers and increased latency times (compared to my ISP's non-DoT servers) I've stopped using DoT for now. Maybe one day if DoT becomes "mainstream" they'll get to a usable state, but by then we'll probably be using DoH.

You can look at the log file at /var/tmp/stubby/stubby.log but there's usually not a lot there.

 

[Bob.Dig]

No problems here

 

[john9527]

I don't get the error if I disable DoT and just go with 8.8.8.8 8.8.4.4. Is there anything I can look for in logs to find out the potential source of these DNS errors?

How are your ping times to the DoT servers vs others.....
For me...
My local ISP servers = 10-15ms
Google = 25-30ms
Cloudflare/Quad9 = 40-45ms

 

[wollyka]

I switched from Merlin to 36E4 and everything seems to work fine.
Thank you John.

PS: I hope the new DDNS Feature will make it to this fork, I could really use it cause I am double NATed.

Yes, i second that, this new DDNS feature is great for us poor people behind double NAT.

 

[john9527]

PS: I hope the new DDNS Feature will make it to this fork, I could really use it cause I am double NATed.

Merlin is still tweaking the new DDNS in his beta.....once he makes a final release I'll take a look at porting it over.

 

[Deleted member 27741]

Colin- I too have foregone DoT for the time being other than testing more or less. It was pretty unreliable for me, in the sense that google "vanilla" dns is completely reliable.

John-
Google 45 ms
cloudflare 22 ms
quad9 77ms

That ping on cloudflare makes me think it should perform great, but it doesn't in terms of latency and reliability. I was using cloudflare secondary (thinking maybe it had less usage) but now I will see how cloudflare primary works for awhile.

Edit- I just put DoT on cloudflare primary and it is still a little wonky. Sometimes sites like amazon.com will pop up as not found, so it's not something to do with obscure sites or anything.

It usually borks out when I try to visit a bunch of bookmarks quickly (as a test), that sort of thing. Perhaps DoT is not as robust as vanilla DNS for those kind of shenanigans?

Here is a DNS over TLS log if it is informative for anyone.

[22:23:52.905226] STUBBY: Read config from file /etc/stubby.yml
[22:23:57.898659] STUBBY: 1.1.1.1 : Conn opened: TLS - Strict Profile
[22:23:58.065067] STUBBY: 1.1.1.1 : Verify passed : TLS
[22:24:00.217068] STUBBY: 1.1.1.1 : Conn closed: TLS - Resps= 1, Timeouts = 0, Curr_auth =Success, Keepaliv$
[22:24:00.217418] STUBBY: 1.1.1.1 : Upstream : TLS - Resps= 1, Timeouts = 0, Best_auth =Success
[22:24:00.217704] STUBBY: 1.1.1.1 : Upstream : TLS - Conns= 1, Conn_fails= 0, Conn_shuts= 0, Backoffs$
[22:24:10.427966] STUBBY: 1.1.1.1 : Conn opened: TLS - Strict Profile
[22:24:12.437590] STUBBY: 1.1.1.1 : Conn closed: TLS - *Failure*
[22:24:12.437844] STUBBY: *FAILURE* no valid transports or upstreams available!
[22:24:12.438207] STUBBY: 1.1.1.1 : Conn closed: TLS - *Failure*
[22:24:12.438453] STUBBY: *FAILURE* no valid transports or upstreams available!
[22:24:12.438804] STUBBY: 1.1.1.1 : Conn closed: TLS - Resps= 0, Timeouts = 1, Curr_auth = None, Keepaliv$
[22:24:12.439166] STUBBY: 1.1.1.1 : Upstream : TLS - Resps= 1, Timeouts = 1, Best_auth =Success
[22:24:12.439450] STUBBY: 1.1.1.1 : Upstream : TLS - Conns= 1, Conn_fails= 0, Conn_shuts= 1, Backoffs$
[22:24:12.741484] STUBBY: 1.1.1.1 : Conn opened: TLS - Strict Profile
[22:24:12.908410] STUBBY: 1.1.1.1 : Verify passed : TLS
[22:24:17.896998] STUBBY: 1.1.1.1 : Conn closed: TLS - Resps= 8, Timeouts = 0, Curr_auth =Success, Keepaliv$
[22:24:17.897349] STUBBY: 1.1.1.1 : Upstream : TLS - Resps= 9, Timeouts = 1, Best_auth =Success
[22:24:17.897634] STUBBY: 1.1.1.1 : Upstream : TLS - Conns= 2, Conn_fails= 0, Conn_shuts= 1, Backoffs$
[22:24:19.408145] STUBBY: 1.1.1.1 : Conn opened: TLS - Strict Profile
[22:24:21.417435] STUBBY: 1.1.1.1 : Conn closed: TLS - *Failure*
[22:24:21.417690] STUBBY: *FAILURE* no valid transports or upstreams available!
[22:24:21.418075] STUBBY: 1.1.1.1 : Conn closed: TLS - Resps= 0, Timeouts = 1, Curr_auth = None, Keepaliv$
[22:24:21.418440] STUBBY: 1.1.1.1 : Upstream : TLS - Resps= 9, Timeouts = 2, Best_auth =Success
[22:24:21.418728] STUBBY: 1.1.1.1 : Upstream : TLS - Conns= 2, Conn_fails= 0, Conn_shuts= 2, Backoffs$
[22:24:30.132390] STUBBY: 1.1.1.1 : Conn opened: TLS - Strict Profile
[22:24:30.307196] STUBBY: 1.1.1.1 : Verify passed : TLS
[22:24:32.337120] STUBBY: 1.1.1.1 : Conn closed: TLS - Resps= 1, Timeouts = 0, Curr_auth =Success, Keepaliv$
[22:24:32.337471] STUBBY: 1.1.1.1 : Upstream : TLS - Resps= 10, Timeouts = 2, Best_auth =Success
[22:24:32.337756] STUBBY: 1.1.1.1 : Upstream : TLS - Conns= 3, Conn_fails= 0, Conn_shuts= 2, Backoffs$
[22:24:34.587425] STUBBY: 1.1.1.1 : Conn opened: TLS - Strict Profile
[22:24:37.617003] STUBBY: 1.1.1.1 : Conn closed: TLS - Resps= 14, Timeouts = 0, Curr_auth =Success, Keepaliv$
[22:24:37.617353] STUBBY: 1.1.1.1 : Upstream : TLS - Resps= 24, Timeouts = 2, Best_auth =Success
[22:24:37.617665] STUBBY: 1.1.1.1 : Upstream : TLS - Conns= 4, Conn_fails= 0, Conn_shuts= 2, Backoffs$
[22:25:14.190924] STUBBY: 1.1.1.1 : Conn opened: TLS - Strict Profile
[22:25:17.656993] STUBBY: 1.1.1.1 : Conn closed: TLS - Resps= 3, Timeouts = 0, Curr_auth =Success, Keepaliv$
[22:25:17.657380] STUBBY: 1.1.1.1 : Upstream : TLS - Resps= 27, Timeouts = 2, Best_auth =Success
[22:25:17.657695] STUBBY: 1.1.1.1 : Upstream : TLS - Conns= 5, Conn_fails= 0, Conn_shuts= 2, Backoffs$
[22:25:20.183836] STUBBY: 1.1.1.1 : Conn opened: TLS - Strict Profile
[22:25:22.187450] STUBBY: 1.1.1.1 : Conn closed: TLS - *Failure*
[22:25:22.187730] STUBBY: *FAILURE* no valid transports or upstreams available!
[22:25:22.188113] STUBBY: 1.1.1.1 : Conn closed: TLS - *Failure*
[22:25:22.188385] STUBBY: *FAILURE* no valid transports or upstreams available!
[22:25:22.188746] STUBBY: 1.1.1.1 : Conn closed: TLS - Resps= 0, Timeouts = 1, Curr_auth = None, Keepaliv$
[22:25:22.189147] STUBBY: 1.1.1.1 : Upstream : TLS - Resps= 27, Timeouts = 3, Best_auth =Success
[22:25:22.189461] STUBBY: 1.1.1.1 : Upstream : TLS - Conns= 5, Conn_fails= 0, Conn_shuts= 3, Backoffs$
[22:25:27.071408] STUBBY: 1.1.1.1 : Conn opened: TLS - Strict Profile
[22:25:28.282491] STUBBY: 1.1.1.1 : Verify passed : TLS
[22:25:30.344718] STUBBY: 1.1.1.1 : Conn closed: TLS - Resps= 3, Timeouts = 0, Curr_auth =Success, Keepaliv$
[22:25:30.345105] STUBBY: 1.1.1.1 : Upstream : TLS - Resps= 30, Timeouts = 3, Best_auth =Success
[22:25:30.345418] STUBBY: 1.1.1.1 : Upstream : TLS - Conns= 6, Conn_fails= 0, Conn_shuts= 3, Backoffs$
[22:25:36.729736] STUBBY: 1.1.1.1 : Conn opened: TLS - Strict Profile
[22:25:38.735173] STUBBY: 1.1.1.1 : Conn closed: TLS - *Failure*
[22:25:38.735453] STUBBY: *FAILURE* no valid transports or upstreams available!
[22:25:38.735839] STUBBY: 1.1.1.1 : Conn closed: TLS - Resps= 0, Timeouts = 1, Curr_auth = None, Keepaliv$

 

[john9527]

It usually borks out when I try to visit a bunch of bookmarks quickly (as a test), that sort of thing. Perhaps DoT is not as robust as vanilla DNS for those kind of shenanigans?

Just thinking out loud.....I wouldn't think this would be the case, but I wonder if the older MIPS processor is having trouble keeping up with the TLS encryption/decryption. As a test, try this /jffs/scripts/stubby.postconf

#!/bin/sh
CONFIG=$1
source /usr/sbin/helper.sh

pc_replace "timeout: 2000" "timeout: 5000" $CONFIG

exit

 

[jrmwvu04]

I’ve been using DoT with cloudflare for a while with no problems whatsoever. I think how well it works depends on where you are and how well the servers you end up with perform.

 

[ColinTaylor]

It usually borks out when I try to visit a bunch of bookmarks quickly (as a test), that sort of thing. Perhaps DoT is not as robust as vanilla DNS for those kind of shenanigans?

By switching to the different bookmarks a higher number of DNS requests are forwarded upstream because they cannot be answered from the local cache (of the router, PC or browser). This is why I said the DNS cache can hide a lot of the problems. So what you're doing is exposing the underlying problem more than would be the case when browsing normally.

 

[bbunge]

I'm back to 36E4 after trying the Merlin 384.7 beta with Stubby on Entware. For my DSL connection I need to set DHCP query frequency to Agressive Mode (my ISP renews DHCP every 15 minutes!), DNSSEC un check Strict DNSSEC enforcement, DoT set to Quad9 and Quad9 Alt round robin. Am getting a few errors in stubby.log ([00:42:43.466439] STUBBY: 9.9.9.9 : Upstream : !Backing off TLS on this upstream - Will retry again in 2s at Wed Oct 3 00:42:45 2018) but have not noticed any problems surfing. Have also used Cloudflare and Cleanbrowsing secure with no issues. Also running OpenVPN with the port set to non-default (connects/disconnects OK). RT-AC66U_B1

John, you mentioned a possible release in a day or so? Am making a 30 mile trip Thursday to upgrade two RT-AC68U's. Will the next release be ready by then?

 

[Deleted member 27741]

Colin- thanks for the info I thought it might be something like that. I am good at breaking things.

John- I am testing the stubby mod you posted and it's working 100% after five minutes of "stress testing." Will let you know how it goes after more testing, looking good though!

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

[15:11:00.959196] STUBBY: 1.1.1.1 : Conn closed: TLS - *Failure*
[15:11:00.959459] STUBBY: *FAILURE* no valid transports or upstreams available!
[15:11:00.959901] STUBBY: 1.1.1.1 : Conn closed: TLS - *Failure*
[15:11:00.960150] STUBBY: *FAILURE* no valid transports or upstreams available!
[15:11:00.960556] STUBBY: 1.1.1.1 : Conn closed: TLS - Resps= 0, Timeouts = 0, Curr_auth = None, Keepaliv$
[15:11:00.960924] STUBBY: 1.1.1.1 : Upstream : TLS - Resps= 5286, Timeouts = 0, Best_auth =Success
[15:11:00.961200] STUBBY: 1.1.1.1 : Upstream : TLS - Conns= 328, Conn_fails= 1, Conn_shuts= 0, Backoffs$
[15:11:04.421037] STUBBY: 1.1.1.1 : Conn opened: TLS - Strict Profile
[15:11:04.582052] STUBBY: 1.1.1.1 : Verify passed : TLS
[15:11:14.399198] STUBBY: 1.1.1.1 : Conn closed: TLS - Resps= 2, Timeouts = 0, Curr_auth =Success, Keepaliv$
[15:11:14.399555] STUBBY: 1.1.1.1 : Upstream : TLS - Resps= 5288, Timeouts = 0, Best_auth =Success
[15:11:14.399833] STUBBY: 1.1.1.1 : Upstream : TLS - Conns= 329, Conn_fails= 1, Conn_shuts= 0, Backoffs$
[15:13:23.560769] STUBBY: 1.1.1.1 : Conn opened: TLS - Strict Profile
[15:13:32.948728] STUBBY: 1.1.1.1 : Conn closed: TLS - Resps= 46, Timeouts = 0, Curr_auth =Success, Keepaliv$
[15:13:32.949078] STUBBY: 1.1.1.1 : Upstream : TLS - Resps= 5334, Timeouts = 0, Best_auth =Success
[15:13:32.949356] STUBBY: 1.1.1.1 : Upstream : TLS - Conns= 330, Conn_fails= 1, Conn_shuts= 0, Backoffs$
[15:14:13.873653] STUBBY: 1.1.1.1 : Conn opened: TLS - Strict Profile
[15:14:16.408751] STUBBY: 1.1.1.1 : Conn closed: TLS - *Failure*
[15:14:16.409031] STUBBY: *FAILURE* no valid transports or upstreams available!
[15:14:16.409468] STUBBY: 1.1.1.1 : Conn closed: TLS - *Failure*
[15:14:16.409733] STUBBY: *FAILURE* no valid transports or upstreams available!
[15:14:16.410139] STUBBY: 1.1.1.1 : Conn closed: TLS - *Failure*
[15:14:16.410405] STUBBY: *FAILURE* no valid transports or upstreams available!
[15:14:16.410788] STUBBY: 1.1.1.1 : Conn closed: TLS - *Failure*
[15:14:16.411053] STUBBY: *FAILURE* no valid transports or upstreams available!
[15:14:16.411433] STUBBY: 1.1.1.1 : Conn closed: TLS - *Failure*
[15:14:16.411696] STUBBY: *FAILURE* no valid transports or upstreams available!

 

[vx46hD]

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?

 

[dlandiss]

For me...
My local ISP servers = 10-15ms
Google = 25-30ms
Cloudflare/Quad9 = 40-45ms

A few DNS servers compared, attached