Bug#389270: additional information
Matthias Andree [EMAIL PROTECTED] schrieb: And who and what would change resolv.conf between off- and online, and why is that necessary? AFAICT, pppd with option usepeerdns does change /etc/resolv.conf. See http://lists.debian.org/debian-user/2001/08/msg00054.html or http://www.debian.org/releases/stable/i386/ch07s02.html.en Ciao, Eike PS: As I had to change my network configuration, the bug isn't happening here anymore. pgpp39JT4Y0HO.pgp Description: PGP signature
Bug#389270: additional information
Hi, On Tue, Dec 05, 2006 at 08:31:05AM +0100, Matthias Andree wrote: And who and what would change resolv.conf between off- and online, and why is that necessary? In my case, the nameservers are configured via DHCP only after the PPP link is established. Also, when I connect my notebook to a different network, I want to reconfigure my connection settings without having to reboot. Is there sustainable evidence that resolv.conf changes between off- and online? At least once, for the initial connection (after reboot or after moving to a different network), it does. Is really *stale* nameserver information cached inside libc or in fetchmail's context on behalf of libc's or libresolv's code? If so, it's still a libc/libresolv bug. Yes. I've seen discussion about this here [1]. Apparently the concern is the additional workload of checking for an updated resolv.conf all the time. Regards, Clemens [1] http://lists.freebsd.org/pipermail/freebsd-arch/2005-August/004245.html -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#389270: [pkg-fetchmail-maint] Bug#389270: additional information
Hi,
On Thu, Nov 30, 2006 at 11:05:05PM +0100, Matthias Andree wrote:
Clemens Buchacher schrieb:
Not so. I don't know about the original fetchmail code, but the fetchmail
Debian package provides its own implementation of getaddrinfo.
Where and how does it do that?
I was referring to the implementation in libesmtp/getaddrinfo.c, which is
used if the system does not provide a getaddrinfo function. That seemed to
be the only explanation why my change worked. I see now that I was wrong.
Anyways, the real problem seems to be the same as in bug #391698 [1]. The
nameserver configuration (/etc/resolv.conf) is only read during the first
call to getaddrinfo.
For illustration, I have appended a patch which fixes the problem, even if
fetchmail is not restarted in /etc/resolvconf/update-libc.d/fetchmail.
I suppose the current solution is preferable, however.
Regards,
Clemens
[1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=391698
--- fetchmail-6.3.4/driver.c2006-03-31 14:10:20.0 +0200
+++ fetchmail-6.3.4.new/driver.c2006-12-04 20:19:37.0 +0100
@@ -39,6 +39,8 @@
#include hesiod.h
#endif
+#include resolv.h
+
#include langinfo.h
#include kerberos.h
@@ -1017,6 +1019,9 @@
error = getaddrinfo(ctl-server.queryname, NULL, hints, res);
if (error)
{
+ if (error == EAI_AGAIN)
+ _res.options = ~RES_INIT;
+
report(stderr,
GT_(couldn't find canonical DNS name of %s (%s)\n),
ctl-server.pollname, ctl-server.queryname);
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#389270: additional information
Clemens Buchacher schrieb am 2006-12-04: Anyways, the real problem seems to be the same as in bug #391698 [1]. The nameserver configuration (/etc/resolv.conf) is only read during the first call to getaddrinfo. And who and what would change resolv.conf between off- and online, and why is that necessary? Is there sustainable evidence that resolv.conf changes between off- and online? Is really *stale* nameserver information cached inside libc or in fetchmail's context on behalf of libc's or libresolv's code? If so, it's still a libc/libresolv bug. For illustration, I have appended a patch which fixes the problem, even if fetchmail is not restarted in /etc/resolvconf/update-libc.d/fetchmail. I suppose the current solution is preferable, however. And unfortunately, neither using a documented interface nor is it portable, so not suitable for the upstream. It also requires linking with -lresolv according to my resolver(3) manpage (SUSE 10.0 though, not Debian). This will be the case as long as res_search is only in libresolv, but not in libc - just as a hint for the packagers (Nico, Héctor). Thank you for your information though. -- Matthias Andree -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#389270: [pkg-fetchmail-maint] Bug#389270: additional information
Hi, On Tue, Nov 28, 2006 at 09:55:14PM +0100, Matthias Andree wrote: Clemens Buchacher [EMAIL PROTECTED] writes: The appended change fixes the problem for me. ...and is evidence that the libc used is broken: res is supposed to contain garbage because getaddrinfo() wasn't successful and res wasn't initialized. I see. If there is a connection, the request succeeds: [EMAIL PROTECTED]:~/tmp$ ./gaitest success, trying to free stuff. This is what I get, when no nameservers are available: [EMAIL PROTECTED]:~/tmp$ ./gaitest ; echo $? gai error: Temporary failure in name resolution ai is: 0xdeadbeef attempting to free ai... caught sigsegv, aborting! 1 ii libc6 2.3.6.ds1-8GNU C Library: Shared libraries Regards, Clemens -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#389270: [pkg-fetchmail-maint] Bug#389270: additional information
Clemens Buchacher schrieb: I see. If there is a connection, the request succeeds: [EMAIL PROTECTED]:~/tmp$ ./gaitest success, trying to free stuff. Your name server is broken. I'm requesting a guaranteed-to-be-invalid DNS name, there should not be success. This is what I get, when no nameservers are available: [EMAIL PROTECTED]:~/tmp$ ./gaitest ; echo $? gai error: Temporary failure in name resolution ai is: 0xdeadbeef attempting to free ai... caught sigsegv, aborting! 1 I wonder how your patch can then work without crashing fetchmail. Strange... -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#389270: [pkg-fetchmail-maint] Bug#389270: additional information
Hi, On Thu, Nov 30, 2006 at 08:31:19PM +0100, Matthias Andree wrote: Your name server is broken. I'm requesting a guaranteed-to-be-invalid DNS name, there should not be success. No. This is how getaddrinfo behaves if a search list is given in /etc/resolv.conf. In my case, the valid host name invalid.dyndns.org is returned. I wonder how your patch can then work without crashing fetchmail. Strange... Not so. I don't know about the original fetchmail code, but the fetchmail Debian package provides its own implementation of getaddrinfo. Regards, Clemens -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#389270: [pkg-fetchmail-maint] Bug#389270: additional information
Clemens Buchacher schrieb: I wonder how your patch can then work without crashing fetchmail. Strange... Not so. I don't know about the original fetchmail code, but the fetchmail Debian package provides its own implementation of getaddrinfo. Where and how does it do that? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#389270: [pkg-fetchmail-maint] Bug#389270: additional information
Clemens Buchacher [EMAIL PROTECTED] writes:
The appended change fixes the problem for me.
...and is evidence that the libc used is broken: res is supposed to
contain garbage because getaddrinfo() wasn't successful and res wasn't
initialized.
Please be sure to have gcc and other compilation stuff installed,
then save the attached program to gaitest.c,
then type:
gcc -O -o gaitest gaitest.c
./gaitest ; echo $?
and paste the output.
Please include information on your libc (use dpkg).
Expected output:
-
gai error: Name or service not known
ai is: 0xdeadbeef - this is a sentinel initialization...
attempting to free ai...
caught sigsegv, aborting!
1
-
It doesn't make a difference with Temporary failure in name resolution
either.
And this happens on FreeBSD 6.2-PRERELEASE i686, a fully patched Solaris
8/SPARC, SUSE Linux 9.2 i686, 10.0 i686, NetBSD 3.1 i386 - so taking the
patch upstream would make matters worse.
--
Matthias Andree
#include sys/socket.h
#include netdb.h
#include stdlib.h
#include stdio.h
#include string.h
#include signal.h
#include unistd.h
void catchsegv(int sig)
{
const char *es = caught sigsegv, aborting!\n;
(void)sig;
write(2, es, strlen(es));
_exit(EXIT_FAILURE);
}
int main(void) {
struct addrinfo *ai = 0xdeadbeef;
struct addrinfo hints;
int e;
signal(SIGSEGV, catchsegv);
memset(hints, 0, sizeof(hints));
hints.ai_socktype = SOCK_STREAM;
hints.ai_family = AF_UNSPEC;
hints.ai_flags = AI_CANONNAME;
e = getaddrinfo(invalid.invalid, NULL, hints, ai);
if (e) {
fprintf(stderr, gai error: %s\nai is: %p\n\nattempting to free
ai...\n, gai_strerror(e), (void *)ai);
freeaddrinfo(ai);
fprintf(stderr, OK, freeing seems to have worked.\n);
exit(EXIT_FAILURE);
}
fprintf(stderr, success, trying to free stuff.\n);
freeaddrinfo(ai);
exit(EXIT_SUCCESS);
}
Bug#389270: additional information
Hi, On Wed, Nov 22, 2006 at 06:34:34PM +0100, Nico Golde wrote: Will be fixed with the next upload, we just changed the awaken to a restart in the init script since fetchmail is really not able to notice when the environment changes. The appended change fixes the problem for me. Cheers, Clemens --- fetchmail-6.3.4/driver.c2006-03-31 14:10:20.0 +0200 +++ fetchmail-6.3.4.new/driver.c2006-11-27 19:35:02.0 +0100 @@ -1020,6 +1020,7 @@ report(stderr, GT_(couldn't find canonical DNS name of %s (%s)\n), ctl-server.pollname, ctl-server.queryname); + freeaddrinfo(res); err = PS_DNS; set_timeout(0); phase = oldphase; -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#389270: [pkg-fetchmail-maint] Bug#389270: additional information
On Wed, Nov 22, 2006 at 01:50:01AM +0100, Matthias Andree wrote: Nagy Gabor Peter [EMAIL PROTECTED] writes: So my impression is that it doesn't ask the DNS when it tries to connect to the servers AFAICT, fetchmail calls getaddrinfo() each and every time when connecting. well, perhaps we are talking about a problem in getaddrinfo() then? or a function call or configuration option that tells libc to not store negative name resolution queries? (eg dnsmasq has such an option) Florian signature.asc Description: Digital signature
Bug#389270: additional information
Hi, * Nagy Gabor Peter [EMAIL PROTECTED] [2006-11-22 03:08]: So I hope this helps to find the problem: I am running etch on a laptop. When I have ethernet connection to a working DNS server when fetchmail is started, it fetches the emails all right. Like I am in an office, pop3 is not allowed to the outside, but DNS works. After login I start my vpn, and through the vpn link the next time fetchmail awakens, it fetches all my mail. But if I don't have a working DNS when I start my machine (like no network at all), fetchmail tries to resolve the names, and fails. So far it's OK. [...] Will be fixed with the next upload, we just changed the awaken to a restart in the init script since fetchmail is really not able to notice when the environment changes. Kind regards Nico -- Nico Golde - http://www.ngolde.de JAB: [EMAIL PROTECTED] - GPG: 0x73647CFF Forget about that mouse with 3/4/5 buttons, gimme a keyboard with 103/104/105 keys! pgpCWblTWAF6d.pgp Description: PGP signature
