Davidc502- wrt1200ac wrt1900acx wrt3200acm wrt32x builds

Hi David,

I just wanted to let you know that despite configuring as described above it looked like I was still leaking dns queries (at least according to: https://www.dnsleaktest.com). What appears to have fixed it for me was setting:

    option noresolv '1'

in the config dnsmasq section of /etc/config/dhcp.

Not sure if that's correct or not, but wanted to let you know. Thanks!


Thanks for the instructions. I will give it a shot.
One observation though, I flashed the latest firmware but I did not configure DNSCrypt at all and I noticed the followings:

  1. Under "services" there is no DNSCrypt-Proxy anymore. Is this expected? ( you said that DNSCrypt versio 2 is built-in in the latest firmware. Do I still need to install it before I follow your instructions listed above?

  2. I was able to connect but without internet connection at all. When I checked the connection information I found that the Primary DNS for the client was which is the router's IP. Do you think that websites did not resolve because DNSCrypt was not configured yet?

For #1 that is correct. Luci-app-dnscrypt-proxy is for version 1 (hence not installed).

For #2 It sounds like the problem may be several things, so it is hard to say. For now, your clients can be manually set up to use, for example, and it should work normally until dnscrypt-proxy2 is configured.

Sorry for the newb question, but Google is failing me:
Everything works fine running r10899 with dns-proxy2. When I upgrade to a newer version with saving settings, I lose the internet connection. E.g., ping returns:
ping: sendto: Network unreachable

Any help on where to start debugging is appreciated. Thanks.

Sorry, just a very very little issue, but the "Local Time" is not shown correctly on the "Overview"-Page in LuCi. I have chosen the timezone Europe/Berlin and it is shown correctly on the "System"-Tab, but the Overview-Page shows the actual time +1h.

Hi all. I just put this on my 1900ACSv2 a few days ago and today was attempting to setup an openVPN server as per the OpenWRT Openvpn basic setup guide.
It fails when attempting to delete the /etc/easy-rsa/pki directory with this-

# Remove and re-initialize the PKI directory
easyrsa --batch init-pki

Has an I/O error, exactly as per this thread-


When re-doing the whole openVPN basic guide setup instead using /tmp, I found I could copy everything to that pki directory except the reqs and private directories (which after the I/O error didn't exist, and threw the I/O error attempting a cp -fr of those 2 directories from tmp).

So I did a factory reset, and sure enough, there is a pki directory with empty reqs and private directories in the default OpenWRT factory default image, and it does not like letting one delete those I presume.

Don't know if this is specific to this (yesterday/recent) builds, or a general OpenWRT issue yet (still on a steep learning curve here).

Still fiddling here, wondering if I should attempt this OpenVPN(server) setup via luci instead of following the OpenVPN basic guide.

edit: If I followed every step in that guide except the "init-pki", it seems to create the files required and starts the server.

1 Like

I have an issue with name resolution after upgrading to r11398. I've been using dnscrypt-proxy v2 for a long time. After upgrading to r11398, things work fine for a number of hours. Then, name resolution simply starts timing out:

root@OpenWrt:/etc/dnscrypt-proxy2# nslookup cnn.com
;; connection timed out; no servers could be reached


I didn't see anything in the dnscrypt-proxy log or the system log which indicates why I am having this problem. I needed to roll back to r11266. Any ideas for what is causing this issue?

1 Like

Start here:

Look @ "Configure dnsmasq to forget about ISP's DNS and only use DNSCrypt" follow this step and after.

1 Like

Yep, I essentially followed that guide a year or so ago when I started using dnscrypt-proxy v2. It's been working great until I upgraded to r11398.

Just recheck configuration.


Hi David,

I followed the instructions you listed but I am still having the same issue. Nothing is being resolved before or after I made the changes from your instructions.

Here is what I did:

  1. I reset my router to factory settings from within Luci
  2. I flashed the latest firmware " *r11398"
  3. I edited the .toml file and the following changes
    listen_addresses = ['']
    server_names = ['cloudflare']
  4. restarted /etc/init.d/dnscrypt-proxy restart
  5. Then I edited /etc/config/dhcp and added list dhcp_option '6,' under LAN and added ist server '' under "config dnsmasq"
  6. restarted /etc/init.d/dnsmasq restart and I got a message that it was failing ( see attached screenshot)

But still nothing was being resolved. I restarted my clients and restarted the router but it did not help.
Even if I remove the line (list server '') from dnsmasq and restart the service it did not make any difference.

Please see attached screenshots




Run this command on the router.

dnscrypt-proxy -config /etc/dnscrypt-proxy2/dnscrypt-proxy.toml -check

Sorry for any confusion. When I said "stock openwrt" I did not mean the firmware provided by Linksys. I meant the firmware downloaded here:
http://downloads.openwrt.org/releases/18.06.4/targets/mvebu/cortexa9/openwrt-18.06.4-mvebu-cortexa9-linksys-wrt32x-squashfs-factory.img (I want to be very specific)

In fact, I've never used the firmware provided by Linksys for anything other than flashing OpenWRT.

When using that image, I get significantly better 5ghz performance than I did using David's build. I did not test performance for the 2.4ghz radio, I may or may not have had similar performance patterns on the 2.4ghz radio, but I never tested. When I say "significantly better performance" I am referring to the crocodile pattern mentioned by @sunarowicz. Not only do I see a crocodile pattern with David's build, but an increase in lost packets, and overall throughput is much lower as well.

I don't know why my 5ghz performance is significantly better with the stable mainstream OpenWRT image (linked to above) than it is with Davidc502's build. I was speculating when I said that it might be that a new driver provided by David's build doesn't work well for my router. I thought that one of the features that David provides is the latest drivers. However, @davidc502 said this:

This is the same Wifi Driver. Expect Zero difference between the 2. You are welcome to try it out, but wifi is sketchy for some.

And I think that means that he doesn't pack a newer driver than the firmware that is linked to above.

Like @sunarowicz, I have very little (like zero) interference from other 5ghz routers in my neighborhood. My problems could not have been caused by that kind of interference. I basically have line of sight with my only 5ghz client (It's a server that I want to keep very fast).

I guess it could have been wild coincidence that I happened to have worse performance with David's build than with the stock openwrt (again, linked to above) build. But it did start when I installed and ran David's build, and stopped immediately when I switched back to the stock/stable openwrt image (you guessed it, linked to above).

How does one go about forking this build to the EA9500v1.1? The only difference is the 1900's and 3200's are Marvell and the the EA9500's are BCM. There is a build for it but It's what I deem bloated and not really what I am looking for in a OpenWRT build. Does anyone have any insight on this at all? Thanks in advance.

Unfortunately I don't think the open source marvel driver (mwlwifi) supports mesh.

Sadly no it doesn't. The best you can do is use one of the radios for backhaul and WDS. Then use the other radio for a distant AP. Unless you hardwire them all together.


Thanks for clarifying this. I was considering doing this, but you just saved me some time. Maybe I'll look into moca or power plug with a second cheapo router to kind of fill in the weak spots.

1 Like

Happy to hardwire the AP's together for the backhaul.. The house has Ethernet ports in every room so this would be the prefered option for the mesh solution.

So i did a little check on the 3200..

iw list | grep "Supported interface modes" -A 9
        Supported interface modes:
                 * managed
                 * AP
                 * AP/VLAN
                 * monitor
                 *** mesh point**
        Band 1:
                Capabilities: 0x186f
                        RX LDPC
        Supported interface modes:
                 * managed
                 * AP
                 * AP/VLAN
                 * monitor
                 *** mesh point**
        Band 2:
                Capabilities: 0x186f
                        RX LDPC

That to me says it is there...

Listed is not the same as working (not apparently).