r38159 already? 2019's first!

Post new topic   Reply to topic    DD-WRT Forum Forum Index -> Marvell MVEBU based Hardware (WRT1900AC etc.)
Author Message
scar1943
DD-WRT User


Joined: 10 Nov 2018
Posts: 334
Location: South Carolina

PostPosted: Thu Jan 03, 2019 1:33    Post subject: r38159 already? 2019's first! Reply with quote
Folks,

Is something changing? What would the reason for updates so close together? 38159 is the first for 2019.

WRT3200ACM V1 r38159 Firefox 64.0 (64-bit) webflash

OpenVPN CLIENT works fine (nordvpn server)
5GHz wpa2 CCMP-128 (AES)working fine 20MHz Mixed
2.4GHz wpa2 CCMP-128 (AES)working fine 20MHz Mixed
NAS via USB Samba also working fine
Sponsor
DS12
DD-WRT Novice


Joined: 01 Jan 2019
Posts: 1

PostPosted: Thu Jan 03, 2019 4:06    Post subject: Reply with quote
ddwrt-linksys-wrt1200acv2-webflash - r38159 - Edge (x64)
flashed using no reset option

**edit: over 48 hours running

5GHz wpa2 CCMP-128 (AES) - working fine - 40MHz Channel 149/Upper, AC/N-mixed; Short Preamble, Short GI and WMM Support = enabled; ACK Timing = 0.
**5GHz wpa2 CCMP-128 (AES) - working fine - 80MHz Channel 149/Upper+6, AC/N-mixed; Short Preamble, Short GI and WMM Support = enabled; ACK Timing = 0.
not using 2.4 - disabled for now and route MoCA device through the 1200AC for appliances that would run on my 2.4

DNSMasq, local DNS, Access restrictions and QoS seem fine
**Test with OpenVPN - set up/working fine
**Test with Single User Beamforming=enabled - devices cannot find network (Maybe something I am doing wrong idk, enabled=no connection/disabled=good connection - AC only and AC/N-mixed).

** thought I had this solved and maybe something in my config, anyways it's back. Maybe someone could point me in the right direction.
Jan 6 21:54:33 DD-WRT daemon.err httpd[2352]: Request Error Code 401: Authorization required. please note that the default username is "root" in all newer releases

Connections seem fine/responsive/fast (test device=Galaxy S7; in room down hallway - 11 meters/35 feet)
Wide HT40 - TxRate 300M/RxRate 24M, SNR 35,
**Same test with VHT80 - TxRate 866M/RxRate 24M, SNR 39


Last edited by DS12 on Mon Jan 07, 2019 1:49; edited 13 times in total
SurprisedItWorks
DD-WRT Guru


Joined: 04 Aug 2018
Posts: 1063
Location: Appalachian mountains, USA

PostPosted: Sat Jan 05, 2019 20:08    Post subject: Reply with quote
Factory flash from linksys 2.0.2.188405 went without a hitch to a new WRT1900ACSv2. For now 2.4 GHz is Mixed 20 GHz and 5 GHz is AC/N-Mixed 80 MHz using ch 149UU with Short Preamble and Single User Beamforming on both. Basic stuff, but some people have trouble with it. Also I'm set up with two DNSCrypt DNS resolvers using Startup commands. One is Quad9 DNS, which is not in our resolvers file, but putting in the parameters on the dnscrypt-proxy command line worked fine.

I'll edit this note in a few days when I've added the fancier config stuff and had a little more experience. Meanwhile I encourage editing of this thread's subject line. By the number of responses/views, I suspect many people are not realizing it's a build thread.

I noticed a couple of problems I saw in earlier versions seem fixed. I can run a single DNSCrypt resolver now using the GUI without the ntpclient race problem. And saving Commands with Save Startup no longer seems to do a semi-boot that confuses the system and forces me to do a real reboot. Now it's just a save. I also see that Wireless Network Mode has a Disabled option. Never noticed that before.

_________________
Five WRT1900ACSv2's on 42926, 44048.
VLANs, VAPs, NAS, client-mode travel router, OpenVPN client (AirVPN), DDNS, wireguard servers, wireguard clients (AzireVPN), two DNSCrypt DNS providers (incl Quad9) via OpenVPN/wireguard clients.
DaveI
DD-WRT User


Joined: 06 Jul 2009
Posts: 335

PostPosted: Sat Jan 05, 2019 21:11    Post subject: Reply with quote
I would greatly appreciate if you describe the steps necessary to add Quad9 as a DNSCrypt DNS resolver. I've been using Quad9 since last fall but was uncertain how to do the DNSCrypt since they're not in DD's list.


SurprisedItWorks wrote:
Also I'm set up with two DNSCrypt DNS resolvers using Startup commands. One is Quad9 DNS, which is not in our resolvers file, but putting in the parameters on the dnscrypt-proxy command line worked fine.

_________________
WRT1900ACSv2
Yemble
DD-WRT Guru


Joined: 17 Feb 2010
Posts: 613
Location: Yorkshire (GOC)

PostPosted: Sun Jan 06, 2019 13:57    Post subject: Reply with quote
Used r38159 successfully as first flash from stock of a brand new WRT32X Very Happy

Note that a few manual reboots are required when upgrading from stock Rolling Eyes

_________________
Linksys WRT32X v1 - r45493
Linksys WRT1900AC v1 - r45493
TP-Link Archer C9 v1 - r45493
Firmware: ftp://ftp.dd-wrt.com/betas/2021/
trandma
DD-WRT Novice


Joined: 18 Jul 2017
Posts: 7

PostPosted: Sun Jan 06, 2019 17:10    Post subject: Reply with quote
WRT3200ACM, installed r38159 from stock.

In previous 3 versions I tried OpenVPN worked only partially. Connection was created and VPN worked but DNS was somehow messed up so that some sites did not get resolved (eg. netflix.com). I went through the entire troubleshooting list with Express VPN support trying different settings and we couldn't get it to work.

The latest version r38159 however worked. OpenVPN seems to work fine. However I have encountered the following problems:

1. OpenVPN policy based routing does not seem to work. When I set it up, the connections not going through the VPN work fine, but the stuff that should be going through the VPN just errors out on me. I am too dumb and too exhausted to do another troubleshooting marathon with ExpressNVPn support to try and solve this, so I am just calling it broken for now.

2. Wifi does not seem to work for me. I get the networks configured like I did with earlier versions where I did not use OpenVPN and I can try to connect to them on my android phone.. but neither 2.4 nor 5Ghz connects successfully. I dont know how to troubleshoot this so I will just be waiting for a new version.. or I dont know... maybe just get a new router. Getting real tired of playing with this WRT3200ACM. I was hoping to just set it up and forget it but it is turning up to be so much work...
SurprisedItWorks
DD-WRT Guru


Joined: 04 Aug 2018
Posts: 1063
Location: Appalachian mountains, USA

PostPosted: Sun Jan 06, 2019 17:18    Post subject: Reply with quote
DaveI wrote:
I would greatly appreciate if you describe the steps necessary to add Quad9 as a DNSCrypt DNS resolver. I've been using Quad9 since last fall but was uncertain how to do the DNSCrypt since they're not in DD's list.


Updated 18 Dec 2020 to clarify, to update URLs, to deal with newer dd-wrt builds, and to suggest a tcpdump test.

So, how to use Quad9 (https://quad9.net) via DNSCrypt. Please excuse me if I get a bit pedantic here, but I'd like to also make this available for those less experienced than you are.

First, in GUI>Services>Services>ServicesManagement>DNSMasq, do NOT enable Encrypt DNS, as doing so would start up a dnscrypt-proxy process tied to a resolver from the drop-down menu, which does not contain Quad9. Enable other options as you choose, as those choices are independent from what we are doing here.
  • Aside: Quad9 does support DNSSEC, but DNSSEC is only useful if the website you are visiting is equipped to support it also. Check that out for sites important to you here: https://dnssec-analyzer.verisignlabs.com/. Also note that dnsmasq will only use DNSSEC if every configured DNS provider supports it. If you add Adguard DNS as a second provider like I do below, you can no longer use DNSSEC, as Adguard does not support it.
Then in Additional DNSMasq Options below those buttons, enter this.
Code:
no-resolv
server=127.0.0.1#30
Here no-resolv (no "e") prevents DNSMasq from falling back to resolvers provided by your ISP and (for builds from late 2019 or later) through your VPN provider through your OpenVPN client. You can omit no-resolv and enable Query DNS in Strict Order if you want to fall back to accessing those resolvers on an unencrypted basis if Quad9 is taking too long to respond. The important line is the server= line, which tells DNSMasq to use loopback IP 127.0.0.1, port 30, as its DNS resolver. Note that where other software generally uses a colon to specify a port, DNSMasq uses the pound sign. Save the changes but do not Apply, as at this point there is nothing on that server for DNSMasq to find.

Now go to GUI>Administration>Commands. If you already have something in the Startup Commands window, hit its Edit button to move it to the Commands window at the top. Otherwise proceed directly to the Commands window and add this:
Code:
( Started=/tmp/root/StartedDNSCrypt; [[ -f $Started ]] && exit || touch $Started
  dnscrypt-proxy -d -S -a 127.0.0.1:30 -r 9.9.9.9:8443 -N 2.dnscrypt-cert.quad9.net -k \
  67c8:47b8:c875:8cd1:2024:5543:be75:6746:df34:df1d:84c0:0b8c:4703:68df:821d:863e
)
The first and last lines (together) are optional and put all the action inside a subshell that can be exited before starting dnscrypt-proxy if this isn't the first time the code has been run. That code may be totally unnecessary, but including it is certainly harmless.

Click Save Startup to save to Startup Commands. The next time you boot, DNSMasq should be using DNSCrypt, which should in turn be using Quad9 as its DNS resolver.

The quick test, per Quad9's suggestion, is to visit dnsleaktest.com and use the extended test. It should show servers with ISP WoodyNet. You can also visit ipleak.net and notice the DNS Addresses section, which should show one or two (or more?) servers in a common location. I'm US-based and so far have seen servers in Illinois, Georgia, Virginia, and California in different experiments. Also, in the CLI you can do ps | grep dns and should see a dnsmasq process and a dnscrypt-proxy process, with the latter mirroring the above dnscrypt-proxy command (if your terminal is wide enough).

If you use the OpenVPN client with PBR to restrict it to subnet X, you have the option of going to GUI>Setup>Networking and finding that subnet's Optional DNS Target field and replacing your VPN provider's DNS server's IP with subnet X's gateway IP 192.168.X.1 in order to tell subnet X's clients to use dnsmasq, and hence Quad9, for DNS queries (to "leak" to) Quad9's DNS servers when on subnet X. I do this to get Quad9's malware filtering, which my VPN provider's DNS server does not provide. If the subnet is for an unbridged wifi interface or virtual interface, you can instead set this in GUI>Wireless>BasicSettings in the section for that interface after checking Advanced Settings there and looking down near the end for Optional DNS Target. (I used the latter approach, so I'm only assuming you can change it under Networking.)

If you want a backup DNSCrypt server from our built-in list to cover you in the unlikely case that Quad9 is ever unavailable (which I gather is extremely unlikely) or the more likely case that it's having a slow moment, enable Query DNS in Strict Order, add a server=127.0.0.2#30 just before server=127.0.0.1#30 in the Additional DNSMasq Options above, and in Startup Commands add, say to use AdGuard DNS (malware filtering plus ad filtering as discussed at https://adguard.com/en/adguard-dns/overview.html),
Code:
 dnscrypt-proxy -d -S -a 127.0.0.2:30 \
  -R adguard-dns-ns1 -L /etc/dnscrypt/dnscrypt-resolvers.csv
either before or after the earlier call to dnscrypt-proxy (but stay inside the parens). Order matters only for the server= lines, because DNSMasq apparently uses the last one first. Where I put adguard-dns-ns1 here, you can use adguard-dns-ns2 instead. In builds from mid-2019 or earlier, you'll need just adguard-dns. The general rule is you can use anything from the first of the comma-separated columns in dd-wrt's dnscrypt-server database file /etc/dnscrypt/dnscrypt-resolvers.csv. These values correspond in a fairly obvious way to the items in the Encrypt DNS (which we are not using) drop-down menu, and in the CLI the command awk -F, '{print $1}' dnscrypt-resolvers.csv will list them. Choose any one you like. Note that AdGuard has "family" options available there. Of course you can use this abbreviated form of the dnscrypt-proxy call in both places if the DNSCrypt providers you want are in the database file.

A decent test to make sure things are working, in this Quad9 + Adguard case, is to run tcpdump -i eth0 | grep -Ei 'quad9|adguard' in the CLI. Here eth0 is the WAN interface for the Linksys/Marvell routers. For other routers do ip route | awk '/^default/{print $NF}' to identify your WAN interface and use that instead. This tcpdump command will dump a line to the terminal for each packet going to or from quad9 or adguard sites. If needed, visit dnsleaktest.com in a browser and run the Standard Test to force some DNS action. When done with all this, control-C to exit the tcpdump.

Background and References

The /etc/dnscrypt/dnscrypt-resolvers.csv file just above appears to match the one at https://svn.dd-wrt.com/browser/src/router/dnscrypt/dnscrypt-resolvers.csv, with each line specifying a resolver. This format has been superceded in the dnscrypt community with a new master dnscrypt server list, with resolver parameters encoded into a "stamp" format, at https://github.com/DNSCrypt/dnscrypt-resolvers/blob/master/v2/public-resolvers.md. The postings at https://dnscrypt.info are noteworthy, especially the checklists of features of DNSCrypt, DoH, DoT, etc. in the FAQ tab along with a tool in the DNS STAMPS tab that you can use to decode stamps to get the three key parameters used in our Quad9 call to dnscrypt-proxy following -r, -N, and -k. You can add the colons to the public key by hand or run it through sed -e 's/..../&:/g;s/:$//' to do it if you are like me and are linux based and either don't trust your fingers near a keyboard or want to do it for lots of stamps. The master dnscrypt server list above seems to contain many DNS resolvers not in our dd-wrt list, so we may have other options to experiment with as well.

Quad9 in particular announced their DNSCrypt support at blog post https://www.quad9.net/dnscryptlive/. There they link at the end to file quad9-resolvers.md, which contains the DNS-resolver stamp for dnscrypt-ip4-filter-pri, the option I configured above. That stamp is also in the master dnscrypt server list above. I verified that they were identical as of a few days before this (original, unedited) post. That Quad9 blog post also says their public key can be obtained with command dig @9.9.9.9 2.dnscrypt-cert.quad9.net txt, which I tested in linux to verify that the public key is as above in the dnscrypt-proxy call.

_________________
Five WRT1900ACSv2's on 42926, 44048.
VLANs, VAPs, NAS, client-mode travel router, OpenVPN client (AirVPN), DDNS, wireguard servers, wireguard clients (AzireVPN), two DNSCrypt DNS providers (incl Quad9) via OpenVPN/wireguard clients.


Last edited by SurprisedItWorks on Fri Dec 18, 2020 16:45; edited 4 times in total
MLandi
DD-WRT User


Joined: 04 Dec 2007
Posts: 340

PostPosted: Sun Jan 06, 2019 19:50    Post subject: Reply with quote
Flashed from the GUI. No issues at all and everything running properly.
_________________
Netgear R9000 X10
DD-WRT v3.0-r45563 std (01/24/21)
Gateway, AP, DNSMasq
IPv4 & IPv6 (Prefix Delegation)
CloudFlare
QoS: HFSC w/CAKE & ACK, SYN, FIN & RST
Static Leases & DHCP
2.4GHz: 10 + 6 (2457 MHz HT40), ACK Timing 450
5GHz: 100 + 106 (5500 MHz VHT80), ACK Timing 450
Xfinity 1Gbps(max)/42Mbps
DaveI
DD-WRT User


Joined: 06 Jul 2009
Posts: 335

PostPosted: Sun Jan 06, 2019 20:23    Post subject: Reply with quote
SurprisedItWorks,

Thank you very much for this. Excellent work.

DaveI

_________________
WRT1900ACSv2
Monza
DD-WRT User


Joined: 01 Jul 2018
Posts: 229

PostPosted: Mon Jan 07, 2019 14:32    Post subject: Reply with quote
Updated WRT1200AC v1 from r37837 to r38159 with no reset, no issues using Firefox 64.0. Up-time 2+ hours. Usual OpenVPN client yellows in syslog but one of the cleanest syslogs I've had in a while. OpenVPN client and DNSMasq working as expected. Browser seems to have a faster response time site to site??

Kernel Version Linux 4.9.148 #691 SMP Wed Jan 2 01:54:17 CET 2019 armv7l

Previous two releases had good wired connections but would not allow connection to any of my wireless devices on 2.4 or 5 GHz due to "Authentication Error". This release (r38159) connects immediately.

**** 1/9/19 Reverted to r37837 after several OpenVPN client disconnects over a 48 hour period. Worked well for me other than unstable OpenVPN client.
Display posts from previous:    Page 1 of 1
Post new topic   Reply to topic    DD-WRT Forum Forum Index -> Marvell MVEBU based Hardware (WRT1900AC etc.) All times are GMT

Navigation

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You cannot download files in this forum