My machine is taking 10 seconds to establish a connection. Once the connection is established, it is up to speed and works correctly. But if I for example ping www.google.com, it takes 5 seconds for

PING www.l.google.com ( 56(84) bytes of data.

to show up, and 5 more seconds for each

64 bytes from ag-in-f147.google.com ( icmp_seq=1 ttl=243 time=100 ms

to show up.

My only clue is that I recently disconnected my computer from the Ethernet cable and rebooted it.

I use a static IP address and my router is configured correctly. My computer is the only one connected to the router that has this problem.

What configuration can I check to solve this problem?



Make sure that your reverse DNS is working properly. You can verify this by typing "ping -n www.google.com". Immediate responses.

  • Is this something I need to fix on my router or on my desktop? – andrewrk Jul 17 '09 at 3:13
  • +1 sounds like dns is the most likely issue here. – theotherreceive Jul 17 '09 at 3:15
  • 2
    superjoe: What are you using as your DNS server, because that's what is having the problem. You type "ping www.google.com" and your computer looks up www.google.com in DNS, and resolves it to the IP. Then, when it pings that IP, it does reverse resolution on that IP to get a hostname. That's the part that's failing, so your DNS server is having issues looking up reverse records. Since the resolution happens eventually (it gets ag-in-f147.google.com), your primary DNS may be faulty, and it may be reverting to your secondary. If they're static, try switching them. – Matt Simmons Jul 17 '09 at 3:23
  • One concern is that he said something about each ping taking 5 seconds, which isn't really born out in the ping line he pasted, but I'd be surprised if ping did a DNS lookup for every packet. If superjoe could clarify that. – David Pashley Jul 17 '09 at 6:38
  • David: I've seen this probably hundreds of times in around 12 years. You can mimic the error by "breaking" your resolv.conf. – Matt Simmons Jul 17 '09 at 11:25

Yes, a DNS problem. The solution was to edit /etc/resolv.conf.

The primary server was when it should have been Fixed that and the problem went away immediately.

The problem was caused by upgrading with aptitude full-upgrade, which overwrote the configuration file. Should probably report this to Debian Squeeze developers.

  • Awesome. Glad that worked out for you! – Matt Simmons Jul 17 '09 at 11:26
  • 2
    This is somewhat academic at this point, but you didn't have to bounce your network stack; changes to resolv.conf become effective immediately. – ktower Jul 17 '09 at 15:37

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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