Commit 931fc45f authored by Daniel Stenberg's avatar Daniel Stenberg
Browse files

- 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.
parent 6076c740
Loading
Loading
Loading
Loading
+28 −0
Original line number Diff line number Diff line
  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
+2 −1
Original line number Diff line number Diff line
@@ -8,10 +8,11 @@ This is what's new and changed in the c-ares 1.5.3 release:
 o configure process no longer needs nor checks size of curl_off_t
 o library will now be built with _REENTRANT symbol defined if needed
 o Improved configure detection of number of arguments for getservbyport_r
 o Improved query-ID randomness

Thanks go to these friendly people for their efforts and contributions:

 Brad House, Yang Tse, Phil Blundell
 Brad House, Yang Tse, Phil Blundell, Tofu Linden
 and obviously Daniel Stenberg

Have fun!
+1 −1
Original line number Diff line number Diff line
@@ -1464,11 +1464,11 @@ static int init_id_key(rc4_key* key,int key_data_len)
  if (!key_data_ptr)
    return ARES_ENOMEM;

  randomize_key(key->state,key_data_len);
  state = &key->state[0];
  for(counter = 0; counter < 256; counter++)
    /* unnecessary AND but it keeps some compilers happier */
    state[counter] = (unsigned char)(counter & 0xff);
  randomize_key(key->state,key_data_len);
  key->x = 0;
  key->y = 0;
  index1 = 0;