Simplify and always retry DNS64 prefix discovery.
- Only request AAAAs for the IPv4-only hostname, since that's
all the information being used. Perhaps at some point in the
future when _validation_ of the IPv4 address(es)'s presence
within the IPv6 address(es) is being done this should be
revisited.
- Only use the first AAAA returned to find the DNS64 prefix.
It's not clear how to properly resolve any potential DNS64
prefix conflicts anyway.
- Re-try DNS64 prefix discovery on any type of error.
If clatd was started (presumably an IPv6-only network), retry
DNS64 prefix discovery with exponential backoff. Some
"permanent" errors can be indistinguishable from transient
errors (e.g. receiving an erroneous SERVFAIL from a DNS
resolver, ...).
- Fix-up back-off logic to not sleep 128 then 120, 120, ...
:-)
Bug: 17569702
Change-Id: I226ea7772cd7c88d2b60153ef76e5435400e11aa
diff --git a/config.c b/config.c
index d8bec80..13889a0 100644
--- a/config.c
+++ b/config.c
@@ -165,16 +165,11 @@
memcpy(&Global_Clatd_Config.plat_subnet, &tmp_ptr, sizeof(struct in6_addr));
return;
}
- if(status < 0) {
- logmsg(ANDROID_LOG_FATAL, "dns64_detection/no dns64, giving up\n");
- exit(1);
- }
- logmsg(ANDROID_LOG_WARN, "dns64_detection failed, sleeping for %d seconds", backoff_sleep);
+ logmsg(ANDROID_LOG_WARN, "dns64_detection -- error, sleeping for %d seconds", backoff_sleep);
sleep(backoff_sleep);
+ backoff_sleep *= 2;
if(backoff_sleep >= 120) {
backoff_sleep = 120;
- } else {
- backoff_sleep *= 2;
}
}
}