[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#554188: marked as done (getaddrinfo: times out when asking for v4 and v6 without single-request option)



Your message dated Tue,  3 Nov 2009 17:57:59 -0500 (EST)
with message-id <20091103225759.64A614496@carter-zimmerman.suchdamage.org>
and subject line not in libc
has caused the Debian Bug report #554188,
regarding getaddrinfo: times out when asking for v4 and v6 without single-request option
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact owner@bugs.debian.org
immediately.)


-- 
554188: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=554188
Debian Bug Tracking System
Contact owner@bugs.debian.org with problems
--- Begin Message ---
Package: libc6
Version: 2.10.1-5
Severity: normal

Hi.  I've found that if I use MIT Kerberos, or any other application
that requests both v4 and v6 addresses at the same time I get a 5
second delay in each call to getaddrinfo with high probability.  There
is obviously a race condition: sometimes (order closer to 1/16 than
1/4 or 1/64) it returns quickly.  If you take a look at a packet
capture  at http://web.mit.edu/hartmans/Public/domain-simple.cap
you will see
* Two separate queries for AAAA and A records
* Responses to these queries
* five second delay
* retransmit of one of the queries
* a response

That's one call to getaddrinfo 

If I include the options single-request line in resolv.conf then things return fast as expected.

Tests were run against name servers that were on the local network (or
on localhost) with the responses already cached.

Here's sample c++ code:

std::string s = "kerberos.mit.edu";
bool numeric = false;

  addrinfo  hints;
  memset(&hints, 0, sizeof(hints));
  if (numeric)
    hints.ai_flags |= AI_NUMERICHOST;
  else hints.ai_flags |= AI_ADDRCONFIG;
  addrinfo *res;
  int ret = getaddrinfo(s.c_str(), NULL, &hints, &res);

If you set hints.ai_family to AF_INET6 or AF_INET then you get a fast response.



-- System Information:
Debian Release: squeeze/sid
  APT prefers testing
  APT policy: (500, 'testing'), (500, 'stable'), (40, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 2.6.30-2-amd64 (SMP w/2 CPU cores)
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)
Shell: /bin/sh linked to /bin/bash

Versions of packages libc6 depends on:
ii  libc-bin                      2.10.1-5   GNU C Library: Binaries
ii  libgcc1                       1:4.4.1-4  GCC support library

libc6 recommends no packages.

Versions of packages libc6 suggests:
ii  debconf [debconf-2.0]         1.5.26     Debian configuration management sy
ii  glibc-doc                     2.9-4      GNU C Library: Documentation
pn  locales                       <none>     (no description available)

-- debconf information:
  glibc/upgrade: true
  glibc/disable-screensaver:
  glibc/restart-failed:
* glibc/restart-services: spamassassin rsync postfix openbsd-inetd cups cron atd



--- End Message ---
--- Begin Message ---
Hi.  After looking into this more,
I misread my packet capture initially.
It seems like some sort of complex networking issue on my end.


--- End Message ---

Reply to: