* ipset causes reverse dns lookups?
@ 2012-04-15 23:26 Ed W
2012-04-16 1:15 ` Ed W
0 siblings, 1 reply; 11+ messages in thread
From: Ed W @ 2012-04-15 23:26 UTC (permalink / raw)
To: netfilter
Hi, ipset appears to require a reverse dns lookup for say:
ipset create cp bitmap:ip,mac range 192.168.111.0/24
Why?
In particular if I lock down iptables (-P DROP), then the above command
takes quite some seconds to complete, rather than instantly if I open up
iptables. This is causing me some problems with startup scripts
Am I missing some configuration option? Is this a bug? Why is a reverse
DNS lookup needed?
ipset 6.9.1, kernel 3.2.13
Thanks
Ed W
^ permalink raw reply [flat|nested] 11+ messages in thread* Re: ipset causes reverse dns lookups? 2012-04-15 23:26 ipset causes reverse dns lookups? Ed W @ 2012-04-16 1:15 ` Ed W 2012-04-16 3:23 ` Ed W 0 siblings, 1 reply; 11+ messages in thread From: Ed W @ 2012-04-16 1:15 UTC (permalink / raw) To: netfilter On 16/04/2012 00:26, Ed W wrote: > In particular if I lock down iptables (-P DROP), then the above > command takes quite some seconds to complete, rather than instantly if > I open up iptables. This is causing me some problems with startup > scripts > > Am I missing some configuration option? Is this a bug? Why is a > reverse DNS lookup needed? eg $ iptables -I INPUT -j REJECT $ time ipset create cp2 bitmap:ip,mac range 192.168.1.1/24 ipset v6.9.1: Set cannot be created: set with the same name already exists Command exited with non-zero status 1 real 0m 45.11s user 0m 0.01s sys 0m 0.00s $ iptables -F $ time ipset create cp2 bitmap:ip,mac range 192.168.1.1/24 ipset v6.9.1: Set cannot be created: set with the same name already exists Command exited with non-zero status 1 real 0m 0.01s user 0m 0.00s sys 0m 0.00s /var/log/messages: Apr 16 01:14:55 localhost daemon.info dnsmasq[6272]: query[PTR] 1.1.168.192.in-addr.arpa from 127.0.0.1 Apr 16 01:14:55 localhost daemon.info dnsmasq[6272]: config 192.168.1.1 is NXDOMAIN-IPv4 What am I doing wrong? ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: ipset causes reverse dns lookups? 2012-04-16 1:15 ` Ed W @ 2012-04-16 3:23 ` Ed W 2012-04-16 8:08 ` Jozsef Kadlecsik 0 siblings, 1 reply; 11+ messages in thread From: Ed W @ 2012-04-16 3:23 UTC (permalink / raw) To: netfilter On 16/04/2012 02:15, Ed W wrote: > On 16/04/2012 00:26, Ed W wrote: >> In particular if I lock down iptables (-P DROP), then the above >> command takes quite some seconds to complete, rather than instantly >> if I open up iptables. This is causing me some problems with startup >> scripts >> >> Am I missing some configuration option? Is this a bug? Why is a >> reverse DNS lookup needed? > > eg > > $ iptables -I INPUT -j REJECT > $ time ipset create cp2 bitmap:ip,mac range 192.168.1.1/24 > ipset v6.9.1: Set cannot be created: set with the same name already > exists > Command exited with non-zero status 1 > real 0m 45.11s > user 0m 0.01s > sys 0m 0.00s I upgraded to ipset 6.11 and note the same issue. I also just discovered I can repro this when adding to a set, eg: $ time /usr/sbin/ipset -! -q add cp2 192.168.105.56,58:b0:35:78:0d:f5 Command exited with non-zero status 1 real 1m 0.09s user 0m 0.00s sys 0m 0.01s In this case I have multiple internet connections. Pushing IPs into an ipset forces that ip over a particular connection. If the box is currently on some non responsive network, then the resolver isn't working correctly and ipset is consequently also slow. Any ideas how I can get out of this? Thanks Ed W ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: ipset causes reverse dns lookups? 2012-04-16 3:23 ` Ed W @ 2012-04-16 8:08 ` Jozsef Kadlecsik 2012-04-16 8:37 ` Ed W 0 siblings, 1 reply; 11+ messages in thread From: Jozsef Kadlecsik @ 2012-04-16 8:08 UTC (permalink / raw) To: Ed W; +Cc: netfilter On Mon, 16 Apr 2012, Ed W wrote: > On 16/04/2012 02:15, Ed W wrote: > > On 16/04/2012 00:26, Ed W wrote: > > > In particular if I lock down iptables (-P DROP), then the above command > > > takes quite some seconds to complete, rather than instantly if I open up > > > iptables. This is causing me some problems with startup scripts > > > > > > Am I missing some configuration option? Is this a bug? Why is a reverse > > > DNS lookup needed? > > > > eg > > > > $ iptables -I INPUT -j REJECT > > $ time ipset create cp2 bitmap:ip,mac range 192.168.1.1/24 > > ipset v6.9.1: Set cannot be created: set with the same name already exists > > Command exited with non-zero status 1 > > real 0m 45.11s > > user 0m 0.01s > > sys 0m 0.00s > > I upgraded to ipset 6.11 and note the same issue. I also just discovered I > can repro this when adding to a set, eg: > > $ time /usr/sbin/ipset -! -q add cp2 192.168.105.56,58:b0:35:78:0d:f5 > Command exited with non-zero status 1 > real 1m 0.09s > user 0m 0.00s > sys 0m 0.01s > > In this case I have multiple internet connections. Pushing IPs into an ipset > forces that ip over a particular connection. If the box is currently on some > non responsive network, then the resolver isn't working correctly and ipset is > consequently also slow. Hostname and IP address are both supported as input and resolved internally by getaddrinfo. That can generate DNS lookups, depeding on the resolver library. What kind of system do you use, with which resolver/libc version? I could suppress DNS lookups with the price of calling twice getaddrinfo. Best regards, Jozsef - E-mail : kadlec@blackhole.kfki.hu, kadlecsik.jozsef@wigner.mta.hu PGP key : http://www.kfki.hu/~kadlec/pgp_public_key.txt Address : Wigner Research Centre for Physics, Hungarian Academy of Sciences H-1525 Budapest 114, POB. 49, Hungary ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: ipset causes reverse dns lookups? 2012-04-16 8:08 ` Jozsef Kadlecsik @ 2012-04-16 8:37 ` Ed W 2012-04-16 9:55 ` Jozsef Kadlecsik 0 siblings, 1 reply; 11+ messages in thread From: Ed W @ 2012-04-16 8:37 UTC (permalink / raw) To: Jozsef Kadlecsik; +Cc: netfilter On 16/04/2012 09:08, Jozsef Kadlecsik wrote: > Hostname and IP address are both supported as input and resolved > internally by getaddrinfo. That can generate DNS lookups, depeding on the > resolver library. What kind of system do you use, with which > resolver/libc version? Thanks so much for replying! This is a uclibc 0.9.33.1 system, x86. Resolver chain is /etc/hosts, then dns. Local dnsmasq is installed. I can very clearly observe that on something like "ipset add", if I add something that isn't quite an IP address then it generates a name lookup. What I'm confused by is why the reverse ip lookup for the ip address? I have traced it back I think to the parser.c code, but I concede I'm stuck understanding even what is generating the lookup? You mention resolver, so presumably it's a side effect of some other call, but could you spare a minute to explain the trigger please? (just interested in the background in case it occurs elsewhere?) > I could suppress DNS lookups with the price of calling twice getaddrinfo. You are presumably giving me a clue as the source here! It would not appear to be a significant performance decrease for the normal situation to call twice? Given the outside edge case of 1+ min delays I'm definitely interested in such a change? Is there any chance of a tentative patch or at least a stronger hint at what I should change in order that I could deploy something quite imminently? Its become a bit of a blocker here... Obviously I'm asking with as much icing as possible and a huge cherry on top... Thanks Jozsef Ed W ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: ipset causes reverse dns lookups? 2012-04-16 8:37 ` Ed W @ 2012-04-16 9:55 ` Jozsef Kadlecsik 2012-04-16 13:08 ` Amos Jeffries 2012-04-16 13:14 ` Ed W 0 siblings, 2 replies; 11+ messages in thread From: Jozsef Kadlecsik @ 2012-04-16 9:55 UTC (permalink / raw) To: Ed W; +Cc: netfilter On Mon, 16 Apr 2012, Ed W wrote: > On 16/04/2012 09:08, Jozsef Kadlecsik wrote: > > Hostname and IP address are both supported as input and resolved > > internally by getaddrinfo. That can generate DNS lookups, depeding on the > > resolver library. What kind of system do you use, with which > > resolver/libc version? > > Thanks so much for replying! > > This is a uclibc 0.9.33.1 system, x86. Resolver chain is /etc/hosts, then dns. > Local dnsmasq is installed. > > I can very clearly observe that on something like "ipset add", if I add > something that isn't quite an IP address then it generates a name lookup. What > I'm confused by is why the reverse ip lookup for the ip address? I have > traced it back I think to the parser.c code, but I concede I'm stuck > understanding even what is generating the lookup? You mention resolver, so > presumably it's a side effect of some other call, but could you spare a minute > to explain the trigger please? (just interested in the background in case it > occurs elsewhere?) That comes from the implementation of "getaddrinfo" in uclibc then. ipset itself does not force reverse DNS lookups. > > I could suppress DNS lookups with the price of calling twice getaddrinfo. > > You are presumably giving me a clue as the source here! > > It would not appear to be a significant performance decrease for the normal > situation to call twice? Given the outside edge case of 1+ min delays I'm > definitely interested in such a change? > > Is there any chance of a tentative patch or at least a stronger hint at what I > should change in order that I could deploy something quite imminently? Its > become a bit of a blocker here... Obviously I'm asking with as much icing as > possible and a huge cherry on top... Try the following untested patch: diff --git a/lib/parse.c b/lib/parse.c index 30efdb6..8b86492 100644 --- a/lib/parse.c +++ b/lib/parse.c @@ -8,6 +8,7 @@ #include <errno.h> /* errno */ #include <limits.h> /* ULLONG_MAX */ #include <netdb.h> /* getservbyname, getaddrinfo */ +#include <string.h> /* str* */ #include <stdlib.h> /* strtoull, etc. */ #include <sys/types.h> /* getaddrinfo */ #include <sys/socket.h> /* getaddrinfo, AF_ */ @@ -687,6 +688,18 @@ call_getaddrinfo(struct ipset_session *session, const char *str, hints.ai_protocol = 0; hints.ai_next = NULL; + if (family == NFPROTO_IPV6) { + if (strchr(str, ':') != NULL) + hints.ai_flags |= AI_NUMERICHOST; + } else { + if (strspn(str, "0123456789.") == strlen(str)) + hints.ai_flags |= AI_NUMERICHOST; + } + if ((err = getaddrinfo(str, NULL, &hints, &res)) != 0) + hints.ai_flags &= ~AI_NUMERICHOST; + else + return res; + if ((err = getaddrinfo(str, NULL, &hints, &res)) != 0) { syntax_err("cannot resolve '%s' to an %s address: %s", str, family == NFPROTO_IPV6 ? "IPv6" : "IPv4", Best regards, Jozsef - E-mail : kadlec@blackhole.kfki.hu, kadlecsik.jozsef@wigner.mta.hu PGP key : http://www.kfki.hu/~kadlec/pgp_public_key.txt Address : Wigner Research Centre for Physics, Hungarian Academy of Sciences H-1525 Budapest 114, POB. 49, Hungary ^ permalink raw reply related [flat|nested] 11+ messages in thread
* Re: ipset causes reverse dns lookups? 2012-04-16 9:55 ` Jozsef Kadlecsik @ 2012-04-16 13:08 ` Amos Jeffries 2012-04-16 13:21 ` Jozsef Kadlecsik 2012-04-16 13:14 ` Ed W 1 sibling, 1 reply; 11+ messages in thread From: Amos Jeffries @ 2012-04-16 13:08 UTC (permalink / raw) To: Jozsef Kadlecsik; +Cc: Ed W, netfilter On 16/04/2012 9:55 p.m., Jozsef Kadlecsik wrote: > On Mon, 16 Apr 2012, Ed W wrote: > >> On 16/04/2012 09:08, Jozsef Kadlecsik wrote: >>> Hostname and IP address are both supported as input and resolved >>> internally by getaddrinfo. That can generate DNS lookups, depeding on the >>> resolver library. What kind of system do you use, with which >>> resolver/libc version? >> Thanks so much for replying! >> >> This is a uclibc 0.9.33.1 system, x86. Resolver chain is /etc/hosts, then dns. >> Local dnsmasq is installed. >> >> I can very clearly observe that on something like "ipset add", if I add >> something that isn't quite an IP address then it generates a name lookup. What >> I'm confused by is why the reverse ip lookup for the ip address? I have >> traced it back I think to the parser.c code, but I concede I'm stuck >> understanding even what is generating the lookup? You mention resolver, so >> presumably it's a side effect of some other call, but could you spare a minute >> to explain the trigger please? (just interested in the background in case it >> occurs elsewhere?) > That comes from the implementation of "getaddrinfo" in uclibc then. ipset > itself does not force reverse DNS lookups. FWIW, I have recently been dealing with user complains with other software when built with uclibc. The uclibc implementation has been caught ignoring AI_NUMERICHOST and performing full remote resolution when passed numeric IPs for conversion. AYJ ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: ipset causes reverse dns lookups? 2012-04-16 13:08 ` Amos Jeffries @ 2012-04-16 13:21 ` Jozsef Kadlecsik 0 siblings, 0 replies; 11+ messages in thread From: Jozsef Kadlecsik @ 2012-04-16 13:21 UTC (permalink / raw) To: Amos Jeffries; +Cc: Ed W, netfilter On Tue, 17 Apr 2012, Amos Jeffries wrote: > On 16/04/2012 9:55 p.m., Jozsef Kadlecsik wrote: > > On Mon, 16 Apr 2012, Ed W wrote: > > > > > On 16/04/2012 09:08, Jozsef Kadlecsik wrote: > > > > Hostname and IP address are both supported as input and resolved > > > > internally by getaddrinfo. That can generate DNS lookups, depeding on > > > > the > > > > resolver library. What kind of system do you use, with which > > > > resolver/libc version? > > > Thanks so much for replying! > > > > > > This is a uclibc 0.9.33.1 system, x86. Resolver chain is /etc/hosts, then > > > dns. > > > Local dnsmasq is installed. > > That comes from the implementation of "getaddrinfo" in uclibc then. ipset > > itself does not force reverse DNS lookups. > > FWIW, I have recently been dealing with user complains with other software > when built with uclibc. The uclibc implementation has been caught ignoring > AI_NUMERICHOST and performing full remote resolution when passed numeric IPs > for conversion. That'd bad, because then DNS lookup is always performed - and cannot be switched off. Hopefully they'll fix the issue in uclibc. Thanks the info. Best regards, Jozsef - E-mail : kadlec@blackhole.kfki.hu, kadlecsik.jozsef@wigner.mta.hu PGP key : http://www.kfki.hu/~kadlec/pgp_public_key.txt Address : Wigner Research Centre for Physics, Hungarian Academy of Sciences H-1525 Budapest 114, POB. 49, Hungary ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: ipset causes reverse dns lookups? 2012-04-16 9:55 ` Jozsef Kadlecsik 2012-04-16 13:08 ` Amos Jeffries @ 2012-04-16 13:14 ` Ed W 2012-04-16 13:20 ` Jozsef Kadlecsik 1 sibling, 1 reply; 11+ messages in thread From: Ed W @ 2012-04-16 13:14 UTC (permalink / raw) To: Jozsef Kadlecsik; +Cc: netfilter On 16/04/2012 10:55, Jozsef Kadlecsik wrote: > Try the following untested patch: > Thanks for the idea. I'm not 100% sure I'm testing correctly, but I rebuilt and I see no change... Does the following strace help any? $ /tmp/strace /tmp/ipset add cp2 192.168.105.56,58:b0:35:78:0d:f5 execve("/tmp/ipset", ["/tmp/ipset", "add", "cp2", "192.168.105.56,58:b0:35:78:0d:f5"], [/* 16 vars */]) = 0 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS|0x4000000, -1, 0) = 0x4f9cc000 stat("/etc/ld.so.cache", {st_mode=S_IFREG|0644, st_size=6754, ...}) = 0 open("/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3 mmap2(NULL, 6754, PROT_READ, MAP_SHARED, 3, 0) = 0x4f9ca000 close(3) = 0 stat("/etc/ld.so.preload", 0x5cc84aec) = -1 ENOENT (No such file or directory) open("/lib/libmnl.so.0", O_RDONLY) = 3 fstat(3, {st_mode=S_IFREG|0755, st_size=17580, ...}) = 0 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS|0x4000000, -1, 0) = 0x4f9c9000 read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0L\25\0\0004\0\0\0"..., 4096) = 4096 mmap2(NULL, 24576, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x4f9c3000 mmap2(0x4f9c3000, 13016, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_FIXED, 3, 0) = 0x4f9c3000 mmap2(0x4f9c7000, 4100, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 3, 0x3) = 0x4f9c7000 close(3) = 0 munmap(0x4f9c9000, 4096) = 0 open("/lib/libgcc_s.so.1", O_RDONLY) = 3 fstat(3, {st_mode=S_IFREG|0644, st_size=91276, ...}) = 0 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS|0x4000000, -1, 0) = 0x4f9c9000 read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0|\"\0\0004\0\0\0"..., 4096) = 4096 mmap2(NULL, 94208, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x4f9ac000 mmap2(0x4f9ac000, 85844, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_FIXED, 3, 0) = 0x4f9ac000 mmap2(0x4f9c1000, 4120, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 3, 0x15) = 0x4f9c1000 close(3) = 0 munmap(0x4f9c9000, 4096) = 0 open("/lib/libc.so.0", O_RDONLY) = 3 fstat(3, {st_mode=S_IFREG|0755, st_size=372132, ...}) = 0 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS|0x4000000, -1, 0) = 0x4f9c9000 read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0@\333\0\0004\0\0\0"..., 4096) = 4096 mmap2(NULL, 397312, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x4f94b000 mmap2(0x4f94b000, 365288, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_FIXED, 3, 0) = 0x4f94b000 mmap2(0x4f9a5000, 4904, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 3, 0x59) = 0x4f9a5000 mmap2(0x4f9a7000, 19752, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x4f9a7000 close(3) = 0 munmap(0x4f9c9000, 4096) = 0 open("/lib/libgcc_s.so.1", O_RDONLY) = 3 fstat(3, {st_mode=S_IFREG|0644, st_size=91276, ...}) = 0 close(3) = 0 open("/lib/libc.so.0", O_RDONLY) = 3 fstat(3, {st_mode=S_IFREG|0755, st_size=372132, ...}) = 0 close(3) = 0 open("/lib/libc.so.0", O_RDONLY) = 3 fstat(3, {st_mode=S_IFREG|0755, st_size=372132, ...}) = 0 close(3) = 0 stat("/lib/ld-uClibc.so.0", {st_mode=S_IFREG|0755, st_size=25236, ...}) = 0 munmap(0x4f9ca000, 6754) = 0 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS|0x4000000, -1, 0) = 0x4f9cb000 set_thread_area({entry_number:-1 -> 6, base_addr:0x4f9cb6a0, limit:1048575, seg_32bit:1, contents:0, read_exec_only:0, limit_in_pages:1, seg_not_present:0, useable:1}) = 0 open("/dev/urandom", O_RDONLY) = 3 read(3, "\254#\3\273", 4) = 4 close(3) = 0 mprotect(0x1409c000, 8192, PROT_READ) = 0 mprotect(0x4f9c7000, 4096, PROT_READ) = 0 mprotect(0x4f9c1000, 4096, PROT_READ) = 0 mprotect(0x4f9a5000, 4096, PROT_READ) = 0 mprotect(0x4f9d4000, 4096, PROT_READ) = 0 ioctl(0, SNDCTL_TMR_TIMEBASE or SNDRV_TIMER_IOCTL_NEXT_DEVICE or TCGETS, {B38400 opost isig icanon echo ...}) = 0 ioctl(1, SNDCTL_TMR_TIMEBASE or SNDRV_TIMER_IOCTL_NEXT_DEVICE or TCGETS, {B38400 opost isig icanon echo ...}) = 0 brk(0) = 0x142dc390 brk(0x142e0390) = 0x142e0390 brk(0x142e1000) = 0x142e1000 socket(PF_NETLINK, SOCK_RAW, 12) = 3 bind(3, {sa_family=AF_NETLINK, pid=0, groups=00000000}, 12) = 0 getsockname(3, {sa_family=AF_NETLINK, pid=11097, groups=00000000}, [12]) = 0 time(NULL) = 1334580838 sendto(3, "\34\0\0\0\1\6\1\0g\26\214O\0\0\0\0\2\0\0\0\5\0\1\0\6\0\0\0", 28, 0, {sa_family=AF_NETLINK, pid=0, groups=00000000}, 12) = 28 recvmsg(3, {msg_name(12)={sa_family=AF_NETLINK, pid=0, groups=00000000}, msg_iov(1)=[{"\34\0\0\0\1\6\0\0g\26\214OY+\0\0\2\0\0\0\5\0\1\0\6\0\0\0\0\0\0\0"..., 256}], msg_controllen=0, msg_flags=0}, 0) = 28 sendto(3, "$\0\0\0\f\6\1\0h\26\214O\0\0\0\0\2\0\0\0\5\0\1\0\6\0\0\0\10\0\2\0"..., 36, 0, {sa_family=AF_NETLINK, pid=0, groups=00000000}, 12) = 36 recvmsg(3, {msg_name(12)={sa_family=AF_NETLINK, pid=0, groups=00000000}, msg_iov(1)=[{"H\0\0\0\f\6\0\0h\26\214OY+\0\0\2\0\0\0\5\0\1\0\6\0\0\0\10\0\2\0"..., 256}], msg_controllen=0, msg_flags=0}, 0) = 72 socket(PF_NETLINK, SOCK_RAW, 0) = 4 bind(4, {sa_family=AF_NETLINK, pid=0, groups=00000000}, 12) = 0 getsockname(4, {sa_family=AF_NETLINK, pid=11097, groups=00000000}, [12]) = 0 time(NULL) = 1334580838 sendto(4, "\24\0\0\0\22\0\1\3f\26\214O\0\0\0\0\0\0\0\0", 20, 0, {sa_family=AF_NETLINK, pid=0, groups=00000000}, 12) = 20 recvmsg(4, {msg_name(12)={sa_family=AF_NETLINK, pid=0, groups=00000000}, msg_iov(1)=[{"\340\3\0\0\20\0\2\0f\26\214OY+\0\0\0\0\4\3\1\0\0\0I\0\1\0\0\0\0\0"..., 4096}], msg_controllen=0, msg_flags=0}, 0) = 3012 recvmsg(4, {msg_name(12)={sa_family=AF_NETLINK, pid=0, groups=00000000}, msg_iov(1)=[{"\360\3\0\0\20\0\2\0f\26\214OY+\0\0\0\0\1\0\4\0\0\0\3\20\0\0\0\0\0\0"..., 4096}], msg_controllen=0, msg_flags=0}, 0) = 2996 brk(0x142e2000) = 0x142e2000 recvmsg(4, {msg_name(12)={sa_family=AF_NETLINK, pid=0, groups=00000000}, msg_iov(1)=[{"\334\3\0\0\20\0\2\0f\26\214OY+\0\0\0\0\0\3\7\0\0\0\200\0\0\0\0\0\0\0"..., 4096}], msg_controllen=0, msg_flags=0}, 0) = 2988 recvmsg(4, {msg_name(12)={sa_family=AF_NETLINK, pid=0, groups=00000000}, msg_iov(1)=[{"\360\3\0\0\20\0\2\0f\26\214OY+\0\0\0\0\1\0\n\0\0\0C\20\1\0\0\0\0\0"..., 4096}], msg_controllen=0, msg_flags=0}, 0) = 2984 brk(0x142e3000) = 0x142e3000 recvmsg(4, {msg_name(12)={sa_family=AF_NETLINK, pid=0, groups=00000000}, msg_iov(1)=[{"\320\3\0\0\20\0\2\0f\26\214OY+\0\0\0\0\0\2\r\0\0\0\321\20\1\0\0\0\0\0"..., 4096}], msg_controllen=0, msg_flags=0}, 0) = 2972 brk(0x142e4000) = 0x142e4000 recvmsg(4, {msg_name(12)={sa_family=AF_NETLINK, pid=0, groups=00000000}, msg_iov(1)=[{"\360\3\0\0\20\0\2\0f\26\214OY+\0\0\0\0\1\0\20\0\0\0C\20\1\0\0\0\0\0"..., 4096}], msg_controllen=0, msg_flags=0}, 0) = 1008 recvmsg(4, {msg_name(12)={sa_family=AF_NETLINK, pid=0, groups=00000000}, msg_iov(1)=[{"\24\0\0\0\3\0\2\0f\26\214OY+\0\0\0\0\0\0\20\0\0\0C\20\1\0\0\0\0\0"..., 4096}], msg_controllen=0, msg_flags=0}, 0) = 20 sendto(4, "\24\0\0\0\26\0\1\3g\26\214O\0\0\0\0\0\0\0\0", 20, 0, {sa_family=AF_NETLINK, pid=0, groups=00000000}, 12) = 20 recvmsg(4, {msg_name(12)={sa_family=AF_NETLINK, pid=0, groups=00000000}, msg_iov(1)=[{"0\0\0\0\24\0\2\0g\26\214OY+\0\0\2\10\200\376\1\0\0\0\10\0\1\0\177\0\0\1"..., 4096}], msg_controllen=0, msg_flags=0}, 0) = 268 recvmsg(4, {msg_name(12)={sa_family=AF_NETLINK, pid=0, groups=00000000}, msg_iov(1)=[{"@\0\0\0\24\0\2\0g\26\214OY+\0\0\n\200\200\376\1\0\0\0\24\0\1\0\0\0\0\0"..., 4096}], msg_controllen=0, msg_flags=0}, 0) = 384 recvmsg(4, {msg_name(12)={sa_family=AF_NETLINK, pid=0, groups=00000000}, msg_iov(1)=[{"\24\0\0\0\3\0\2\0g\26\214OY+\0\0\0\0\0\0\1\0\0\0\24\0\1\0\0\0\0\0"..., 4096}], msg_controllen=0, msg_flags=0}, 0) = 20 brk(0x142e5000) = 0x142e5000 close(4) = 0 open("/etc/hosts", O_RDONLY) = 4 ioctl(4, SNDCTL_TMR_TIMEBASE or SNDRV_TIMER_IOCTL_NEXT_DEVICE or TCGETS, 0x5cc842c8) = -1 ENOTTY (Inappropriate ioctl for device) read(4, "# /etc/hosts: Local Host Databas"..., 4096) = 1061 read(4, "", 4096) = 0 close(4) = 0 stat64("/etc/resolv.conf", {st_mode=S_IFREG|0644, st_size=174, ...}) = 0 open("/etc/resolv.conf", O_RDONLY) = 4 ioctl(4, SNDCTL_TMR_TIMEBASE or SNDRV_TIMER_IOCTL_NEXT_DEVICE or TCGETS, 0x5cc83f70) = -1 ENOTTY (Inappropriate ioctl for device) read(4, "# Generated by resolvconf\nsearch"..., 4096) = 174 read(4, "", 4096) = 0 close(4) = 0 socket(PF_INET, SOCK_DGRAM, IPPROTO_UDP) = 4 connect(4, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("127.0.0.1")}, 28) = 0 send(4, "\0\2\1\0\0\1\0\0\0\0\0\0\00256\003105\003168\003192\7in-a"..., 45, 0) = 45 poll([{fd=4, events=POLLIN}], 1, 5000) = 1 ([{fd=4, revents=POLLIN}]) recv(4, "\0\2\205\203\0\1\0\0\0\0\0\0\00256\003105\003168\003192\7in-a"..., 512, MSG_DONTWAIT) = 45 close(4) = 0 stat64("/etc/resolv.conf", {st_mode=S_IFREG|0644, st_size=174, ...}) = 0 socket(PF_INET, SOCK_DGRAM, IPPROTO_UDP) = 4 connect(4, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("127.0.0.1")}, 28) = 0 send(4, "\0\3\1\0\0\1\0\0\0\0\0\0\00256\003105\003168\003192\7in-a"..., 65, 0) = 65 poll([{fd=4, events=POLLIN}], 1, 5000) = 0 (Timeout) close(4) = 0 stat64("/etc/resolv.conf", {st_mode=S_IFREG|0644, st_size=174, ...}) = 0 socket(PF_INET, SOCK_DGRAM, IPPROTO_UDP) = 4 connect(4, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("192.168.105.212")}, 28) = 0 send(4, "\0\4\1\0\0\1\0\0\0\0\0\0\00256\003105\003168\003192\7in-a"..., 45, 0) = 45 poll([{fd=4, events=POLLIN}], 1, 5000) = 0 (Timeout) close(4) = 0 stat64("/etc/resolv.conf", {st_mode=S_IFREG|0644, st_size=174, ...}) = 0 socket(PF_INET, SOCK_DGRAM, IPPROTO_UDP) = 4 connect(4, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("8.8.8.8")}, 28) = 0 send(4, "\0\5\1\0\0\1\0\0\0\0\0\0\00256\003105\003168\003192\7in-a"..., 45, 0) = 45 poll([{fd=4, events=POLLIN}], 1, 5000) = 0 (Timeout) close(4) = 0 stat64("/etc/resolv.conf", {st_mode=S_IFREG|0644, st_size=174, ...}) = 0 socket(PF_INET, SOCK_DGRAM, IPPROTO_UDP) = 4 connect(4, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("8.8.4.4")}, 28) = 0 send(4, "\0\6\1\0\0\1\0\0\0\0\0\0\00256\003105\003168\003192\7in-a"..., 45, 0) = 45 poll([{fd=4, events=POLLIN}], 1, 5000) = 0 (Timeout) close(4) = 0 stat64("/etc/resolv.conf", {st_mode=S_IFREG|0644, st_size=174, ...}) = 0 socket(PF_INET, SOCK_DGRAM, IPPROTO_UDP) = 4 connect(4, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("127.0.0.1")}, 28) = 0 send(4, "\0\7\1\0\0\1\0\0\0\0\0\0\00256\003105\003168\003192\7in-a"..., 45, 0) = 45 poll([{fd=4, events=POLLIN}], 1, 5000) = 1 ([{fd=4, revents=POLLIN}]) recv(4, "\0\7\205\203\0\1\0\0\0\0\0\0\00256\003105\003168\003192\7in-a"..., 512, MSG_DONTWAIT) = 45 close(4) = 0 stat64("/etc/resolv.conf", {st_mode=S_IFREG|0644, st_size=174, ...}) = 0 socket(PF_INET, SOCK_DGRAM, IPPROTO_UDP) = 4 connect(4, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("127.0.0.1")}, 28) = 0 send(4, "\0\10\1\0\0\1\0\0\0\0\0\0\00256\003105\003168\003192\7in-a"..., 65, 0) = 65 poll([{fd=4, events=POLLIN}], 1, 5000) = 0 (Timeout) close(4) = 0 stat64("/etc/resolv.conf", {st_mode=S_IFREG|0644, st_size=174, ...}) = 0 socket(PF_INET, SOCK_DGRAM, IPPROTO_UDP) = 4 connect(4, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("192.168.105.212")}, 28) = 0 send(4, "\0\t\1\0\0\1\0\0\0\0\0\0\00256\003105\003168\003192\7in-a"..., 45, 0) = 45 poll([{fd=4, events=POLLIN}], 1, 5000^C <unfinished ...> ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: ipset causes reverse dns lookups? 2012-04-16 13:14 ` Ed W @ 2012-04-16 13:20 ` Jozsef Kadlecsik [not found] ` <4F8C1E78.6030202@wildgooses.com> 0 siblings, 1 reply; 11+ messages in thread From: Jozsef Kadlecsik @ 2012-04-16 13:20 UTC (permalink / raw) To: Ed W; +Cc: netfilter On Mon, 16 Apr 2012, Ed W wrote: > On 16/04/2012 10:55, Jozsef Kadlecsik wrote: > > Try the following untested patch: > > Thanks for the idea. I'm not 100% sure I'm testing correctly, but I rebuilt > and I see no change... See the message from Amos in this thread: if uclibc ignores AI_NUMERICHOST, then I can't workaround that :-(. Best regards, Jozsef - E-mail : kadlec@blackhole.kfki.hu, kadlecsik.jozsef@wigner.mta.hu PGP key : http://www.kfki.hu/~kadlec/pgp_public_key.txt Address : Wigner Research Centre for Physics, Hungarian Academy of Sciences H-1525 Budapest 114, POB. 49, Hungary ^ permalink raw reply [flat|nested] 11+ messages in thread
[parent not found: <4F8C1E78.6030202@wildgooses.com>]
[parent not found: <alpine.DEB.2.00.1204161548170.20321@blackhole.kfki.hu>]
* Re: ipset causes reverse dns lookups? [not found] ` <alpine.DEB.2.00.1204161548170.20321@blackhole.kfki.hu> @ 2012-04-16 22:05 ` Ed W 0 siblings, 0 replies; 11+ messages in thread From: Ed W @ 2012-04-16 22:05 UTC (permalink / raw) To: Jozsef Kadlecsik, Netfilter On 16/04/2012 14:48, Jozsef Kadlecsik wrote: > On Mon, 16 Apr 2012, Ed W wrote: > >> On 16/04/2012 14:20, Jozsef Kadlecsik wrote: >>> On Mon, 16 Apr 2012, Ed W wrote: >>> >>>> On 16/04/2012 10:55, Jozsef Kadlecsik wrote: >>>>> Try the following untested patch: >>>> Thanks for the idea. I'm not 100% sure I'm testing correctly, but I >>>> rebuilt >>>> and I see no change... >>> See the message from Amos in this thread: if uclibc ignores >>> AI_NUMERICHOST, then I can't workaround that :-(. >> Could you please investigate keeping your changes and I will separately >> investigate fixing/patching uclibc. I found Amos' referenced post and it >> gives some background on what is needed to resolve this > Sure. > I have now implemented a fix in uclibc. The current patch I submitted is not optimised by the AI_NUMERICSERV option, so whilst leave it in if there is no harm, it's not necessary for uclibc. Performance has improved dramatically! Thanks for all the help - very much appreciated! Ed W ^ permalink raw reply [flat|nested] 11+ messages in thread
end of thread, other threads:[~2012-04-16 22:05 UTC | newest]
Thread overview: 11+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2012-04-15 23:26 ipset causes reverse dns lookups? Ed W
2012-04-16 1:15 ` Ed W
2012-04-16 3:23 ` Ed W
2012-04-16 8:08 ` Jozsef Kadlecsik
2012-04-16 8:37 ` Ed W
2012-04-16 9:55 ` Jozsef Kadlecsik
2012-04-16 13:08 ` Amos Jeffries
2012-04-16 13:21 ` Jozsef Kadlecsik
2012-04-16 13:14 ` Ed W
2012-04-16 13:20 ` Jozsef Kadlecsik
[not found] ` <4F8C1E78.6030202@wildgooses.com>
[not found] ` <alpine.DEB.2.00.1204161548170.20321@blackhole.kfki.hu>
2012-04-16 22:05 ` Ed W
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.