Davidc502- wrt1200ac wrt1900acx wrt3200acm wrt32x builds

DNSCrypt is to try and stop Man in the middle attacks, although the domain you requested is in plaintext, the rest of it is authenticated/checked.

In other words someone with a Raspberry pi pretending to be will fail to get anything as it will fail the check.

Read whats on https://www.dnscrypt.org/#about it will tell you all about how it works. If you want to be 100% safe use a VPN as well.

I thought what you were describing as dnssec which basically ensures the DNS server is who the DNS servers says it is. Also, as you described dnssec doesn't encrypt the payload so anyone can read what the DNS query and response from the DNS server.

Here is an example of a regular DNS query. It's in plaintext.

root@dc502wrt:~# tcpdump -nnvvi eth0 dst port 53
tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes
19:14:15.792152 IP (tos 0x0, ttl 63, id 3068, offset 0, flags [none], proto UDP (17), length 53)
    x.x.x.x.53686 > [udp sum ok] 58669+ A? cnn.com. (25)
19:14:15.813902 IP (tos 0x0, ttl 63, id 3073, offset 0, flags [none], proto UDP (17), length 53)
    x.x.x.x.41504 > [udp sum ok] 26914+ AAAA? cnn.com. (25)

Here is what is seen when using dnscrypt-proxy2

root@dc502wrt:~# tcpdump -nnvvi eth0 host or host
tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes
19:19:57.030576 IP (tos 0x0, ttl 64, id 33616, offset 0, flags [DF], proto TCP (6), length 145)
    x.x.x.x.52216 > Flags [P.], cksum 0xda00 (incorrect -> 0x7527), seq 2738809251:2738809356, ack 3690564401, win 1002, length 105
19:19:57.030855 IP (tos 0x0, ttl 64, id 33617, offset 0, flags [DF], proto TCP (6), length 139)
    x.x.x.x.52216 > Flags [P.], cksum 0xd9fa (incorrect -> 0x607c), seq 105:204, ack 1, win 1002, length 99
1 Like

Can you please stop spamming for the a Driver thats already the latest on Davidc's build. update is a firmware blob file for the WRT32X/WRT3200ACM its not a driver.

As pointed out on github your issue is to do with changing the country code within LUCI's Wireless setup, simply change it to driver default and reboot the router.

If you continue to spam i will have to report you to the mods.


I really think DNScrypst is one of the most pointless pieces of software ever made for the internet. Yea you encrypt your DNS request but so what, your ISP still gets the IP in plain text once you have the IP for from DNS. Man-in-the-middle attack? No one is walking into my home network to plug-in a raspberry pi. It's one thing to use one as a Pi-hole but encrypting DNS just seems so pointless too me.


There is a lot of DNS spying going on and companies selling it. By pointing DNSCrypt to a DNS server that doesn't save the requests it 'helps' to cut down on the garbage selling. ISP's can still get an idea of where you are going by IP, but since one IP could have a dozen or more different websites, it isn't as helpful as it used to be. As for MITM, it happens more than people realize. No, people aren't going to tap into your network to get those requests, they will do it remotely and have those requests come to them. By using dnssec or dnscrypt proxy those users are protected from that type of activity. However, still not 100% because we do see a lot of dns hijacking going on where malware will just point your DNS requests to the server of their choosing, but OS AV and 3rd party AV's are pretty good and picking that stuff out these days.
Edit TIP~ Running as "user" instead of "Admin" stops a lot of crap malware can do if it gets on your system. For instance, running as user and you happen to download malware, it couldn't change the tcp/ip settings because it would have to elevate privileges and it wouldn't know the credentials to do so.


Dear Dave - solidus1983 and others,
Hello and I hope that you are well. I do not quite get all the discussion and squabbles about dnscrypt-proxy2 as it seems that most seem dissatisfied due to security concerns. Now I do not pretend to be a know it all. However, in an attempt to be of some small assistance to those here ; may I suggest that those concerned about dns privacy - check out DNSPRIVACY. I have written a few tutorials on the subject - see here : ( From The DNS Privacy Project ) DNS-OVER-TLS on OpenWrt/LEDE FEATURING UNBOUND GETDNS and STUBBY and here : Stubby dns over tls using dnsmasq-full for dnssec & caching for clearer text and reading I have also posted these guides on TORGUARD Forums - here : https://forums.torguard.net/index.php?/topic/1374-from-the-dns-privacy-project-dns-over-tls-on-openwrtlede-featuring-unbound-getdns-and-stubby/ and here : https://forums.torguard.net/index.php?/topic/1455-openwrt-stubby-dns-over-tls-using-dnsmasq-full-for-dnssec-caching/
I keep these pretty much up to date - hopefully; this helps some folks here on this thread. Just remember to still run a properly configured secure VPN service. I also run encrypted SNI on FireFox browser - this should pretty much keep you safe. I also have another tutorial : https://forums.torguard.net/index.php?/topic/1861-openwrt-new-and-improved-getdns-stubby-and-unbound-aka-dns-privacy/ and here -
Fresh new and improved getdns stubby and unbound aka dns privacy
I am always open to feedback and ways to improve running DNSPRIVACY : https://dnsprivacy.org/wiki/



Uploaded new builds to the server. We have a couple kernel bumps, various bug fixes. Same wifi drivers and firmware. The dropbear patch to disable weak ciphers is still included.

Kernel version = 4.19.108
WiFi driver =
Build = r12570




Both I and @spurgeonspooner have expressed an interest in getting Wireguard incorporated into your standard builds. Plus we are willing to help with testing. You've released a couple of builds since we expressed this interest. What can we do to move forward with getting Wireguard in there?


We can certainly give it a roll and see how it does. We are talking 8k for both packages, but I'm not sure about how much space is left on some hardware.

Can we get a sound off for those who own the 1200ac, 1900ac, 1900acV2 please? I think the 1900acs and newer wouldn't have an issue. Just do a df -h in command line and post the results.

OR - In LuCi you can go to System -> Mount Points, and copy the text over like so. I'm thinking we just need overlay and root / .

/dev/ubi0_1   /overlay   38.72 MB / 41.10 MB   0.60% (252.00 KB)
overlayfs:/overlay  /  38.72 MB / 41.10 MB  0.60% (252.00 KB)

I have been on r10899(rango-WRT3200ACM) for a while now, and tried upgrading to a version with v2 of dnscrypt integrated on a few different occassions (the latest being this morning). I can get dnscrypt working fine, the issue I am having is that I cannot get a functioning guest wifi network under the Marvell 88W8964 802.11bgn adaptor. Are there any known issues with the wifi/adding guest networks?

I have tried using my saved config from r10899, and it loads all of the old values, though the system logs say wlan1-1 is not associated to any device. Also, the guest interface can't find the 'guest' network; and there is no way for me to get a DHCP server running on the interface. The guest network appears disabled though it is actually running. My devices can see the network and try connecting, but it fails because there is no dhcp server to assign an address.

I have tried resetting the firmware to default setttings and creating everything from scratch instead of from my saved settings. I get stuck very early in the process-When I create a new wifi network and create a new network name under interfaces, nothing gets created.

I have seen some users post similar issues from October to now, though no solutions were found. Since I can't get this working from defaults and from scratch, I am guessing this is some bug or restriction that started in the same version of firmware when dnscrypt v2 was integrated. Only a guess on my part, I have no other explanation.

If anyone has any ideas, please let me know.


Admittedly, I have a 1900acs and have installed wireguard so I don't think you're asking for the memory information from me. However, in case you are, the df -h results are:

Filesystem                Size      Used Available Use% Mounted on
/dev/ubi0_1               7.5M    592.0K      6.5M   8% /overlay
overlayfs:/overlay        7.5M    592.0K      6.5M   8% /
1 Like

/dev/ubi0_1 7.5M 5.7M 1.4M 80% /overlay
overlayfs:/overlay 7.5M 5.7M 1.4M 80% /

Since I am also running a wireguard server I just install wireguard via opkg. Would you including these packages bring any benefit? Except for avoiding the initial installation?


I finally figured out why my port forwarding wasn't working. I have my linksys router behind an ATT gateway. At some point the gateway reset the firewall rules and closed all ports. I fixed it, told the att router to set the linksys router in dmzplus mode and all good now.

1 Like

Could you maybe please build the package "srelay" so it is available for install. It is a socks5 proxy/relay.

It isn't available yet. You might reach out to "coolsnowwolf" to see it it will be introduced.

Not sure what you mean with that, that is just some luci app.

It looks like the LuCi app is the front end to control srelay. Probably preparing for it.

Thanks for the new build. I'll give it a try asap but I would like to know where is the best place to read about those bug fixes? I always having problems to see what was actually changed with new snapshot builds. Any advice?

You can see the changes made/committed to all the different hardware throughout the OpenWrt line. Go there at least once a day and look for anything mvebu.

1 Like

+1 for Wireguard on 1200 v2.

Hearing about Linus baking it natively in the upcoming 5.x kernel, but I can see openwrt is far from 5.x train kernel.

root@OpenWrt:~# df -h
Filesystem                Size      Used Available Use% Mounted on
/dev/root                20.0M     20.0M         0 100% /rom
tmpfs                   249.5M      3.0M    246.5M   1% /tmp
/dev/ubi0_1               7.5M    128.0K      7.0M   2% /overlay
overlayfs:/overlay        7.5M    128.0K      7.0M   2% /
ubi1:syscfg              29.6M    264.0K     27.8M   1% /tmp/syscfg
tmpfs                   512.0K         0    512.0K   0% /dev
Filesystem Mount Point Available Used Unmount
/dev/root /rom 0 B / 20.00 MB 100.00% (20.00 MB) -
tmpfs /tmp 246.52 MB / 249.47 MB 1.19% (2.96 MB) -
/dev/ubi0_1 /overlay 6.96 MB / 7.50 MB 1.67% (128.00 KB) -
overlayfs:/overlay / 6.96 MB / 7.50 MB 1.67% (128.00 KB) -
ubi1:syscfg /tmp/syscfg 27.77 MB / 29.57 MB 0.87% (264.00 KB) -
tmpfs /dev 512.00 KB / 512.00 KB 0.00% (0 B) -