Potential bug: dnscrypt-proxy does not go to "wait for network" after loss of connectivity

[bitandquit]

Version & Environment:

dnscrypt-proxy-android_arm64-2.1.5 , device: Lineage-20 (Android 13), running as root

What is affected by this bug?

On loss of network connectivity, when it is time to renew certificates, dnscrypt-proxy will keep retrying rather than going back to a "wait for network available" state.

When does this occur?

Loss of network connectivity, during certificate refresh time, even with netprobe_timeout = -1 .

How do we replicate the issue?

• Set cert_refresh_delay in configuration to something small (i.e. 2 mins)
• Set netprobe_timeout = -1 (wait as much as possible)
• Comment out bootstrap_resolvers
• Enable logging

Launch dnscrypt-proxy with network disconnected, then enable network connectivity (i.e. enable wifi), verify it can connect to valid DNS resolvers then disable network connectivity, leaving dnscrypt-proxy running.

tail -f will show dnscrypt-proxy will keep retrying to renew certificates

Expected behavior (i.e. solution)

On loss of network connectivity, I would presume dnscrypt-proxy go back to "waiting for network" as it does on start-up. On Android, wait for network works properly until dnscrypt-proxy connects successfully, but after loss it does not return to this "global state".

Other Comments

An alternative solution might be to signal to dnscrypt-proxy to suspend it self and resume itself and then handle passing this to the program externally (i.e. via BASH script, etc). On Android, I have yet to try kill -TSTP / kill -CONT so maybe this can already be done (I will test shortly).

[lifenjoiner]

On loss of network connectivity, when it is time to renew certificates, dnscrypt-proxy will keep retrying rather than

The strategy is, depending on the refreshing result:

1. if there is no valid upstream, sleep a short time (10 minutes) to retry to be available ASAP;
2. if get any, then service is available. The servers ranking is updated on the fly. And sleep cert_refresh_delay (min: 60) minutes.

going back to a "wait for network available" state

Is that necessary?

[bitandquit]

On loss of network connectivity, when it is time to renew certificates, dnscrypt-proxy will keep retrying rather than

The strategy is, depending on the refreshing result:

1. if there is no valid upstream, sleep a short time (10 minutes) to retry to be available ASAP;
2. if get any, then service is available. The servers ranking is updated on the fly. And sleep cert_refresh_delay (min: 60) minutes.

I don't know if you've tested it, but at least on my system the retries were more like once every 10-30 seconds, definitely more frequent than 10 min intervals. I don't know if that's because maybe something in the system made a DNS request, therefore it forced a retry?

going back to a "wait for network available" state

Is that necessary?

From a system design perspective that would be "logical" to me but I'm not the author or maintainer of the program so obviously I can't force such a change. I still don't understand why the behavior would go into a retry loop (even at 10 min intervals) vs. going back to "wait for network" state if there's no network.

[lifenjoiner]

Can you provide the log? I don't have rooted Android devices, and can't get what you say on PC.

I still don't understand why the behavior would go into a retry loop (even at 10 min intervals) vs. going back to "wait for network" state if there's no network.

I guess there would be false positive loss of connectivity.
The implementation may be different from what we see, but still aiming to be available, stable and robust.

[jedisct1]

We will never know.