aboutsummaryrefslogtreecommitdiff
path: root/lib/md5.c
diff options
context:
space:
mode:
authorDaniel Stenberg <daniel@haxx.se>2008-08-04 20:23:12 +0000
committerDaniel Stenberg <daniel@haxx.se>2008-08-04 20:23:12 +0000
commit931fc45f05e7370fd815c34884863f2b56920b5f (patch)
tree647fe7e0cdd54f186138dcc7e87eeeabcb4b2706 /lib/md5.c
parent6076c7404117940f0625ae643e3c6877fea05dcb (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 'lib/md5.c')
0 files changed, 0 insertions, 0 deletions