-
Notifications
You must be signed in to change notification settings - Fork 341
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fixed to handle case where only IPv6 nameservers are specified #56
Conversation
… IPv6 nameservers are specified.
The underscores in the field name for the ns6count seem to indicate that this is a private field. Isn't there a more proper (portable) way to get at the ns6count field? |
…clude IPv6 nameservers.
rewolff, thanks for getting back to me. It doesn't seem like there's a more proper/portable way. I've fixed it up so this should only apply if GLIBC is defined. What do you think? |
I've done a bit more research.... We are messing with the internals of the _res variable, which is documented as having just one user-accessible field. And we're messing with a bunch of others. The code is already not-portable, but seems to work. Can you remove the check for __glibc then I'll merge. If you want a nice weekend project: Rewrite dns.c: Every lookup request: fork, call the system resolver, report the result, exit. This will cause a flurry of extra mtr-processes every time you start mtr. Modern machines can handle that.... (improvement once that works: If available, use threads. ) I'm not very good with git. Let me try if I can do the "remove glibc check" myself. |
The NSCOUNT define is missing for when ipv6 is not enabled/available. |
Fancy! I pulled from your repo, changed a few things, then pushed to github, and it immediately notices in my web-browser that the repo now contains your patch/pull request, so it auto-closes this pull........ |
haha fancy indeed! Thank you so much for spending the time reviewing, On 15 August 2014 19:50, rewolff notifications@github.com wrote:
|
rewolff, I think we should only use ncount6 for glibc. It seems that libc used by FreeBSD and possibly others doesn't have that member and IPv6 nameservers are included in ncount: e.g. http://svnweb.freebsd.org/base/head/lib/libc/resolv/res_init.c?revision=269867&view=markup#l225 and http://svnweb.freebsd.org/base/head/lib/libc/resolv/res_init.c?revision=269867&view=markup#l870 |
On Fri, 15 Aug 2014, rewolff wrote:
This latest change causes mtr to look for resolver structs that don't Antonio Querubin |
I'm attaching a short program that I've been using to figure out how Antonio Querubin |
@hloeung , Does that "only glibc" address Antonio's objections? |
On Fri, 15 Aug 2014, rewolff wrote:
Previous to this latest commit I had verified mtr was working with only Linux Mint 17
Looks like the github mail server filters attachments. I'll repost the I don't mean to belabor this point but in case it's not clear, the idea is nscount = the number of listed resolvers in /etc/resolv.conf nscount6 (if it exists) = the number of IPv6 resolvers in /etc/resolv.conf So nscount6 (if it exists) <= nscount Attempting to querying nscount+nscount6 resolvers does not make sense when The short program that follows below dumps out nscount, nscount6 (if it // Short program to debug resolver issues. -aq #include <netinet/in.h> #include <arpa/inet.h> #include <string.h> #ifdef GLIBC #ifndef __res_state_ext #ifdef res_ninit int satop(struct sockaddr *sa, char *dst, socklen_t size); int main(int argc, char **argv) { #ifdef GLIBC MY_RES_INIT(); printf("res_state.nscount = %d\n", myres.nscount); if (!myres.nscount) { for (i = 0; i < myres.nscount; i++) { return(0); /* Convert a sockaddr to a printable address. */ af = sa->sa_family; switch (af) { }
Virtualization is your friend. It's amazingly easy to boot an ISO image Antonio Querubin |
@rewolff yes that "only glibc" addresses Antonio's issue. @aquerubin nscount only counts IPv6 addresses. Example program I used for testing: | #include <stdio.h> My resolv.conf: | nameserver ::1 Output from program is shows nscount as 0 as glibc (2.19) only counts IPv4 addresses. This currently affects both Ubuntu[1] and Debian[2] users. ulibc code also notes nscount as a count for only IPv4 nameservers[3]. [1] https://bugs.launchpad.net/ubuntu/+source/mtr/+bug/752583 |
#57 to revert previous changes. |
On Fri, 15 Aug 2014, Haw Loeung wrote:
Really? I just checked the latest Debian release 7.6 and nscount includes The latest Linux Mint 17 (Ubuntu derivative) also shows nscount includes Antonio Querubin |
Yeah, I mentioned this in #57 to revert my set of changes. https://lists.debian.org/debian-glibc/2014/06/msg00138.html I've also reported it upstream to Debian in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=528992 |
On Sat, 16 Aug 2014, Haw Loeung wrote:
So this affects only the Debian testing release "jessie". Which might Antonio Querubin |
Guys. Are you willing to test a new approach to the DNS lookups? Check out the "newdns" branch. The idea is to use the interface that the OS provides to lookup names from IP addresses. I'm not sure it works yet for IPV6 so let me know if you can test and if it works or not. Here the new version already resolves one IP address that "stock" mtr does not resolve (my local ADSL modem has an entry in /etc/hosts, but nothing in DNS). For a short while after startup there will be a whole bunch of mtr-processes each doing a name lookup. Might look a bit weird, but that's how it is supposed to work. Oh... The good news: "dns.c" was reduced by about 80%. |
On Sun, 17 Aug 2014, rewolff wrote:
There's some kind of corruption going on in the output display when Antonio Querubin |
On Sun, 17 Aug 2014, rewolff wrote:
Some corrections below to fix the output corruption. diff --git a/dns.c b/dns.c
Antonio Querubin |
On Sun, 17 Aug 2014, rewolff wrote:
Another cumulative diff - hostnames can be very long.
@@ -191,11 +191,11 @@ void dns_open(void)
@@ -243,12 +243,12 @@ int dns_waitfd (void) void dns_ack(void)
r = findip (ip); Antonio Querubin |
On Sun, 17 Aug 2014, rewolff wrote:
Another cumulative diff. diff --git a/dns.c b/dns.c
@@ -191,11 +191,11 @@ void dns_open(void)
- hostname, 0x100, NULL, 0, 0);- sprintf (result, "%s %s\n", strlongip (&host), hostname);
r = findip (ip); Antonio Querubin |
I'm curious in why fork processes for DNS resolution? If it's to speed up lookups and get around blocking caused by the system resolver why not look into switching to some asynchronous DNS lookup library? |
Antonio: I forgot to say: this is a proof-of-concept, There is a whole lot of "fixed size buffers" that need enlarging or making-dynamic.... That's on my todo list, provided that the strategy works. MTR has had a whole stream of bugs because we were using our own DNS lookup. If say IPV7 comes out, we can be sure that the system lookup functions will still work. But not that the DNS library that we selected in 2014 is still being maintained... |
although I have my objections, I searched for asynchronous DNS and examined the top two hits:
|
And THIS: #59 my friends is why MTR should not use internal structures of the resolver..... |
@rewolff How about libev or libevent together with getnameinfo() to implement non-blocking DNS? Or even eventdns which you can bundle with mtr? https://www.imperialviolet.org/binary/eventdns.c |
newdns branch fails to build on redhat derivatives. Apparently they need diff --git a/dns.c b/dns.c #include "mtr.h" Antonio Querubin |
Apparently FreeBSD is a bit more picky about sockaddr lengths passed to diff --git a/dns.c b/dns.c
Antonio Querubin |
At present, mtr will abort when only IPv6 nameservers are specified in /etc/resolv.conf as reported in https://bugs.launchpad.net/ubuntu/+source/mtr/+bug/752583. This fixes that by including a count of all IPv6 nameservers.