Florian Obser(flor...@openbsd.org) 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. >