Skip to content
Snippets Groups Projects
  1. Mar 11, 2009
  2. Feb 20, 2009
  3. Feb 03, 2009
  4. Jan 31, 2009
  5. Jan 14, 2009
  6. Jan 13, 2009
  7. Jan 11, 2009
  8. Dec 09, 2008
  9. Dec 04, 2008
  10. Dec 03, 2008
  11. Nov 26, 2008
  12. Nov 25, 2008
  13. Nov 19, 2008
  14. Nov 01, 2008
  15. Oct 21, 2008
    • Yang Tse's avatar
      Charles Hardin patch: · 3f2de3d1
      Yang Tse authored
      - handles the EINPROGRESS for UDP connects
      - uses closesocket instead of close on some paths that were noticed
      3f2de3d1
  16. Oct 17, 2008
  17. Oct 07, 2008
  18. Sep 17, 2008
  19. Aug 29, 2008
  20. Aug 25, 2008
  21. Aug 04, 2008
    • Daniel Stenberg's avatar
      - Fix by Tofu Linden: · 931fc45f
      Daniel Stenberg authored
        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.
      931fc45f
    • Yang Tse's avatar
      Autoconf 2.62 has changed the behaviour of the AC_AIX macro which we use. · b4fdccf8
      Yang Tse authored
      Prior versions of autoconf defined _ALL_SOURCE if _AIX was defined. But,
      autoconf 2.62 version of AC_AIX defines _ALL_SOURCE along with other four
      preprocessor symbols no matter if the system is AIX or not. To keep the
      traditional behaviour, as well as an uniform one, across autoconf versions
      AC_AIX is replaced with our own internal macro.
      b4fdccf8
  22. Aug 01, 2008
  23. Jul 21, 2008
  24. Jul 17, 2008
  25. Jul 16, 2008
  26. Jul 15, 2008
  27. Jul 03, 2008
    • Daniel Stenberg's avatar
      - Phil Blundell: If you ask ares_gethostbyname() to do an AF_INET6 lookup and · e3b5673e
      Daniel Stenberg authored
        the target host has only A records, it automatically falls back to an
        AF_INET lookup and gives you the A results.  However, if the target host has
        a CNAME record, this behaviour is defeated since the original query does
        return some data even though ares_parse_aaa_reply() doesn't consider it
        relevant. Here's a small patch to make it behave the same with and without
        the CNAME.
      e3b5673e
  28. Jul 02, 2008
  29. Jun 30, 2008
    • Daniel Stenberg's avatar
      - As was pointed out to me by Andreas Schuldei, the MAXHOSTNAMELEN define is · 67f139e0
      Daniel Stenberg authored
        not posix or anything and thus c-ares failed to build on hurd (and possibly
        elsewhere). The define was also somewhat artificially used in the windows
        port. Now, I instead rewrote the use of gethostbyname to enlarge the host
        name buffer in case of need and totally avoid the use of the MAXHOSTNAMELEN
        define. I thus also removed the defien from the namser.h file where it was
        once added for the windows build.
      
        I also fixed init_by_defaults() function to not leak memory in case if
        error.
      67f139e0
  30. Jun 09, 2008
  31. May 30, 2008
  32. May 29, 2008
  33. May 13, 2008
  34. May 09, 2008
  35. May 07, 2008
Loading