Version: (using KDE KDE 3.1.1) Installed from: SuSE RPMs OS: Linux There are 2 places in which a very similar problem manifests in the KDE print system: 1] On opening <kprinter> from a bash command line 2] Opening <kcmshell printmgr> from a menu or from a command line and subsequently clicking on an remote samba printer I have not investigated whether it also occurs in other circumstances for these components or others, but I think that the below would pin down what is happening sufficiently to locate any other instances. In both cases, my router opens up a connection to the ISP. [Which, here in the UK, incurs a non trivial connection charge which covers the first 5 minutes of connection]. On investigation with <snort>, I find that the PC is sending a message to port 53 of my router, which dummies for the ISP's DNS. It is trying to resolve the <ServerName> given in <cupsd.conf> [verified by changing this value]. This occurs for both hostnames and IP addresses on the network. The network itself is too small to require internal DNS, this is managed with </etc/hosts>. The configuration of the hosts file is considered as correct, since pinging any of the hosts resolves names and IP addresses via the hosts file without making an external DNS call, whereas a ping to a non existent host will make an external DNS call. My provisional diagnosis is that [rightly or wrongly], in the described circumstances, th program requires to resolve the <ServerName> given in <cupsd.conf>. However, quite wrongly it is using DNS without using /etc/hosts. I should have the humility to accept that I might have missed a configuration option somewhere which controls this - but I don't think I missed anything.
Subject: Re: New: Uses DNS to resolve hostname - ignores /etc/hosts [This costs $$$ on dialup] Was this problem also present in earlier KDE versions (KDE-3.1.0)? I think that a workaround to avoid name resolution is to put directly the IP address in the cupsd.conf file (provided that this IP address is fixed). Otherwise, KDEPrint itself is not responsible for name resolution, it uses external components to connect to a given host (from CUPS and KDE API), so I cannot really control how name resolution will be done. Michael. > There are 2 places in which a very similar problem manifests in the KDE print system: > 1] On opening <kprinter> from a bash command line > 2] Opening <kcmshell printmgr> from a menu or from a command line and subsequently clicking on an remote samba printer > I have not investigated whether it also occurs in other circumstances for these components or others, but I think that the below would pin down what is happening sufficiently to locate any other instances. > > In both cases, my router opens up a connection to the ISP. [Which, here in the UK, incurs a non trivial connection charge which covers the first 5 minutes of connection]. On investigation with <snort>, I find that the PC is sending a message to port 53 of my router, which dummies for the ISP's DNS. It is trying to resolve the <ServerName> given in <cupsd.conf> [verified by changing this value]. This occurs for both hostnames and IP addresses on the network. > > The network itself is too small to require internal DNS, this is managed with </etc/hosts>. The configuration of the hosts file is considered as correct, since pinging any of the hosts resolves names and IP addresses via the hosts file without making an external DNS call, whereas a ping to a non existent host will make an external DNS call. > > My provisional diagnosis is that [rightly or wrongly], in the described circumstances, th program requires to resolve the <ServerName> given in <cupsd.conf>. However, quite wrongly it is using DNS without using /etc/hosts. I should have the humility to accept that I might have missed a configuration option somewhere which controls this - but I don't think I missed anything.
Subject: Re: Uses DNS to resolve hostname - ignores /etc/hosts [This costs $$$ on dialup] Michael, It was in KDE 3.0 as supplied with SuSE 8.0, as far as <kcmshell printmgr> was concerned. At that stage, I did not investigate too much because *] SuSE 8.2 was coming out *] I knew my KDE version was not current. But it seems likely it is a longstanding problem rather than a code regression. I have tried putting the IP address as <ServerName> in <cupsd.conf>. This merely takes the IP address and attempts to resolve it as a name! I note your comment that KDEPrint uses external components [which is exactly what I would expect]. However, I can configure CUPS printers using the browser interface [127.0.0.1:901] and using SuSE's YAST2 without making a DNS call or disturbing the router. So yes, I incline to accept that it is more likely to be KDEPrint's choice of friends rather than KDEPrint itself. Michael, would you mind sticking with me on this, or assigning someone. I am motivated to take this where ever it goes and fix it, because I don't want to pay my telco [for doing nothing] every time I print from KOffice. By day, I am an embedded C and Assembler software engineer, I know nothing of KDE programming, or linux programming in general, but I reckon I could contribute and this looks like a good place to start. regards Vince Littler On Monday 28 April 2003 10:38 am, you wrote: > ------- Additional Comments From goffioul@imec.be 2003-04-28 11:38 ------- > Subject: Re: New: Uses DNS to resolve hostname - ignores /etc/hosts > [This costs $$$ on dialup] > > Was this problem also present in earlier KDE versions (KDE-3.1.0)? > I think that a workaround to avoid name resolution is to put directly > the IP address in the cupsd.conf file (provided that this IP address is > fixed). Otherwise, KDEPrint itself is not responsible for name > resolution, it uses external components to connect to a given host > (from CUPS and KDE API), so I cannot really control how name resolution > will be done. > > Michael. > > > There are 2 places in which a very similar problem manifests in the KDE > > print system: 1] On opening <kprinter> from a bash command line > > 2] Opening <kcmshell printmgr> from a menu or from a command line and > > subsequently clicking on an remote samba printer I have not investigated > > whether it also occurs in other circumstances for these components or > > others, but I think that the below would pin down what is happening > > sufficiently to locate any other instances. > > > > In both cases, my router opens up a connection to the ISP. [Which, here > > in the UK, incurs a non trivial connection charge which covers the first > > 5 minutes of connection]. On investigation with <snort>, I find that the > > PC is sending a message to port 53 of my router, which dummies for the > > ISP's DNS. It is trying to resolve the <ServerName> given in <cupsd.conf> > > [verified by changing this value]. This occurs for both hostnames and IP > > addresses on the network. > > > > The network itself is too small to require internal DNS, this is managed > > with </etc/hosts>. The configuration of the hosts file is considered as > > correct, since pinging any of the hosts resolves names and IP addresses > > via the hosts file without making an external DNS call, whereas a ping to > > a non existent host will make an external DNS call. > > > > My provisional diagnosis is that [rightly or wrongly], in the described > > circumstances, th program requires to resolve the <ServerName> given in > > <cupsd.conf>. However, quite wrongly it is using DNS without using > > /etc/hosts. I should have the humility to accept that I might have missed > > a configuration option somewhere which controls this - but I don't think > > I missed anything.
The person to be assigned would probably be me. I found it odd that you said the IP address was attempted as a hostname for resolution. But my local testing revealed what I expected. This is an output from tcpdump port 53 while running kprinter: 14:55:45.162708 127.0.0.1.32979 > 127.0.0.1.53: 9766+ AAAA? localhost.fr.local.lan. (40) (DF) 14:55:45.163166 127.0.0.1.53 > 127.0.0.1.32979: 9766* 1/2/7 AAAA[|domain] (DF) 14:55:45.167328 127.0.0.1.32979 > 127.0.0.1.53: 9767+ AAAA? localhost.local.lan. (37) (DF) 14:55:45.167794 127.0.0.1.53 > 127.0.0.1.32979: 9767* 1/2/7 AAAA[|domain] (DF) 14:55:45.169775 127.0.0.1.32979 > 127.0.0.1.53: 9768+ CNAME? localhost.fr.local.lan. (40) (DF) 14:55:45.170156 127.0.0.1.53 > 127.0.0.1.32979: 9768* 0/1/0 (85) (DF) 14:55:45.171495 127.0.0.1.32979 > 127.0.0.1.53: 9769+ CNAME? localhost.local.lan. (37) (DF) 14:55:45.171848 127.0.0.1.53 > 127.0.0.1.32979: 9769* 0/1/0 (82) (DF) That is: the resolution was attempted because "localhost" was not resolved with IPv6 address from /etc/hosts. Still, the output is strange because the first reply was already successful and contained the correct address. There was no need for the other three. Also note that this must come from glibc's name resolution functions, since the two domains for my network were attempted and KDE never reads /etc/resolv.conf (Qt does, however). In all, my recommendation is to run a DNS server. Your connection to the ISP is being attempted because KDE *is* looking for an address that is not present in /etc/hosts. It might be just an IPv6 address for the server.
Subject: Re: CUPS and name resolving Michael Goffioul wrote: > Hi Michael, > > Could you have a look at this bug report? > http://bugs.kde.org/show_bug.cgi?id=57754 > > Basically, what KDEPrint is doing internally is extracting the host > name and port from the printer URI, then open a connection to these > using httpConnect and sending the request. Do you think that the > reported problem is CUPS-related, or KDEPrint-related? It is a local configuration error; basically, it sounds like the host.conf file is using DNS as primary and the hosts file as backup (bind,hosts) instead of the other way around (hosts,bind). Also, it isn't clear from the post what version of CUPS is being used, but any recent version of CUPS will not be using gethostbyname to lookup IP addresses, only names. Finally, it would be interesting to find out if the user has enabled hostname lookups in cupsd.conf (HostNameLookups on or double), as that might be the source of the hostname lookups and not the client.
Subject: Re: Uses DNS to resolve hostname - ignores /etc/hosts [This costs $$$ on dialup] On Monday 28 April 2003 3:40 pm, Michael Goffioul wrote: > ------- You are receiving this mail because: ------- > You reported the bug, or are watching the reporter. > > http://bugs.kde.org/show_bug.cgi?id=57754 > > > > > ------- Additional Comments From goffioul@imec.be 2003-04-28 16:40 ------- > Subject: Re: CUPS and name resolving > > Michael Goffioul wrote: > > Hi Michael, > > > > Could you have a look at this bug report? > > http://bugs.kde.org/show_bug.cgi?id=57754 > > > > Basically, what KDEPrint is doing internally is extracting the host > > name and port from the printer URI, then open a connection to these > > using httpConnect and sending the request. Do you think that the > > reported problem is CUPS-related, or KDEPrint-related? > > It is a local configuration error; basically, it sounds like the > host.conf file is using DNS as primary and the hosts file as backup > (bind,hosts) instead of the other way around (hosts,bind). > > Also, it isn't clear from the post what version of CUPS is being > used, but any recent version of CUPS will not be using gethostbyname > to lookup IP addresses, only names. > > Finally, it would be interesting to find out if the user has enabled > hostname lookups in cupsd.conf (HostNameLookups on or double), as > that might be the source of the hostname lookups and not the client. 1] host.conf ============ order hosts, bind multi on 2] cups ======= version 1.1.18 2] cupsd.conf ============= HostnameLookups Off This has been tried 'On' and 'Off', to no avail. All info posted is when set to 'Off'. regards Vince Littler
Subject: Re: Uses DNS to resolve hostname - ignores /etc/hosts [This costs $$$ on dialup] On Monday 28 April 2003 2:01 pm, Thiago Macieira wrote: > ------- You are receiving this mail because: ------- > You reported the bug, or are watching the reporter. > > http://bugs.kde.org/show_bug.cgi?id=57754 > > > > > ------- Additional Comments From thiagom@mail.com 2003-04-28 15:01 ------- > The person to be assigned would probably be me. > > I found it odd that you said the IP address was attempted as a hostname for > resolution. But my local testing revealed what I expected. This is an > output from tcpdump port 53 while running kprinter: > > 14:55:45.162708 127.0.0.1.32979 > 127.0.0.1.53: 9766+ AAAA? > localhost.fr.local.lan. (40) (DF) > 14:55:45.163166 127.0.0.1.53 > 127.0.0.1.32979: 9766* 1/2/7 AAAA[|domain] > (DF) 14:55:45.167328 127.0.0.1.32979 > 127.0.0.1.53: 9767+ AAAA? > localhost.local.lan. (37) (DF) > 14:55:45.167794 127.0.0.1.53 > 127.0.0.1.32979: 9767* 1/2/7 AAAA[|domain] > (DF) 14:55:45.169775 127.0.0.1.32979 > 127.0.0.1.53: 9768+ CNAME? > localhost.fr.local.lan. (40) (DF) > 14:55:45.170156 127.0.0.1.53 > 127.0.0.1.32979: 9768* 0/1/0 (85) (DF) > 14:55:45.171495 127.0.0.1.32979 > 127.0.0.1.53: 9769+ CNAME? > localhost.local.lan. (37) (DF) > 14:55:45.171848 127.0.0.1.53 > 127.0.0.1.32979: 9769* 0/1/0 (82) (DF) > > That is: the resolution was attempted because "localhost" was not resolved > with IPv6 address from /etc/hosts. > > Still, the output is strange because the first reply was already successful > and contained the correct address. There was no need for the other three. > Also note that this must come from glibc's name resolution functions, since > the two domains for my network were attempted and KDE never reads > /etc/resolv.conf (Qt does, however). > > In all, my recommendation is to run a DNS server. Your connection to the > ISP is being attempted because KDE *is* looking for an address that is not > present in /etc/hosts. It might be just an IPv6 address for the server. Well, here is a section of my /etc/hosts file: 127.0.0.1 localhost # special IPv6 addresses ::1 localhost ipv6-localhost ipv6-loopback fe00::0 ipv6-localnet ff00::0 ipv6-mcastprefix ff02::1 ipv6-allnodes ff02::2 ipv6-allrouters ff02::3 ipv6-allhosts We should be able to resolve localhost from /etc/hosts in IPv4 and IPv6. I agree that running a local DNS would make the problem "go away", but it doesn't fix it and I always find that these problems come back and bite. As it is, either something is not working [eg glibc not working right for KDEprint] or my configuration is wrong. And I have tcpip working a treat, not to mention samba, and NOTHING disturbs my router for DNS without cause, so I tend to think that KPrinter is calling something which is not providing the expected returns for KPrinter. I am suspicious of glibc or some system service, because if I do ping 10.40.40.7 [which is an unnamed machine], DNS is used, presumably to return that the IP address is the unsurprising value 10.40.40.7, and the 1st ping returns after several seconds. If I name the machine in /etc/hosts, it will ping by name or IP address, with the first return always <10ms. The same applies to telnet. The point of this is that some common system service can only recognise a dotted quad address as a hostname, and is therefore broken - could KPrint be suffering from a similar problem in part of the same common ssytem service? Is there anything I could try with cups itself, to see if cups is responsible? When I access cups with its web interface, there is no problem. regards Vince Littler
It is certainly possible that this is a glibc problem. We have had reports of problem with the getaddrinfo() function doing DNS even when /etc/hosts had the correct resolution. The workaround was to re-order the elements in each line in the file (i.e., instead of 127.0.0.1 localhost localhost.localnet to be: 127.0.0.1 localhost.localnet localhost). It has been reported once in KDE and was apparently a Red Hat bug, which has also been marked as fixed. Anyways, can you paste an strace of ping? Or, if similarly telnet 10.40.40.7 suffers from the same pathology, the strace of telnet (since it's simpler)? That should show exactly where in the code the DNS lookup is being attempted and we'll be able to say if this is a KDE bug or a system-wide one. As for KDEPrint, try adding an IPv6 address in /etc/hosts for the machine in question (if it's not already there). See if that spares the DNS lookup.
Subject: Re: Uses DNS to resolve hostname - ignores /etc/hosts [This costs $$$ on dialup] On Monday 28 April 2003 9:52 pm, Thiago Macieira wrote: > ------- You are receiving this mail because: ------- > You reported the bug, or are watching the reporter. > > http://bugs.kde.org/show_bug.cgi?id=57754 > > > > > ------- Additional Comments From thiagom@mail.com 2003-04-28 22:52 ------- > It is certainly possible that this is a glibc problem. We have had reports > of problem with the getaddrinfo() function doing DNS even when /etc/hosts > had the correct resolution. The workaround was to re-order the elements in > each line in the file (i.e., instead of > 127.0.0.1 localhost localhost.localnet > to be: > 127.0.0.1 localhost.localnet localhost). > > It has been reported once in KDE and was apparently a Red Hat bug, which > has also been marked as fixed. > > Anyways, can you paste an strace of ping? Or, if similarly telnet > 10.40.40.7 suffers from the same pathology, the strace of telnet (since > it's simpler)? That should show exactly where in the code the DNS lookup is > being attempted and we'll be able to say if this is a KDE bug or a > system-wide one. > > As for KDEPrint, try adding an IPv6 address in /etc/hosts for the machine > in question (if it's not already there). See if that spares the DNS lookup. Hi Thiago OK, I have never done strace before, but I have just installed it and played a little. Ping doesn't do strace for me, but telnet does. I will play around with the hosts file a bit and see if there is anything to summarize, and as you request, I will paste in an output later. As for KDEPrint and IPv^ addresses, I have this: # special IPv6 addresses ::1 localhost ipv6-localhost ipv6-loopback Sorry, my IPv4 does not run to knowing whether this is right! rgds Vince
Subject: Re: Uses DNS to resolve hostname - ignores /etc/hosts [This costs $$$ on dialup] On Monday 28 April 2003 9:52 pm, Thiago Macieira wrote: > ------- You are receiving this mail because: ------- > You reported the bug, or are watching the reporter. > > http://bugs.kde.org/show_bug.cgi?id=57754 > > > > > ------- Additional Comments From thiagom@mail.com 2003-04-28 22:52 ------- > It is certainly possible that this is a glibc problem. We have had reports > of problem with the getaddrinfo() function doing DNS even when /etc/hosts > had the correct resolution. The workaround was to re-order the elements in > each line in the file (i.e., instead of > 127.0.0.1 localhost localhost.localnet > to be: > 127.0.0.1 localhost.localnet localhost). > > It has been reported once in KDE and was apparently a Red Hat bug, which > has also been marked as fixed. > > Anyways, can you paste an strace of ping? Or, if similarly telnet > 10.40.40.7 suffers from the same pathology, the strace of telnet (since > it's simpler)? That should show exactly where in the code the DNS lookup is > being attempted and we'll be able to say if this is a KDE bug or a > system-wide one. > > As for KDEPrint, try adding an IPv6 address in /etc/hosts for the machine > in question (if it's not already there). See if that spares the DNS lookup. Thiago, I have dug up this snippet [below] from a discussion elsewhere on telnet and ping on SuSE. In part, it seems that if you do telnet 10.40.40.7, then 10.40.40.7 is no more and no less than a string, when you send the command. It then requires either hostname resolution to give an address, or a semantic transformation [ie change of meaning] to use it as an address. It may be that the libs think that the apps mostly handle this and vice versa and we get an end result which works, but not too well > > But the question remains, is there not a small bug inherent in this in > > that the destination address should be checked for being an IP address or > > a URL, and DNS only invoked for a URL? > > After actually looking at the source, I see the reason. telnet does a > getaddrinfo with the AI_CANONNAME set, which does at least a reverse name > lookup. telnet itself doesn't try to parse the address very much. It looks > like that's where the call to dns comes from. > Whether this is directly relevant to our KDEPrint situation is not obvious, but we might be looking at a similar scenario of poor partitioning of functionality. Below are straces of telnet to 10.40.40.7 with and without the line 10.40.40.7 birdy.archipelago birdy in /etc/hosts, and a DNS call evident if it is not in /etc/hosts regards Vince Littler ============================================================================= strace 1 [10.40.40.7 not in /etc/hosts] ============================================================================= vince@irvine:~> strace telnet 10.40.40.7 execve("/usr/bin/telnet", ["telnet", "10.40.40.7"], [/* 61 vars */]) = 0 uname({sys="Linux", node="irvine", ...}) = 0 brk(0) = 0x8066888 open("/etc/ld.so.preload", O_RDONLY) = -1 ENOENT (No such file or directory) open("/etc/ld.so.cache", O_RDONLY) = 3 fstat64(3, {st_mode=S_IFREG|0644, st_size=45920, ...}) = 0 old_mmap(NULL, 45920, PROT_READ, MAP_PRIVATE, 3, 0) = 0x40015000 close(3) = 0 open("/lib/libncurses.so.5", O_RDONLY) = 3 read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0 \361\0"..., 1024) = 1024 fstat64(3, {st_mode=S_IFREG|0755, st_size=316845, ...}) = 0 old_mmap(NULL, 277836, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) = 0x40021000 mprotect(0x40059000, 48460, PROT_NONE) = 0 old_mmap(0x40059000, 49152, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 3, 0x37000) = 0x40059000 close(3) = 0 open("/lib/libc.so.6", O_RDONLY) = 3 read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0pY\1\000"..., 1024) = 1024 fstat64(3, {st_mode=S_IFREG|0755, st_size=1491599, ...}) = 0 old_mmap(NULL, 1268004, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) = 0x40065000 mprotect(0x40194000, 26916, PROT_NONE) = 0 old_mmap(0x40194000, 16384, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 3, 0x12f000) = 0x40194000 old_mmap(0x40198000, 10532, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x40198000 close(3) = 0 old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x4019b000 munmap(0x40015000, 45920) = 0 brk(0) = 0x8066888 brk(0x8067888) = 0x8067888 brk(0) = 0x8067888 brk(0x8068000) = 0x8068000 uname({sys="Linux", node="irvine", ...}) = 0 brk(0) = 0x8068000 brk(0x8069000) = 0x8069000 gettimeofday({1051646452, 368358}, NULL) = 0 getpid() = 4306 open("/etc/resolv.conf", O_RDONLY) = 3 fstat64(3, {st_mode=S_IFREG|0644, st_size=43, ...}) = 0 old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x40015000 read(3, "domain archipelago\nnameserver 17"..., 4096) = 43 read(3, "", 4096) = 0 close(3) = 0 munmap(0x40015000, 4096) = 0 socket(PF_UNIX, SOCK_STREAM, 0) = 3 connect(3, {sa_family=AF_UNIX, path="/var/run/.nscd_socket"}, 110) = 0 writev(3, [{"\2\0\0\0\4\0\0\0\7\0\0\0", 12}, {"irvine\0", 7}], 2) = 19 read(3, "\2\0\0\0\377\377\377\377\0\0\0\0\0\0\0\0\377\377\377\377"..., 32) = 32 close(3) = 0 open("/etc/nsswitch.conf", O_RDONLY) = 3 fstat64(3, {st_mode=S_IFREG|0644, st_size=1291, ...}) = 0 old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x40015000 read(3, "#\n# /etc/nsswitch.conf\n#\n# An ex"..., 4096) = 1291 read(3, "", 4096) = 0 close(3) = 0 munmap(0x40015000, 4096) = 0 open("/etc/ld.so.cache", O_RDONLY) = 3 fstat64(3, {st_mode=S_IFREG|0644, st_size=45920, ...}) = 0 old_mmap(NULL, 45920, PROT_READ, MAP_PRIVATE, 3, 0) = 0x40015000 close(3) = 0 open("/lib/libnss_files.so.2", O_RDONLY) = 3 read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0p\35\0\000"..., 1024) = 1024 fstat64(3, {st_mode=S_IFREG|0755, st_size=42881, ...}) = 0 old_mmap(NULL, 38492, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) = 0x4019c000 mprotect(0x401a5000, 1628, PROT_NONE) = 0 old_mmap(0x401a5000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 3, 0x8000) = 0x401a5000 close(3) = 0 munmap(0x40015000, 45920) = 0 open("/etc/host.conf", O_RDONLY) = 3 fstat64(3, {st_mode=S_IFREG|0644, st_size=370, ...}) = 0 old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x40015000 read(3, "#\n# /etc/host.conf - resolver co"..., 4096) = 370 read(3, "", 4096) = 0 close(3) = 0 munmap(0x40015000, 4096) = 0 open("/etc/hosts", O_RDONLY) = 3 fcntl64(3, F_GETFD) = 0 fcntl64(3, F_SETFD, FD_CLOEXEC) = 0 fstat64(3, {st_mode=S_IFREG|0644, st_size=861, ...}) = 0 old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x40015000 read(3, "#\n# hosts This file desc"..., 4096) = 861 read(3, "", 4096) = 0 close(3) = 0 munmap(0x40015000, 4096) = 0 ioctl(0, SNDCTL_TMR_TIMEBASE, {B38400 opost isig icanon echo ...}) = 0 rt_sigprocmask(SIG_BLOCK, NULL, [RTMIN], 8) = 0 open("/etc/services", O_RDONLY) = 3 fcntl64(3, F_GETFD) = 0 fcntl64(3, F_SETFD, FD_CLOEXEC) = 0 fstat64(3, {st_mode=S_IFREG|0644, st_size=304796, ...}) = 0 old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x40015000 read(3, "#\n# Network services, Internet s"..., 4096) = 4096 close(3) = 0 munmap(0x40015000, 4096) = 0 open("/etc/hosts", O_RDONLY) = 3 fcntl64(3, F_GETFD) = 0 fcntl64(3, F_SETFD, FD_CLOEXEC) = 0 fstat64(3, {st_mode=S_IFREG|0644, st_size=861, ...}) = 0 old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x40015000 read(3, "#\n# hosts This file desc"..., 4096) = 861 read(3, "", 4096) = 0 close(3) = 0 munmap(0x40015000, 4096) = 0 open("/etc/ld.so.cache", O_RDONLY) = 3 fstat64(3, {st_mode=S_IFREG|0644, st_size=45920, ...}) = 0 old_mmap(NULL, 45920, PROT_READ, MAP_PRIVATE, 3, 0) = 0x40015000 close(3) = 0 open("/lib/libnss_dns.so.2", O_RDONLY) = 3 read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\360\16"..., 1024) = 1024 fstat64(3, {st_mode=S_IFREG|0755, st_size=17395, ...}) = 0 old_mmap(NULL, 16936, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) = 0x401a6000 mprotect(0x401aa000, 552, PROT_NONE) = 0 old_mmap(0x401aa000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 3, 0x3000) = 0x401aa000 close(3) = 0 open("/lib/libresolv.so.2", O_RDONLY) = 3 read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\0*\0\000"..., 1024) = 1024 fstat64(3, {st_mode=S_IFREG|0755, st_size=75057, ...}) = 0 old_mmap(NULL, 73640, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) = 0x401ab000 mprotect(0x401ba000, 12200, PROT_NONE) = 0 old_mmap(0x401ba000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 3, 0xf000) = 0x401ba000 old_mmap(0x401bb000, 8104, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x401bb000 close(3) = 0 brk(0) = 0x8069000 brk(0x806a000) = 0x806a000 munmap(0x40015000, 45920) = 0 stat64("/etc/resolv.conf", {st_mode=S_IFREG|0644, st_size=43, ...}) = 0 gettimeofday({1051646452, 387458}, NULL) = 0 getpid() = 4306 open("/etc/resolv.conf", O_RDONLY) = 3 fstat64(3, {st_mode=S_IFREG|0644, st_size=43, ...}) = 0 old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x40015000 read(3, "domain archipelago\nnameserver 17"..., 4096) = 43 read(3, "", 4096) = 0 close(3) = 0 munmap(0x40015000, 4096) = 0 socket(PF_INET, SOCK_DGRAM, IPPROTO_IP) = 3 connect(3, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("172.23.4.254")}, 28) = 0 send(3, " \245\1\0\0\1\0\0\0\0\0\0\0017\00240\00240\00210\7in-a"..., 41, 0) = 41 gettimeofday({1051646452, 390268}, NULL) = 0 poll([{fd=3, events=POLLIN}], 1, 5000) = 0 send(3, " \245\1\0\0\1\0\0\0\0\0\0\0017\00240\00240\00210\7in-a"..., 41, 0) = 41 gettimeofday({1051646457, 391448}, NULL) = 0 poll([{fd=3, events=POLLIN}], 1, 5000) = 0 close(3) = 0 open("/etc/services", O_RDONLY) = 3 fcntl64(3, F_GETFD) = 0 fcntl64(3, F_SETFD, FD_CLOEXEC) = 0 fstat64(3, {st_mode=S_IFREG|0644, st_size=304796, ...}) = 0 old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x40015000 read(3, "#\n# Network services, Internet s"..., 4096) = 4096 close(3) = 0 munmap(0x40015000, 4096) = 0 fstat64(1, {st_mode=S_IFCHR|0600, st_rdev=makedev(136, 1), ...}) = 0 old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x40015000 write(1, "Trying 10.40.40.7...\r\n", 22Trying 10.40.40.7... ) = 22 socket(PF_INET, SOCK_STREAM, IPPROTO_TCP) = 3 setsockopt(3, SOL_IP, IP_TOS, [16], 4) = 0 connect(3, {sa_family=AF_INET, sin_port=htons(23), sin_addr=inet_addr("10.40.40.7")}, 16) = -1 ECONNREFUSED (Connection refused) write(2, "telnet: connect to address 10.40"..., 58telnet: connect to address 10.40.40.7: Connection refused ) = 58 close(3) = 0 munmap(0x40015000, 4096) = 0 exit_group(1) = ? vince@irvine:~> ============================================================================= strace 2 [10.40.40.7 in /etc/hosts] ============================================================================= vince@irvine:~> strace telnet 10.40.40.7 execve("/usr/bin/telnet", ["telnet", "10.40.40.7"], [/* 61 vars */]) = 0 uname({sys="Linux", node="irvine", ...}) = 0 brk(0) = 0x8066888 open("/etc/ld.so.preload", O_RDONLY) = -1 ENOENT (No such file or directory) open("/etc/ld.so.cache", O_RDONLY) = 3 fstat64(3, {st_mode=S_IFREG|0644, st_size=45920, ...}) = 0 old_mmap(NULL, 45920, PROT_READ, MAP_PRIVATE, 3, 0) = 0x40015000 close(3) = 0 open("/lib/libncurses.so.5", O_RDONLY) = 3 read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0 \361\0"..., 1024) = 1024 fstat64(3, {st_mode=S_IFREG|0755, st_size=316845, ...}) = 0 old_mmap(NULL, 277836, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) = 0x40021000 mprotect(0x40059000, 48460, PROT_NONE) = 0 old_mmap(0x40059000, 49152, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 3, 0x37000) = 0x40059000 close(3) = 0 open("/lib/libc.so.6", O_RDONLY) = 3 read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0pY\1\000"..., 1024) = 1024 fstat64(3, {st_mode=S_IFREG|0755, st_size=1491599, ...}) = 0 old_mmap(NULL, 1268004, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) = 0x40065000 mprotect(0x40194000, 26916, PROT_NONE) = 0 old_mmap(0x40194000, 16384, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 3, 0x12f000) = 0x40194000 old_mmap(0x40198000, 10532, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x40198000 close(3) = 0 old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x4019b000 munmap(0x40015000, 45920) = 0 brk(0) = 0x8066888 brk(0x8067888) = 0x8067888 brk(0) = 0x8067888 brk(0x8068000) = 0x8068000 uname({sys="Linux", node="irvine", ...}) = 0 brk(0) = 0x8068000 brk(0x8069000) = 0x8069000 gettimeofday({1051646849, 576034}, NULL) = 0 getpid() = 4326 open("/etc/resolv.conf", O_RDONLY) = 3 fstat64(3, {st_mode=S_IFREG|0644, st_size=43, ...}) = 0 old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x40015000 read(3, "domain archipelago\nnameserver 17"..., 4096) = 43 read(3, "", 4096) = 0 close(3) = 0 munmap(0x40015000, 4096) = 0 socket(PF_UNIX, SOCK_STREAM, 0) = 3 connect(3, {sa_family=AF_UNIX, path="/var/run/.nscd_socket"}, 110) = 0 writev(3, [{"\2\0\0\0\4\0\0\0\7\0\0\0", 12}, {"irvine\0", 7}], 2) = 19 read(3, "\2\0\0\0\377\377\377\377\0\0\0\0\0\0\0\0\377\377\377\377"..., 32) = 32 close(3) = 0 open("/etc/nsswitch.conf", O_RDONLY) = 3 fstat64(3, {st_mode=S_IFREG|0644, st_size=1291, ...}) = 0 old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x40015000 read(3, "#\n# /etc/nsswitch.conf\n#\n# An ex"..., 4096) = 1291 read(3, "", 4096) = 0 close(3) = 0 munmap(0x40015000, 4096) = 0 open("/etc/ld.so.cache", O_RDONLY) = 3 fstat64(3, {st_mode=S_IFREG|0644, st_size=45920, ...}) = 0 old_mmap(NULL, 45920, PROT_READ, MAP_PRIVATE, 3, 0) = 0x40015000 close(3) = 0 open("/lib/libnss_files.so.2", O_RDONLY) = 3 read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0p\35\0\000"..., 1024) = 1024 fstat64(3, {st_mode=S_IFREG|0755, st_size=42881, ...}) = 0 old_mmap(NULL, 38492, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) = 0x4019c000 mprotect(0x401a5000, 1628, PROT_NONE) = 0 old_mmap(0x401a5000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 3, 0x8000) = 0x401a5000 close(3) = 0 munmap(0x40015000, 45920) = 0 open("/etc/host.conf", O_RDONLY) = 3 fstat64(3, {st_mode=S_IFREG|0644, st_size=370, ...}) = 0 old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x40015000 read(3, "#\n# /etc/host.conf - resolver co"..., 4096) = 370 read(3, "", 4096) = 0 close(3) = 0 munmap(0x40015000, 4096) = 0 open("/etc/hosts", O_RDONLY) = 3 fcntl64(3, F_GETFD) = 0 fcntl64(3, F_SETFD, FD_CLOEXEC) = 0 fstat64(3, {st_mode=S_IFREG|0644, st_size=860, ...}) = 0 old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x40015000 read(3, "#\n# hosts This file desc"..., 4096) = 860 read(3, "", 4096) = 0 close(3) = 0 munmap(0x40015000, 4096) = 0 ioctl(0, SNDCTL_TMR_TIMEBASE, {B38400 opost isig icanon echo ...}) = 0 rt_sigprocmask(SIG_BLOCK, NULL, [RTMIN], 8) = 0 open("/etc/services", O_RDONLY) = 3 fcntl64(3, F_GETFD) = 0 fcntl64(3, F_SETFD, FD_CLOEXEC) = 0 fstat64(3, {st_mode=S_IFREG|0644, st_size=304796, ...}) = 0 old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x40015000 read(3, "#\n# Network services, Internet s"..., 4096) = 4096 close(3) = 0 munmap(0x40015000, 4096) = 0 open("/etc/hosts", O_RDONLY) = 3 fcntl64(3, F_GETFD) = 0 fcntl64(3, F_SETFD, FD_CLOEXEC) = 0 fstat64(3, {st_mode=S_IFREG|0644, st_size=860, ...}) = 0 old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x40015000 read(3, "#\n# hosts This file desc"..., 4096) = 860 close(3) = 0 munmap(0x40015000, 4096) = 0 fstat64(1, {st_mode=S_IFCHR|0600, st_rdev=makedev(136, 5), ...}) = 0 old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x40015000 write(1, "Trying 10.40.40.7...\r\n", 22Trying 10.40.40.7... ) = 22 socket(PF_INET, SOCK_STREAM, IPPROTO_TCP) = 3 setsockopt(3, SOL_IP, IP_TOS, [16], 4) = 0 connect(3, {sa_family=AF_INET, sin_port=htons(23), sin_addr=inet_addr("10.40.40.7")}, 16) = -1 ECONNREFUSED (Connection refused) write(2, "telnet: connect to address 10.40"..., 58telnet: connect to address 10.40.40.7: Connection refused ) = 58 close(3) = 0 munmap(0x40015000, 4096) = 0 exit_group(1) = ? vince@irvine:~>
Well, your strace outputs show that it's a glibc problem, not a KDE one. KDE can't control what is going on, but we could probably help it. What is going on is that libnss_files can't resolve 10.40.40.7 from /etc/hosts, so the resolution is passed down to DNS. I've tested my computer and I get the same behaviour. However, when 10.40.40.7 is present in /etc/hosts, libnss_files can do the resolution and comes up with the IP -- surprise surprise! -- 10.40.40.7. The test for a numeric IP should be done before a true resolution is attempted. I'll see about adding a workaround for that in KDE 3.1.x (KDE_3_1_BRANCH). The upcoming version in HEAD will use different resolution code which should handle this automatically.
I would like to see this implimented as well. I have the exact same issue here. Being on a home LAN, I perfer to use the older IPv4 addresses. Thanks! Marshall Heartley
I believe I have fixed this problem now with the new libraries. It's still not yet in CVS because I'm doing some testing before committing, but it'll be there soon.