Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

Has anyone ever seen this before? Note that this happens not only with google.com, but with every domain I try. It's a wireless connection (WEP), but I'm not sure how that would be relevant:

$ curl -v google.com
# This takes about 60s to return
* getaddrinfo(3) failed for google.com:80
* Couldn't resolve host 'google.com'
* Closing connection #0
curl: (6) Couldn't resolve host 'google.com'

$ wget google.com
--2011-11-28 14:44:08--  http://google.com/
Resolving google.com... failed: Name or service not known.
wget: unable to resolve host address `google.com'

$ ping google.com
PING google.com (209.85.148.147) 56(84) bytes of data.
64 bytes from fra07s07-in-f147.1e100.net (209.85.148.147): icmp_req=2 ttl=54 time=136 ms
64 bytes from fra07s07-in-f147.1e100.net (209.85.148.147): icmp_req=3 ttl=54 time=34.0 ms
64 bytes from fra07s07-in-f147.1e100.net (209.85.148.147): icmp_req=4 ttl=54 time=34.3 ms
64 bytes from fra07s07-in-f147.1e100.net (209.85.148.147): icmp_req=5 ttl=54 time=42.5 ms
64 bytes from fra07s07-in-f147.1e100.net (209.85.148.147): icmp_req=6 ttl=54 time=44.7 ms
64 bytes from fra07s07-in-f147.1e100.net (209.85.148.147): icmp_req=7 ttl=54 time=34.5 ms
^C
--- google.com ping statistics ---
8 packets transmitted, 6 received, 25% packet loss, time 7007ms
rtt min/avg/max/mdev = 34.063/54.376/136.026/36.758 ms


$ host google.com
google.com has address 209.85.148.106
google.com has address 209.85.148.147
google.com has address 209.85.148.99
google.com has address 209.85.148.103
google.com has address 209.85.148.104
google.com has address 209.85.148.105
google.com mail is handled by 30 alt2.aspmx.l.google.com.
google.com mail is handled by 40 alt3.aspmx.l.google.com.
google.com mail is handled by 50 alt4.aspmx.l.google.com.
google.com mail is handled by 10 aspmx.l.google.com.
google.com mail is handled by 20 alt1.aspmx.l.google.com.

$ host google.com 192.168.1.201
Using domain server:
Name: 192.168.1.201
Address: 192.168.1.201#53
Aliases: 

google.com has address 209.85.148.103
google.com has address 209.85.148.104
google.com has address 209.85.148.105
google.com has address 209.85.148.106
google.com has address 209.85.148.147
google.com has address 209.85.148.99
google.com mail is handled by 40 alt3.aspmx.l.google.com.
google.com mail is handled by 50 alt4.aspmx.l.google.com.
google.com mail is handled by 10 aspmx.l.google.com.
google.com mail is handled by 20 alt1.aspmx.l.google.com.
google.com mail is handled by 30 alt2.aspmx.l.google.com.

$ cat /etc/resolv.conf 
# Generated by NetworkManager
nameserver 192.168.1.201

$ cat /etc/hosts
127.0.0.1       localhost
::1             localhost

$ netstat -rn
Kernel IP routing table
Destination     Gateway         Genmask         Flags   MSS Window  irtt Iface
0.0.0.0         192.168.1.254   0.0.0.0         UG        0 0          0 wlan0
127.0.0.0       127.0.0.1       255.0.0.0       UG        0 0          0 lo
192.168.1.0     0.0.0.0         255.255.255.0   U         0 0          0 wlan0

Basically any application, including Firefox, can't work to do name lookups. What's more, if I take the wifi offline and plug in an ethernet cable, everything is fine.

share|improve this question
1  
Maybe add some more info - is it just curl ? What about wget, browsers, ping etc. ? –  Sandman4 Nov 28 '11 at 8:39
    
I see you marked an answer but what exactly was the issue and solution? Was it an SELinux problem? –  Belmin Fernandez Nov 28 '11 at 17:10
    
The "solution" was just that the network appears to be right-gibbled. I'm not running any SELinux on the laptop and the "network" is just managed by a crappy store-bought wifi router. That answer was the one to help me figure out that I was dropping packets all over the place, so I figured it was something I couldn't solve and gave that guy the credit. Why, do you have a better idea? –  Daniel Quinn Nov 29 '11 at 14:20

4 Answers 4

up vote 4 down vote accepted

Perhaps you have some very weird and restrictive SELinux (or grsecurity...) rules in place?

If not, try strace -o /tmp/wtf -fF curl -v google.com and try to spot from /tmp/wtf output file what's going on.

share|improve this answer
    
Looks like it's the wifi connection itself. The output file is FULL of stuff like this: 9344 poll([{fd=3, events=POLLIN|POLLPRI|POLLRDNORM|POLLRDBAND}], 1, 1000) = 0 (Timeout) –  Daniel Quinn Nov 28 '11 at 10:44
    
@Daniel Quinn, can you post output of /tmp/wtf? –  Sachin Divekar Nov 28 '11 at 10:44
    
Here's the output: pastebin.com/1y5Z48NK –  Daniel Quinn Nov 28 '11 at 12:49
    
Hmm, looks like it's doing the query to 192.168.1.201. Can you do "host google.com 192.168.1.201" for sanity? Basically, DNS lookup specifically against your DNS server. –  cjc Nov 28 '11 at 12:57
    
Done (added it to the question). And that works just fine -- which makes sense since issuing host without a server argument works correctly as well. It looks like it's just actual HTTP calls too, since ICMP (mostly, it drops the first ping) works. –  Daniel Quinn Nov 28 '11 at 13:00

Using this: https://www.centos.org/modules/newbb/viewtopic.php?topic_id=39343

I found a key command that helped me troubleshoot:

[root@localhost ~]# wget -6 URL Failed

[root@localhost ~]# wget -4 URL Worked

It's something to do with the default ipv6 stack that's causing problems with certain utils. Disable ipv6 to resolve.

share|improve this answer

Check your /etc/nsswitch.conf. If the hosts line says something like

hosts:      files dns

I'm as confused as you. But if it says something like

hosts:      files

then the fact that DNS is working (see output of host command) won't help curl, which is doing name resolution via the standard OS libraries, which have been told not to use the DNS.

share|improve this answer
    
Hmm. I hadn't thought of that, but I just checked and it says files dns so I guess that's not it :-( –  Daniel Quinn Nov 28 '11 at 8:49

Was your curl installation smooth? If possible try re-installing curl.

Try curl -v google.com to get more verbose output for debugging.

e.g.:

curl -v dnserror.test
* getaddrinfo(3) failed for dnserror.test:80
* Couldn't resolve host 'dnserror.test'
* Closing connection #0
curl: (6) Couldn't resolve host 'dnserror.test'

Are you getting similar output?

share|improve this answer
    
Exactly the same :-( I've updated the question with the output. –  Daniel Quinn Nov 28 '11 at 9:35

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.