Davidc502- wrt1200ac wrt1900acx wrt3200acm wrt32x builds

Thanks @herik

I'm not sure how to categorize this potential issue. Is the fact that dnsmasq not being able to find the file causing issues on your end? Maybe this should go to dev and not flyspray. Maybe pose the question on the dev forum and see if you get any bites - https://forum.openwrt.org/c/devel if you don't get a response from dev, then consider flyspray, and see the response you get there -- https://bugs.openwrt.org/index.php?do=tasklist&project=2

As for adding unbound, since I've never worked with unbound, I wouldn't feel comfortable switching over to it at this time.

For softether - I see both v4 and v5 being available in the repo today. All of them are selected as a module meaning they aren't built in, but are downloadable. Unfortunately I can't build it in because we have at least one model of Linksys that just doesn't have the space. At this point I have to be very selective to what is added to the build.

I can't use 160Mhz, but makes little difference in throughput at least for me. Also, the DFS issue kills wifi after radar is detected, and it just doesn't recover.
Have you been able to use 160Hz width for some time? Do you live in a populated area or more rural and away from any airports?

Thank you very much Mr David
I hope about this dnsmasq file fixed soon

Real thanks for your time
Have a nice day

I am using channel 100 with 160hz, I do have an Airport 40+ Miles away from me and I am on a flight path. I have just since updating that post gone to 160hz mode, i will keep you updated if I get Radar detected however in the past it just wouldn't bring the connection up without it stating radar detected so we will soon find out when the next aircraft comes flying past be it a civilian or military aircraft.

Sorry about being vague about location in a public thread I will send you location in a DM if it will help.

I also noticed without placing my country code in
to the settings for 5Ghz 160hz would simply not work at all but after that it worked.

Yes I am not getting 2600 in speed but I am getting 1733 and lows of 64 rather then the standard 866 with lows of 7.2 . Latency and jitter is the same on channel 100 as it is on 80hz mode channel 48.

I am currently doing a 1.5gb upload (got to try and get the line to fail for science) which after I will be uploading a 3.5gb file (OS images for modem line stats in 64bit and 32bit raspbian is flavours)

I knew to use channel 100 due to all my router I test with seem to use that channel without issue one Stock firmware on WRT32X, the DWA0120 and the TG 589vac V2 the latters being Technicolour ISP CPE's (The port forwarding nightmares). These CPE ISP gateways didn't drop the connection for 5Ghz at all nor did the stock WRT32X firmware from Linksys.

System log shows

Fri Nov  8 17:15:34 2019 daemon.notice hostapd: wlan0: DFS-NOP-FINISHED freq=5500 ht_enabled=0 chan_offset=0 chan_width=0 cf1=5500 cf2=0
Fri Nov  8 17:15:34 2019 daemon.notice hostapd: wlan0: DFS-NOP-FINISHED freq=5520 ht_enabled=0 chan_offset=0 chan_width=0 cf1=5520 cf2=0
Fri Nov  8 17:15:34 2019 daemon.notice hostapd: wlan0: DFS-NOP-FINISHED freq=5540 ht_enabled=0 chan_offset=0 chan_width=0 cf1=5540 cf2=0
Fri Nov  8 17:15:34 2019 daemon.notice hostapd: wlan0: DFS-NOP-FINISHED freq=5560 ht_enabled=0 chan_offset=0 chan_width=0 cf1=5560 cf2=0
Fri Nov  8 17:15:34 2019 daemon.notice hostapd: wlan0: DFS-NOP-FINISHED freq=5580 ht_enabled=0 chan_offset=0 chan_width=0 cf1=5580 cf2=0
Fri Nov  8 17:15:34 2019 daemon.notice hostapd: wlan0: DFS-NOP-FINISHED freq=5600 ht_enabled=0 chan_offset=0 chan_width=0 cf1=5600 cf2=0
Fri Nov  8 17:15:34 2019 daemon.notice hostapd: wlan0: DFS-NOP-FINISHED freq=5620 ht_enabled=0 chan_offset=0 chan_width=0 cf1=5620 cf2=0
Fri Nov  8 17:15:34 2019 daemon.notice hostapd: wlan0: DFS-NOP-FINISHED freq=5640 ht_enabled=0 chan_offset=0 chan_width=0 cf1=5640 cf2=0

Which means it was Radar detected however rather then dropping the connection it just through the router back to channel 36, i was gaming at the time and didn't even notice.

WRT3200ACM user here, reporting in that r11398 is working fine (for the past hour).

In order to get DNSCrypt working properly, I did need to add the option noresolv '1' option that was called out above by @rainkinz . I went ahead and threw in option localuse '1' as well, to ensure my local router queries use the same DNS.

This matches the GitHub Documentation as well: https://github.com/DNSCrypt/dnscrypt-proxy/wiki/Installation-on-OpenWRT

With all that working, dnsleaktest.com passes with flying colors.

I did have to jimmy/disable-reenable my Interfaces and bounce my modem in order for a network connection to come through properly. For some reason the WAN (not 6) had the "Use builtin IPV6 management" option checked - since it's an IPV4 interface, I just unchecked it.

After saving/applying, all Interfaces came up with IP from modem - success!


I have the same cosmetic time issue on Overview Page as @abysso2.

I have a WRT3200ACM with Davidc502's latest build r11398

Mine is -6 hours! :slight_smile: lol.. Though system time shows correctly.
Has anybody looked to see if this issue has been reported? Also, would like to eliminate a particular LuCi version.

I've had a number of issues when upgrading to r11398 from r11266 on my WRT1900ACS V2. The issues have included:

  1. Multiple instances of IPv6 Upstream displayed in Overview -> Network
  2. dnscrypt-proxy working for ~12 hours, then suddenly not resolving
  3. Odd behavior in the dnscrypt-proxy log file in that not all my servers identified in the toml file are represented
  4. Adblock not starting with a block list on upgrade
  5. Losing the 2.4GHz WiFi network after many hours that comes along with a profound loss of memory and requiring a reboot

First, on the Overview page in LuCI, I am used to seeing one IPv4 Upstream Network and one IPv6 Upstream Network. With r11398, I see three IPv6 Upstreams, which are all the same, as pictured:

They are all duplicates.

The second issue, dnscrypt-proxy working fine for ~12 hours and then suddenly not resolving was frustrating. @YummyHamster suggested I recheck the configuration per the setup instructions, specifically where my ISP DNS may interfere with my selection. I did so, found no issues, and no longer have any DNS problems although given the other issues I have had I don't know if it is truly fixed.

The third issue is my dnscrypt-proxy log looks weird and misses servers after restarting the service. Under r11266, the log file typically looks like:

[2019-11-09 16:11:03] [NOTICE] Stopped.
[2019-11-09 16:11:03] [NOTICE] dnscrypt-proxy 2.0.27
[2019-11-09 16:11:03] [NOTICE] Network connectivity detected
[2019-11-09 16:11:03] [NOTICE] Source [public-resolvers.md] loaded
[2019-11-09 16:11:03] [NOTICE] Firefox workaround initialized
[2019-11-09 16:11:03] [NOTICE] Loading the set of blocking rules from [blacklist.txt]
[2019-11-09 16:11:03] [NOTICE] Now listening to [UDP]
[2019-11-09 16:11:03] [NOTICE] Now listening to [TCP]
[2019-11-09 16:11:13] [NOTICE] System DNS configuration not usable yet, exceptionally resolving [dns9.quad9.net] using fallback resolver []
[2019-11-09 16:11:13] [NOTICE] [quad9-doh-ip4-filter-pri] OK (DoH) - rtt: 17ms
[2019-11-09 16:11:13] [NOTICE] [cloudflare-ipv6] OK (DoH) - rtt: 5ms
[2019-11-09 16:11:13] [NOTICE] [cloudflare] OK (DoH) - rtt: 4ms
[2019-11-09 16:11:13] [NOTICE] [quad9-doh-ip6-filter-pri] OK (DoH) - rtt: 17ms
[2019-11-09 16:11:13] [NOTICE] Sorted latencies:
[2019-11-09 16:11:13] [NOTICE] - 4ms cloudflare
[2019-11-09 16:11:13] [NOTICE] - 5ms cloudflare-ipv6
[2019-11-09 16:11:13] [NOTICE] - 17ms quad9-doh-ip4-filter-pri
[2019-11-09 16:11:13] [NOTICE] - 17ms quad9-doh-ip6-filter-pri
[2019-11-09 16:11:13] [NOTICE] Server with the lowest initial latency: cloudflare (rtt: 4ms)
[2019-11-09 16:11:13] [NOTICE] dnscrypt-proxy is ready - live servers: 4

Under r11398, the log file misses servers after restart, even though they are in the toml file:

[2019-11-09 18:31:44] [NOTICE] Quit signal received...
[2019-11-09 18:31:44] [NOTICE] Stopped.
[2019-11-09 18:31:44] [NOTICE] dnscrypt-proxy 2.0.29
[2019-11-09 18:31:44] [NOTICE] Network connectivity detected
[2019-11-09 18:31:44] [NOTICE] Source [public-resolvers.md] loaded
[2019-11-09 18:31:44] [NOTICE] Firefox workaround initialized
[2019-11-09 18:31:44] [NOTICE] Loading the set of blocking rules from [blacklist.txt]
[2019-11-09 18:31:44] [NOTICE] Now listening to [UDP]
[2019-11-09 18:31:44] [NOTICE] Now listening to [TCP]
[2019-11-09 18:31:45] [NOTICE] [cloudflare] OK (DoH) - rtt: 5ms
[2019-11-09 18:31:55] [NOTICE] Server with the lowest initial latency: cloudflare (rtt: 5ms)
[2019-11-09 18:31:55] [NOTICE] dnscrypt-proxy is ready - live servers: 1

I can monkey around to get the other three servers back, essentially my editing the toml file, making no real changes, and restarting dnscrypt-proxy again, however it is not clear they will stay. Moreover, I have seen the following in the dnscrypt-proxy log file:

[2019-11-09 20:25:46] [WARNING] Too many connections (max=250)
[2019-11-09 20:25:46] [WARNING] Too many connections (max=250)
[2019-11-09 20:25:46] [WARNING] Too many connections (max=250)
[2019-11-09 20:25:46] [WARNING] Too many connections (max=250)
[2019-11-09 20:25:56] [NOTICE] System DNS configuration not usable yet, exceptionally resolving [dns9.quad9.net] using resolver udp[]
[2019-11-09 20:25:56] [NOTICE] System DNS configuration not usable yet, exceptionally resolving [dns9.quad9.net] using resolver udp[]
[2019-11-09 20:25:56] [NOTICE] System DNS configuration not usable yet, exceptionally resolving [dns9.quad9.net] using resolver udp[]
[2019-11-09 20:25:56] [NOTICE] System DNS configuration not usable yet, exceptionally resolving [dns9.quad9.net] using resolver udp[]

So this is weird and I have never seen it before.

Fourth, after previous upgrades, adblock comes up with the full blocklist. With the r11398 upgrade, no domains were in the blocklist and I had to refresh blocklist sources. Clearly, it is not hard to do that but there has been no previous upgrade where I needed to do so, and I've done a lot of upgrades. Strange behavior.

Finally, at least once I have lost the 2.4 GHz WiFi network after running for ~10 hours. Afterwards, when I look at the Overview page in LuCI, the Total Available and Free memory, which usually hover around 70%, were down at 10%. I did not do anything unique with my network, so I don't understand why memory got so low and I lost a WiFi network. Again, an experience I never previously had.

So.... I've been through many upgrades with David's build, and I don't remember a previous instance where I had so many issues that made the upgrade perhaps unusable. Any thoughts on what I should check?

[Solved]: had to override the WAN MAC address to match the older working one

Hello everyone, hope your weekend is going well.

I have been running into an issue with the last couple builds. I am currently on OpenWrt SNAPSHOT r10899-1c0290c5cc / LuCI Master (git-19.241.65047-dffe9ca) kernel version 4.19.69, and have not been able to access the internet in all the builds after. My WAN interfaces do not have any upstream data or respective IPv4 or IPv6 addresses.

Initially tried keeping my settings which currently use Stubby, and worked backwards to disable it to try to get a connection, but it fails. I then tried doing a fresh sysupgrade.bin but the issue remains. Not sure why it would be failing with fresh settings.

Any ideas? Both partitions are OpenWRT

Here is my /etc/config/network and ifstatus wan dump on the latest build (no internet):

Hey !

Maybe you need the Use broadcast flag under option @wan interface some ISP's need it for docsis 3+.
All latest builds work just fine. The log shows that the wan interface is not up at all (No Connectivity) are you sure the cable is still fine?

Best Regards,


It was a different WAN MAC address, I figured it out. Had to do an override with the old working MAC and voila! Time to call the ISP I guess

Hi There,

This indeed looks strange, perhaps it's worth to safe the config and do a factory reset and start from there? It's not ideal for sure but if the list of issues is only growing this might be the fastest way.

Glad it works again enjoy the internet!

1 Like

Hi There,

Local time is indeed of by 1H for me aswell only in webinterface.

10-11-2019 01:55:34

OpenWrt SNAPSHOT r11398-6f3a293532 / LuCI Master git-19.307.79135-4e9f2d3

Time/Date region is set correctly, command "date" in terminal shows correct time only the web interface seems wrong.

root@MAA-ROUTER01:~# date
Sun Nov 10 01:04:52 CET 2019
root@MAA-ROUTER01:~# date -u
Sun Nov 10 00:04:57 UTC 2019
root@MAA-ROUTER01:~# uci show system | grep zone

Latest LuCI master has the fixes.


The thought of doing a complete reset did cross my mind.... However I've been using these builds for a long time with no problems, so I'm really reluctant to hit a reset button at this point. Tough choice! I'd hate to be stuck on r11266 forever.

Hi All,

Sorry this is a bit OT, but maybe someone here can point me in the right direction. I have couple of commercial wifi cameras (I was using motioneye previously), and I'd like to create a separate AP for them and not allow them to access my LAN at all. They could get out to the internet to 'call home', and upload their recordings, but that would be it. Could anyone point me at a good article for how to do this? I've read some about configuring VLANs, but what about the wifi part?

Thanks again for all the great work.

When using https with uhttpd/luci the webinterface is slow.
But when using own certificates and the certificates got installed on the client machine
(so the browser doesn't throw a certificate error), luci web interface access is way faster.

And for last releases in trunk (not related to david's builds), IPv6 prefix delegation is again not working for me. After reboot I have to restart wan and wan6 to get the prefix delegation working.
Only restarting wan6 doesn't work, doesn't even get a IPv6 address.

Maybe something to do with flowoffload? I'm running master/trunk as well but the only switch I flipped is changing target/linux/mvebu/Makefile to KERNEL_PATCHVER:=4.14.

I still think kernel 4.19 is not fully stable yet. I do know there are fixes to mvneta, though I ended up just backporting some of them to 4.14.


I've got an OpenVPN tunnel setup to a provider, and want all internet traffic for all devices to go over this tunnel except for my Roku (video streaming services often won't work properly over the VPN). It looks like mwan3 is what I need to do this, but when I try to install, I get:

root@LEDE:/etc/openvpn# opkg install mwan3 luci-app-mwan3
Installing mwan3 (2.8.0-2) to root...
Downloading https://dc502wrt.org/snapshots/r11398/packages/arm_cortex-a9_vfpv3/packages/mwan3_2.8.0-2_all.ipk
Installing ip-tiny (5.3.0-1) to root...
Downloading https://dc502wrt.org/snapshots/r11398/packages/arm_cortex-a9_vfpv3/base/ip-tiny_5.3.0-1_arm_cortex-a9_vfpv3.ipk
Installing luci-app-mwan3 (git-19.307.79135-4e9f2d3-1) to root...
Downloading https://dc502wrt.org/snapshots/r11398/packages/arm_cortex-a9_vfpv3/luci/luci-app-mwan3_git-19.307.79135-4e9f2d3-1_all.ipk
Configuring ip-tiny.
Configuring mwan3.
uci: Entry not found
uci: Entry not found
grep: /var/etc/miniupnpd.conf: No such file or directory
uci: Entry not found
uci: Entry not found
grep: /var/etc/miniupnpd.conf: No such file or directory
Configuring luci-app-mwan3.
root@LEDE:/etc/openvpn#  120948  WARN : Service section disabled! - TERMINATE

I'm unsure how to resolve this, can someone point me in the right direction?