Dnscrypt-proxy: DNSCrypt on OpenWRT\LEDE #help wanted

[ghost]

Has anyone experience using DNSCRypt on OpenWRT\LEDE(MIPS) routers?

[worldofpeace]

@milsed Yes I have. Works well enough. The init script doesn't work though.
I've been using this init script

#!/bin/sh /etc/rc.common

START=50
EXTRA_COMMANDS="status"
EXTRA_HELP="        status  Check service status"

PROG="<FULL-PATH>/dnscrypt-proxy"

start() {
    SERVICE_DAEMONIZE=1 service_start "$PROG"
}

stop() {
    service_stop "$PROG"
}

reload() {
    restart
}

status() {
    if service_check "$PROG"; then
        echo "Running"
    else
        echo "Stopped"
    fi
}

Credits to @the-w1nd

I'd like to see an opkg in the openwrt repo's though.

[ghost]

@worldofpeace
look like easy init.d script.
yes, me too.. see an opkg in the openwrt repo's
i think write "howto" use DNSCrypt 2 on OpenWRT\LEDE

[jedisct1]

You can write a howto here, too :)

[ghost]

@jedisct1 @worldofpeace any ideas:

uname -a
Linux asus 4.4.92 #0 Tue Oct 17 17:46:20 2017 mips GNU/Linux
./dnscrypt-proxy
./dnscrypt-proxy: line 1: syntax error: unexpected "("

i use dnscrypt-proxy-linux_mips-2.0.2.tar.gz

[jedisct1]

This error typically means that you didn't download the correct file for your CPU.

Try the mipsle version maybe.

[worldofpeace]

i think write "howto" use DNSCrypt 2 on OpenWRT\LEDE

The howto is pretty much the same as the one on the openwrt wiki aside from actually getting dnscrypt-proxy.

I filed a bug to get an opkg.
But I really don't know the rules of engagement for openwrt. :)

[jedisct1]

errno -9 means that your kernel is too old :(

[jedisct1]

From https://github.com/golang/go/wiki/MinimumRequirements:

Kernel version 2.6.23 or later. [This depends on architecture though, we need to have specific builder for this.] Linux/ARMv5 requires much newer kernels, at least v3.1 (for __kuser_cmpxchg64).

We don't support CentOS 5. The kernel is too old (2.6.18).

For little-endian MIPS64, kernel version 4.1 is known to fail, and 4.8 works.

[ghost]

so.
DNSCrypt 2 easy install on OpenWRT\LEDE. )))

i think, dev LEDE make GUI and opkg..
because its work 1-4 hours max for him

root@asus:/tmp/lib/unbound# drill github.com
;; ->>HEADER<<- opcode: QUERY, rcode: NOERROR, id: 58562
;; flags: qr rd ra ; QUERY: 1, ANSWER: 2, AUTHORITY: 8, ADDITIONAL: 0 
;; QUESTION SECTION:
;; github.com.  IN  A

;; ANSWER SECTION:
github.com. 120 IN  A   192.30.253.113
github.com. 120 IN  A   192.30.253.112

;; AUTHORITY SECTION:
github.com. 900 IN  NS  ns-1283.awsdns-32.org.
github.com. 900 IN  NS  ns-1707.awsdns-21.co.uk.
github.com. 900 IN  NS  ns-421.awsdns-52.com.
github.com. 900 IN  NS  ns-520.awsdns-01.net.
github.com. 900 IN  NS  ns1.p16.dynect.net.
github.com. 900 IN  NS  ns2.p16.dynect.net.
github.com. 900 IN  NS  ns3.p16.dynect.net.
github.com. 900 IN  NS  ns4.p16.dynect.net.

;; ADDITIONAL SECTION:

;; Query time: 188 msec
;; SERVER: 127.0.0.1
;; WHEN: Fri Feb 23 02:15:14 2018
;; MSG SIZE  rcvd: 280
root@asus:/tmp/lib/unbound# 

[jedisct1]

Awesome!

PS: dnscrypt-proxy -resolve github.com looks better :)

[ghost]

dont forget install in your WAN interface DNS resolvers (like 127.0.0.1) :-)

[worldofpeace]

Doesn't look so great.

No, and I do not longer use dnscrypt-proxy … I’ve switched to unbound month ago. The “old” repo is only meant for bugfixes & server list maintenance. The new project is written in “Go” which is currently not supported by the default openwrt buildsystem. Feel free to ask the author directly - I do not plan any efforts in this regard.

- dibdot

[the-w1nd]

@worldofpeace Doesn't look so great.

Yeah, I was suspecting that it would be complicated to get this project integrated into LEDE/OpenWRT buildsystem. Even if "Go" gets the required support, the configurability through UCI and service integration needs to be done differently for LEDE/OopenWRT. The configuration needs to be persisted between firmware flashes, so the current TOML-file is not going to survive, unless you manually take care of it.

I've been testing this project for a week now just to feel the stability and speed. I'm very much satisfied and was planning to write up some instructions on LEDE forums for others who want to give it a try too. But I guess @milsed is going to do it earlier than I can find the time for it. Let me know if you need any help or proof-reading it.

[worldofpeace]

@the-w1nd The configuration needs to be persisted between firmware flashes, so the current TOML-file is not going to survive, unless you manually take care of it.

You can manually specifiy for the directory of where you installed dnscrypt-proxy(i used /opt) to be preserved during an upgrade. This can most easily be done through LuCI:

[the-w1nd]

@worldofpeace You can manually specifiy for the directory of where you installed dnscrypt-proxy(i used /opt) to be preserved during an upgrade.

You're absolutely right! That's one of the places where automatic backup can be configured. Another one is "luci.flash_keep" config section in uci. It can be added through command line or in file "/etc/config/luci" under "config extern flash_keep". I was just trying to say that there is no automatic way to do that at the moment and people need to do it manually.

Also, because the toml-file is expected to be in the same folder as the executable, the back up will try to preserve the executable in flash too and could break something on devices with very limited flash. So, the proper way to do it is by keeping the toml-file in some backed up folder under /etc/... and just create a sym-link to it next to the executable.

[worldofpeace]

@the-w1nd Yeah, I was suspecting that it would be complicated to get this project integrated into LEDE/OpenWRT buildsystem. Even if "Go" gets the required support, the configurability through UCI and service integration needs to be done differently for LEDE/OopenWRT.

I'd love to hear if anyone is interested in working on this. Or at least formulating a solution that doesn't integrate directly into OpenWRT. :stuck_out_tongue_winking_eye:

[jedisct1]

because the toml-file is expected to be in the same folder as the executable

It doesn't have to!

The -config command-line flag let you use a config file that can be anywhere. And other files (blacklists, etc.) will be relative to that config file, not the executable.

[jedisct1]

Also, if there is anything that could be implemented in order to make it a better fit for OpenWRT, lemme know :)

[worldofpeace]

Also, if there is anything that could be implemented in order to make it a better fit for OpenWRT, lemme know :)

I'd talk to someone who does packaging stuffs @openwrt and maybe got go working there in the first place.