Bug#329745: mtr-tiny: Contradictory output when there is a failure in name resolution
On Sun, Oct 02, 2005 at 08:54:49AM -0700, Robert Woodcock wrote:
On Sun, Oct 02, 2005 at 01:32:48AM -0300, Nelson A. de Oliveira wrote:
On 9/27/05, Rogier Wolff [EMAIL PROTECTED] wrote:
Yes, somehow, it calls a function that fails, but the errno variable
indicates no specification as to what system call when wrong or why: The
system calls all worked, just the name server told can't resolve this.
I agree it's confusing. I'm not familiar with the code that
generates that message.
Maybe forward this to upstream and change severity to wishlist?
Well, you already have an answer from Rogier, who *is* upstream.
The weird thing is, *neither* the Temporary failure in name resolution
string nor the Success string appear anywhere in mtr source. Just about
all of the DNS code returns responses that start with Resolver: or
Resolver error: So it's a bit difficult to figure out exactly what sort of
DNS response causes that message to appear (and therefore, what code path is
being taken within mtr).
One exception to that is this chunk in mtr.c line 392ish:
#ifdef ENABLE_IPV6
/* gethostbyname2() is deprecated so we'll use getaddrinfo() instead. */
bzero( hints, sizeof hints );
hints.ai_family = af;
hints.ai_socktype = SOCK_DGRAM;
error = getaddrinfo( Hostname, 0, hints, res );
if ( error ) {
perror( gai_strerror(error) );
exit( EXIT_FAILURE );
}
I'm not sure that gai_strerror should be wrapped in perror like that - it
could be that getaddrinfo does not set errno, or it could also be that
gai_strerror resets errno. I think that a safer thing to do would be to
check if error == EAI_SYSTEM. If so, use the output from perror. If not, use
the output from gai_strerror. But never use the output from both.
To get to the bottom of it we'd need to be able to replicate the bug. Would
you be able to tell us how to configure a DNS server to be broken like yours
was?
Robert, It certainly looks as if code like this is the culprit. Yes, the
Success string comes from
errno = 0;
perror ();
Roger.
--
Robert Woodcock - [EMAIL PROTECTED]
By metaphorically, I mean get in the car.
-- Bender
--
** [EMAIL PROTECTED] ** http://www.BitWizard.nl/ ** +31-15-2600998 **
*-- BitWizard writes Linux device drivers for any device you may have! --*
Q: It doesn't work. A: Look buddy, doesn't work is an ambiguous statement.
Does it sit on the couch all day? Is it unemployed? Please be specific!
Define 'it' and what it isn't doing. - Adapted from lxrbot FAQ
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#329745: mtr-tiny: Contradictory output when there is a failure in name resolution
On Sun, Oct 02, 2005 at 01:32:48AM -0300, Nelson A. de Oliveira wrote:
On 9/27/05, Rogier Wolff [EMAIL PROTECTED] wrote:
Yes, somehow, it calls a function that fails, but the errno variable
indicates no specification as to what system call when wrong or why: The
system calls all worked, just the name server told can't resolve this.
I agree it's confusing. I'm not familiar with the code that
generates that message.
Maybe forward this to upstream and change severity to wishlist?
Well, you already have an answer from Rogier, who *is* upstream.
The weird thing is, *neither* the Temporary failure in name resolution
string nor the Success string appear anywhere in mtr source. Just about
all of the DNS code returns responses that start with Resolver: or
Resolver error: So it's a bit difficult to figure out exactly what sort of
DNS response causes that message to appear (and therefore, what code path is
being taken within mtr).
One exception to that is this chunk in mtr.c line 392ish:
#ifdef ENABLE_IPV6
/* gethostbyname2() is deprecated so we'll use getaddrinfo() instead. */
bzero( hints, sizeof hints );
hints.ai_family = af;
hints.ai_socktype = SOCK_DGRAM;
error = getaddrinfo( Hostname, 0, hints, res );
if ( error ) {
perror( gai_strerror(error) );
exit( EXIT_FAILURE );
}
I'm not sure that gai_strerror should be wrapped in perror like that - it
could be that getaddrinfo does not set errno, or it could also be that
gai_strerror resets errno. I think that a safer thing to do would be to
check if error == EAI_SYSTEM. If so, use the output from perror. If not, use
the output from gai_strerror. But never use the output from both.
To get to the bottom of it we'd need to be able to replicate the bug. Would
you be able to tell us how to configure a DNS server to be broken like yours
was?
--
Robert Woodcock - [EMAIL PROTECTED]
By metaphorically, I mean get in the car.
-- Bender
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#329745: mtr-tiny: Contradictory output when there is a failure in name resolution
Hi! On 9/27/05, Rogier Wolff [EMAIL PROTECTED] wrote: (...) While using mtr and with the DNS server still with problem, I saw this: $ mtr http.us.debian.org Temporary failure in name resolution: Success This look contradictory, at least to me. If it failed resolving the machine name, it prints Success? Yes, somehow, it calls a function that fails, but the errno variable indicates no specification as to what system call when wrong or why: The system calls all worked, just the name server told can't resolve this. I agree it's confusing. I'm not familiar with the code that generates that message. Maybe forward this to upstream and change severity to wishlist? Cheers Nelson
Bug#329745: mtr-tiny: Contradictory output when there is a failure in name resolution
Package: mtr-tiny Version: 0.69-2 Severity: minor Hi! Today one machine that I have access was failing in resolving names, due to a problem on our DNS server. While using mtr and with the DNS server still with problem, I saw this: $ mtr http.us.debian.org Temporary failure in name resolution: Success This look contradictory, at least to me. If it failed resolving the machine name, it prints Success? Thank you! Nelson -- System Information: Debian Release: testing/unstable Architecture: i386 (i686) Shell: /bin/sh linked to /bin/dash Kernel: Linux 2.6.13-rc5-mm1 Locale: LANG=pt_BR, LC_CTYPE=pt_BR (charmap=ISO-8859-1) (ignored: LC_ALL set to pt_BR) Versions of packages mtr-tiny depends on: ii libc6 2.3.5-6GNU C Library: Shared libraries an ii libncurses5 5.4-9 Shared libraries for terminal hand mtr-tiny recommends no packages. -- no debconf information
