Https-dns-proxy not working on boot

Installing and Using OpenWrt
1

Hi

I have an issue with https-dns-proxy not working on boot.

I have to go into the settings page and stop and restart the service for DNS resolution to work.

I have set my router setup with Watchcat to check OpenWrt.org and if it fails it will restart the wan interface that also fixes the DNS resolution problem on boot automatically.

I have dual DNSmasq instances and have DNS hijacking setup with Adblock.
My OpenWrt router is double Nat behind an ISP provided router and gets a private address from it.

After restarting the server or restarting Wan a leak test suggests everything is working.

DNS resolution works if I permanently stop http-dns-proxy from running at boot.

I am running a homebuilt snapshot from this month with the current feeds.

My config files can be found on my github as below:
pj_openwrt/files/etc/config at master · professor-jonny/pj_openwrt (github.com)

2

I can reproduce. I think even with START value of 95 https-dns-proxy starts too early and then is stuck until restarted. I'm trying to figure out how to address it.

1 Like
3

Can it ping check the backup dnsmasq servers before applying rules perhaps?

4

Disable the auto start, put a sleep 30 in the rc.local, and start it after the sleep ?

5

I have it working using Watchcat as a workaround, but it would be best to apply a native fix that would the under lying issue.

6

If it's a race condition, no one can really tell how long it takes for the network to come up.

7

I don't really know how to diag this problem I guess it is an issue with the backup DNS not resolving the address of the secure DNS or it is rejecting the the router because ntp has not synced the time.

8

Set up Hotplug extras and try this:

mkdir -p /etc/hotplug.d/online
cat << "EOF" > /etc/hotplug.d/online/30-doh
/etc/init.d/https-dns-proxy restart
EOF
4 Likes
9

Thanks @vgaetera I didn't know about online hotplug. I've incorporated it into package/Makefile and will test with various start settings. There was already the WAN/WAN6 procd triggers but they weren't helping.

1 Like
10

To tell the truth, this method is borrowed from the firewall hotplug script and has some caveats:

  • The script can be triggered more than once by some connection types, e.g. WAN+WAN6 in a dual-stack setup, PPPoE with a dynamic IP, chained WAN+VPN supported by netifd, etc.
  • The network functions work only for interfaces which protocols are supported by netifd, so unsupported protocols like OpenVPN can still change the default gateway and don't trigger the script.
    • This may result in a race condition if some service starts along with OpenVPN and tries to establish a connection with an upstream server the moment when the default gateway changes.
11

@professor_jonny if you're using x86_64 and want to grab an IPK from my dev repo or can update your init-script and hotplug file from my source repo, please test and let me know.

1 Like
12

So if i just update the init sript and put the hotplug script here? :

/etc/hotplug.d/online/30-https-dns-proxy

I have tested your updated scripts and it works great, it fixed the problem for me.

1 Like
13

This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.