diff options
author | Daniel Stenberg <daniel@haxx.se> | 2008-08-04 20:23:12 +0000 |
---|---|---|
committer | Daniel Stenberg <daniel@haxx.se> | 2008-08-04 20:23:12 +0000 |
commit | 931fc45f05e7370fd815c34884863f2b56920b5f (patch) | |
tree | 647fe7e0cdd54f186138dcc7e87eeeabcb4b2706 /tests/data/test1043 | |
parent | 6076c7404117940f0625ae643e3c6877fea05dcb (diff) |
- 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.
Diffstat (limited to 'tests/data/test1043')
0 files changed, 0 insertions, 0 deletions