Davidc502- wrt1200ac wrt1900acx wrt3200acm wrt32x builds

Well good news is I have a 22 day uptime on your last build with kernel 5.4.42 and it's been absolutely flawless. Routing, 5GHz Wifi, Adblock, USB3.0 storage, SQM Cake, software offloading, port forwarding, everything great.


Potentially yes, re-configuring from scratch, unless you are able to work around the problem.

Me too, don't use adblock because of some sites not working great for me. Though, how do you enable software offloading? Can't find it.


1 Like


If I am understanding correctly, the new builds that soft-brick the system would work fine if installed from scratch without carrying over any old configs? If that's the case, maybe having a separate directory for those builds with a disclaimer might be a good option potentially for those that want to update, and keep the stable builds highlighted as they are right now.

Also if starting from the next build from the current release, would that one's configs carry over to the next one without issue?

Sorry I don't know much about what's going on : )

HOW-TO Configure DNSCrypt-proxy2 on a Davidc502 OpenWrt Build

This How-To is condensed from the DNSCrypt-proxy Installation on OpenWrt instructions at:

David's builds come ready out of the box with DNSCrypt-Proxy2 and dnsmasq baked in.

Manual installation

Edit the dnscrypt-proxy.toml file. Change/verify the:

listen_addresses =

line reads as:

listen_addresses = [''] # DNSCrypt-proxy listens here for upstream queries forwarded by dnsmasq

You can un-comment the:

# server_names = ['scaleway-fr', 'google', 'yandex', 'cloudflare']

line and select a specific upstream resolver ie 'cloudflare'. If you leave this line commented out, DNSCrypt-proxy will use the provided Public Resolvers list by default.

Now we need to check that the proxy is properly installed:

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

Watch for possible errors. OK? Start it:

/etc/init.d/dnscrypt-proxy enable
/etc/init.d/dnscrypt-proxy start

Configure dnsmasq

David's stock dhcp configuration file (/rom/etc/config/dhcp) is pretty well configured for our needs, but we still need to add/change a few options in /etc/config/dhcp to:
direct dns queries to dnscrypt-proxy
disable dnsmasq cache
ignore your ISP's DNS by not reading upstream servers from /etc/resolv.conf

Edit /etc/config/dhcp and add/change the following under config dnsmasq section:

config dnsmasq
# Upstream dnscrypt-proxy resolver to use for queries:
list server ''
# Ignore ISP's DNS by not reading upstream servers from /etc/resolv.conf
option noresolv '1'
# Ensures that /etc/resolv.conf directs local system processes to use dnsmasq and hence dnscrypt-proxy
option localuse '1'
# Don't forward RFC 1918 private addresses and RFC 6761 top level domains
option boguspriv '1'
# Disable dnsmasq cache because we don't want to cache twice and the dnscrypt-proxy cache is superior
option cachesize '0'

Restart dnsmasq to switch to the new configuration and check for any errors reported:

/etc/init.d/dnsmasq restart
logread -l 100 | grep dnsmasq

It should report this:

daemon.info dnsmasq[PID]: using nameserver

Preventing DNS queries to other local zones

Preventing leakage of queries from local zones (such as 168.192.in-addr.arpa) to upstream resolvers is enabled by default in dnscrypt-proxy.toml:

block_undelegated = true # Prevent clients on the local network from using external DNS servers

You can verify with:

cat /etc/dnscrypt-proxy2/dnscrypt-proxy.toml | grep undelegated

Create Firewall Rules

Now we need to create firewall rules for redirecting all detectable DNS requests from lan zone clients to dnscrypt-proxy by adding the following rules into /etc/config/firewall:

config redirect
option name 'Divert-DNS, port 53'
option src 'lan'
option proto 'tcp udp'
option src_dport '53'
option dest_port '53'
option target 'DNAT'

config redirect
option name 'Divert-DNS, port 853'
option src 'lan'
option proto 'tcp udp'
option src_dport '853'
option dest_port '853'
option target 'DNAT'

config redirect
option name 'Divert-DNS, port 5353'
option src 'lan'
option proto 'tcp udp'
option src_dport '5353'
option dest_port '5353'
option target 'DNAT'

And reload Firewall: /etc/init.d/firewall reload

Note: Alternatively, if you are using the adblock package you can enable the Force Local DNS option which will create these rules automatically for you.

Verifying the configuration

Check that you are not using your ISP resolver any more:

dnscrypt-proxy -resolve google.com

Resolver IP should NOT belong to your ISP. You can verify whose network an IP address is on IPtoASN - https://iptoasn.com/.

Check that processes on the router use dnsmasq:

cat /etc/resolv.conf
search lan

The above value for nameserver must be, which is the dnsmasq server.

3rd party DNS tests

The DNS leak test - https://www.dnsleaktest.com and DNS randomness test - https://www.dns-oarc.net/oarc/services/dnsentropy show the actual IP of your DNS server(s).

You should make sure that any reported name or IP is NOT associated with the ISP you are using.

If you see the ISP presence in the test results, something is wrong with the configuration, since it's bypassing your dnscrypt-proxy provider.

DNSSEC resolver test - http://dnssec.vs.uni-due.de/ determines whether your DNS resolver validates DNSSEC signatures.

You can also use this site to test both your IPV4 & IPV6 & DNSSEC settings: https://en.internet.nl/connection/

Make sure that the files you added are backed up using LuCI

In the Luci > System > Backup / Flash Firmware page, click the Configuration tab and add the 2 lines below to restore its enabled status after a sysupgrade:


Configuration files in /etc/config are automatically saved already.


Using the command line:

Edit /etc/sysupgrade.conf to add the files to be included in backups.

Optional Steps:

Completely disable ISP's DNS servers

For the perfectionists, add this option to /etc/config/network to prevent the ISP's DNS servers from being used anywhere:

config interface 'wan' # or 'wan6'
option peerdns '0'

Logging DNS queries with client IPs

dnscrypt-proxy can log queries, but in this OpenWrt configuration it cannot log the requesting client IP address because dnsmasq is forwarding the request to dnscrypt-proxy. It can be helpful to know the requesting client IP in order to identify which device is making a particular DNS query. This can be achieved by enabling query logging in dnsmasq as follows:

config dnsmasq
# equivalent to --log-queries=extra in dnsmasq
option logqueries '1'
# where to write log file to
option logfacility '/tmp/dnsmasq_queries.log'

/etc/init.d/dnsmasq restart

Note: These logs accumulate quickly so it is recommended to write to an external share or storage device. Embedded devices have limited flash write cycles and RAM.

Examine the /etc/dnscrypt-proxy2/dnscrypt-proxy.toml File carefully
to enable additional options and off-router logging. The file is very well documented and explanatory.


Thank you. Much Appreciated. I'll give it a go.

My old router is wrt1900ac v1 and fan is working all the time. Can you recommend the simple startup script to turn the fan on 85C and turn it off at 80C as recommended by Linksys.

#!/bin/sh /etc/rc.common
# Copyright (C) 2016-2017 LEDE-Project.org


boot() {
. /lib/functions.sh


case "$board" in
    rc_procd start_service

start_service() {
    procd_set_param command /usr/sbin/fan_monitor -b -a
    procd_set_param stdout 1
    procd_set_param stderr 1

# put in /usr/sbin/fan_monitor
# fan_monitor
# Utility script to monitor temperatures and run fan at 50%/75%/100%
# For Reference the original Belkin specs.

INTERVAL=20  # sleep time in seconds between temp check
FANLOW=127   # low fan speed, set to 0 for off
FANMID=191   # mid fan speed
FANHI=255    # high fan speed

# Set fan to 100% on >= these temperatures
#CPU_HI=80000    # Belkin default is 85
#DDR_HI=58000    # Belkin default is 65
#WIFI_HI=75000   # Belkin default is 105

# Set fan to 75% <= these, otherwise 100% 
CPU_MID=80000     # Belkin sets no default
DDR_MID=58000     # Belkin sets no default
WIFI_MID=75000    # Belkin sets no default

# Set fan to 50% <= these temperatures
CPU_LOW=72000     # Belkin default is 80
DDR_LOW=52000     # Belkin default is 60
WIFI_LOW=55000    # Belkin default is 100

new_pwm="$FANHI"  # start fan at HI while coming up

fan_set() {
    local ppwm

    if [ "$1" -eq $FANLOW ]; then
    elif [ "$1" -eq $FANMID ]; then

    logger -t FAN_MONITOR "Setting Fan to $ppwm"
    echo "$1" > /sys/devices/platform/pwm_fan/hwmon/hwmon0/pwm1

# Crank fan on exit
trap "{ logger -t FAN_MONITOR Fan monitor exiting; fan_set $FANHI; logger -t FAN_MONITOR as a precaution; exit; }" SIGINT SIGTERM

# Main fan control loop
while :
    if [ "$new_pwm" -ne "$cur_pwm" ]
        fan_set "$new_pwm"
    sleep $INTERVAL

    cpu=`cat /sys/class/hwmon/hwmon2/temp1_input`
    ddr=`cat /sys/class/hwmon/hwmon1/temp1_input`
    wifi=`cat /sys/class/hwmon/hwmon1/temp2_input`

    if [ "$cpu" -le $CPU_LOW -a "$ddr" -le $DDR_LOW -a "$wifi" -le $WIFI_LOW ]
    elif [ "$cpu" -le $CPU_MID -a "$ddr" -le $DDR_MID -a "$wifi" -le $WIFI_MID ]

/etc/init.d/fan_control enable
/etc/init.d/fan_control start

Comment out the default in /etc/crontabs/root if extant.

Edit: @vit5421, there was a small issue in /etc/init.d/fan_control due to the mvebu name reconciliation commit a while back. You can just edit the string into the file.

1 Like

How to examine output please.

iirc when enabled it provides some extra output on startup / shutdown; wiki

1 Like

And logread to view it I assume? Sorry for obvious questions, but trying to figure out procd, init scripts, et al.

Got it, TY. It told me what I needed to know.


I had an issue that required restoring the factory image to both partitions. However, I have forgotten how to install David's builds onto my WTR1900ACS. Can someone please provide some step by step instructions.

Many thanks in advance.


1 Like

Thanks Koldur

[RFC PATCH] Introduce UCI support for configuring DSA VLAN filter rules
Link: http://lists.openwrt.org/pipermail/openwrt-devel/2020-July/029955.html
This new dsaconfig binary should be beneficial.


Does this mean that we could configure DSA via Luci? That would definitely help a lot of people with switch to DSA!

At this moment, no - but it's one rather low-level precondition[0] for making that possible in the future.

[0] it teaches uci about a configuration schema, syntax and semantics for defining DSA setups (and the glue code to allow testing/ using it for simple setups). Next stop, netifd integration, only then you could look towards luci.

1 Like

How does one download this patch, as I am trying a compile again tonight.