Florian Obser([email protected]) on 2021.02.06 19:18:20 +0100:
> I noticed that sometimes DNS64 detection is not working correctly on
> boot. Eventually I tracked it down to this:
> Feb 6 08:56:22 x1 unwind[7139]: check_dns64_done: bad packet: too short: -1
>
> The problem is that we are checking for dns64 while we might not yet
> have a route to the nameserver provided by the router advertisement or
> our IPv6 addresses are all tentative. Since we only re-schedule the
> check when the network changes we are stuck. Instead we can check for
> the presence of DNS64 when we know that DNS works, which is being
> rescheduled correctly.
>
> OK?
ok
> diff --git resolver.c resolver.c
> index 302f381a0dd..95c32369830 100644
> --- resolver.c
> +++ resolver.c
> @@ -1142,6 +1142,8 @@ new_resolver(enum uw_resolver_type type, enum
> uw_resolver_state state)
> /* FALLTHROUGH */
> case RESOLVING:
> resolvers[type]->state = state;
> + if (type == UW_RES_ASR)
> + check_dns64();
> break;
> }
> }
> @@ -2053,7 +2055,6 @@ replace_autoconf_forwarders(struct imsg_rdns_proposal
> *rdns_proposal)
> new_resolver(UW_RES_ASR, UNKNOWN);
> new_resolver(UW_RES_DHCP, UNKNOWN);
> new_resolver(UW_RES_ODOT_DHCP, UNKNOWN);
> - check_dns64();
> } else {
> while ((tmp = TAILQ_FIRST(&new_forwarder_list)) != NULL) {
> TAILQ_REMOVE(&new_forwarder_list, tmp, entry);
>
>
>
> --
> I'm not entirely sure you are real.
>
