We only need on demand information when re-bootstrapping. On Bootsrap,
this is already checked by ctrldnet.Up, so on demand query will cause
un-necessary slow down if external ipv6 is slow to response.
On Windows host with StarLink network, ctrld hangs on startup for ~30s
before continue running. This dues to IPv6 is configured but no external
IPv6 can be reached. When probing stack, ctrld is dialing using ipv6
without any timeout set, so the dialing timeout is enforced by OS.
This commit adds a timeout for probing dialer, so we ensure the probing
process will fail fast.
So we don't have to worry about network stack changes causes an upstream
to be broken. Just send requests to all nameservers concurrently, and
get the first success response.
Instead of re-query DNS record for upstream when re-bootstrapping, just
query all records on startup, then selecting the next bootstrap ip
depends on the current network stack.
For better recovery and dealing with network stack changes, this commit
change the request flow to:
failure of any kind -> recreate transport/re-bootstrap -> retry once
That would make ctrld recover from all scenarios in theory.
At startup, ctrld gathers bootstrap IP information and use this
bootstrap IP for connecting to upstream. However, in case the network
stack changed, for example, dues to VPN connection, ctrld will still use
this old (maybe invalid) bootstrap IP for the current network stack.
This commit rework the discovering process, and re-initializing the
bootstrap IP if connecting to upstream failed.
This commit add support for ctrld to run on freebsd, supported platforms
are amd64/arm64/armv6/armv7,386.
Supporting freebsd also requires adding debian and openresolv resolvconf.
Updates #47
After telling service manager to start ctrld, performing self check
status by sending DNS query to ctrld listener. So if ctrld could not
start for any reason, an error message will be reported to user instead
of simply telling service started.
Updates #56
For interface managed by systemd-networkd, systemd-resolved can not
reset DNS. To fix this, attempting to check before the run loop and set
the suitable manager for the system.
Updates #55
For address already in use error when listening, we have a workaround to
spawn a new listener on different port. However, if that case does not
match, we must fatal to notice the error to user.
Currently, ctrld force NetworkManager ignore auto DNS setup from DHCP
per connection. This does not work well, because an interface can be
attached to many connections. So if `ctrld` started with a connection,
then user connect to new one, the DNS configured by ctrld will be
override.
Instead, we can force NetworkManager not to manage DNS by:
- Using dns=none
- Set systemd-resolved=false
So NetworkManager won't attempt to send DNS setup to systemd-resolved,
leaving what ctrld set as-is.
On some Ubuntu systems, we experiment with DNS is not set even though
systemd-resolved log indicates that it set them. To ensure the DNS will
be set, after setting them, double check the current DNS for interface
is actually the value was set, if not, attempting to set again.
While at it, also make sure the DNS is set when ctrld start on Linux.
Currently, when reset DNS, ctrld always find the net.Interface by
interface name. This may produce unexpected error because the interface
table may be cleared at the time ctrld is being stopped.
Instead, we can get the net interface only once, and use that interface
for restoring the DNS before shutting down.
While at it, also making logging message clearer.
If ctrld setup the interface correctly, the interface DNS is set to
ctrld listener address. At boot time, the ctrld is not up yet, so it
would break the processing Control D config fetching.
Fixing this by waiting for network up before doing the query.
On Windows, there's no easy way for disabling/removing IPv6 DNS
resolver, so we check whether we can listen on ::1, then spawn a
listener for receiving DNS requests
On windows, the SYSTEM user is used to run ctrld service. This user has
different environment with the user that run the `ctrld` binary via CLI.
That causes the mismatch issue in config file path, log path, or more
generally, everything that involve with home directory.
To circumvent this pain, just always passing the config path and the
original home dir in start mode. So `ctrld run` command can setup things
correctly.
Cuong Manh Le