From 931fc45f05e7370fd815c34884863f2b56920b5f Mon Sep 17 00:00:00 2001 From: Daniel Stenberg Date: Mon, 4 Aug 2008 20:23:12 +0000 Subject: - Fix by Tofu Linden: The symptom: * Users (usually, but not always) on 2-Wire routers and the Comcast service and a wired connection to their router would find that the second and subsequent DNS lookups from fresh processes using c-ares to resolve the same address would cause the process to never see a reply (it keeps polling for around 1m15s before giving up). The repro: * On such a machine (and yeah, it took us a lot of QA to find the systems that reproduce such a specific problem!), do 'ahost www.secondlife.com', then do it again. The first process's lookup will work, subsequent lookups will time-out and fail. The cause: * init_id_key() was calling randomize_key() *before* it initialized key->state, meaning that the randomness generated by randomize_key() is immediately overwritten with deterministic values. (/dev/urandom was also being read incorrectly in the c-ares version we were using, but this was fixed in a later version.) * This makes the stream of generated query-IDs from any new c-ares process be an identical and predictable sequence of IDs. * This makes the 2-Wire's default built-in DNS server detect these queries as probable-duplicates and (erroneously) not respond at all. --- ares/CHANGES | 28 ++++++++++++++++++++++++++++ 1 file changed, 28 insertions(+) (limited to 'ares/CHANGES') diff --git a/ares/CHANGES b/ares/CHANGES index d23897216..dff8e8d67 100644 --- a/ares/CHANGES +++ b/ares/CHANGES @@ -1,5 +1,33 @@ Changelog for the c-ares project +* Aug 4 2008 (Daniel Stenberg) +- Fix by Tofu Linden: + + The symptom: + * Users (usually, but not always) on 2-Wire routers and the Comcast service + and a wired connection to their router would find that the second and + subsequent DNS lookups from fresh processes using c-ares to resolve the same + address would cause the process to never see a reply (it keeps polling for + around 1m15s before giving up). + + The repro: + * On such a machine (and yeah, it took us a lot of QA to find the systems + that reproduce such a specific problem!), do 'ahost www.secondlife.com', + then do it again. The first process's lookup will work, subsequent lookups + will time-out and fail. + + The cause: + * init_id_key() was calling randomize_key() *before* it initialized + key->state, meaning that the randomness generated by randomize_key() is + immediately overwritten with deterministic values. (/dev/urandom was also + being read incorrectly in the c-ares version we were using, but this was + fixed in a later version.) + * This makes the stream of generated query-IDs from any new c-ares process + be an identical and predictable sequence of IDs. + * This makes the 2-Wire's default built-in DNS server detect these queries + as probable-duplicates and (erroneously) not respond at all. + + * Aug 4 2008 (Yang Tse) - Autoconf 2.62 has changed the behaviour of the AC_AIX macro which we use. Prior versions of autoconf defined _ALL_SOURCE if _AIX was defined. 2.62 -- cgit v1.2.3