 <p><strong>Q</strong>: How can I have DNS name resolving running while other protocols seem to be down?</p> <p><strong>A</strong>: Your local DNS resolver (<code>bind</code> is another possibility besides <code>ncsd</code>) <em>might</em> be caching the first response. <code>dig</code> will tell you where you are getting the response from:</p> <pre><code>[mpenning@Bucksnort ~]$ dig cisco.com ; &lt;&lt;&gt;&gt; DiG 9.6-ESV-R4 &lt;&lt;&gt;&gt; +all cisco.com ;; global options: +cmd ;; Got answer: ;; -&gt;&gt;HEADER&lt;&lt;- opcode: QUERY, status: NOERROR, id: 22106 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 0 ;; QUESTION SECTION: ;cisco.com. IN A ;; ANSWER SECTION: cisco.com. 86367 IN A 198.133.219.25 ;; AUTHORITY SECTION: cisco.com. 86367 IN NS ns2.cisco.com. cisco.com. 86367 IN NS ns1.cisco.com. ;; Query time: 1 msec &lt;----------------------- 1msec is usually cached ;; SERVER: 127.0.0.1#53(127.0.0.1) &lt;--------------- Answered by localhost ;; WHEN: Wed Dec 7 04:41:21 2011 ;; MSG SIZE rcvd: 79 [mpenning@Bucksnort ~]$ </code></pre> <p>If you are getting a very quick (low milliseconds) answer from <code>127.0.0.1</code>, then it's very likely that you're getting a locally cached answer from a prior query of the same DNS name (and it's quite common for people to use caching DNS resolvers on a <code>ppp</code> connection to reduce connection time, as well as achieving a small load reduction on the ppp link).</p> <p>If you suspect a cached answer, do a <code>dig</code> on some other DNS name to see whether it can resolve too.</p> <ul> <li>If random DNS names continue resolution and you still cannot make a TCP connection to a certain host, this is worthy of noting when you edit the question after this investigation.</li> <li>If random DNS names don't resolve, then this is indicative of something like the loss of your default route, or the <code>ppp</code> connection going down.</li> </ul> <h2>Other diagnostic information</h2> <p>If you find yourself in either of the last situations I described, you need to do some IP and ppp-level debugs before this can be isolated further. As someone mentioned, <code>tcpdump</code> is quite valuable at this point, but it sounds like you don't have it available.</p> <p>I assume you are not making a TCP connection to the same IP address of your DNS server. There are many possibilities at this point... If you can still resolve random DNS names, but TCP connections are failing, it is possible that the problem you are seeing is on the other side of the ppp connection, that the kernel routing cache (which holds a little TCP state information like <code>MSS</code>) is getting messed up, you have too much packet loss for <code>tcp</code>, or any number of things.</p> <p>Let's assume your topology is like this:</p> <pre><code> 10.1.1.2/30 10.1.1.1/30 [ppp0] [pppX] uCLinux----------------------AccessServer----&gt;[To the reset of the network] </code></pre> <p>When you initiate your ppp connection, take note of your IP address and the address of your default gateway:</p> <pre><code>ip link show ppp0 # display the link status of your ppp0 intf (is it up?) ip addr show ppp0 # display the IP address of your ppp0 interface ip route show # display your routing table route -Cevn # display the kernel's routing cache </code></pre> <p>Similar results can be found if you don't have the <code>iproute2</code> package as part of your distro (<code>iproute2</code> provides the <code>ip</code> utility):</p> <pre><code>ifconfig ppp0 # display link status and addresses on ppp0 netstat -rn # display routing table route -Cevn # display kernel routing table </code></pre> <p>For those with the <code>iproute2</code> utilities (which is almost everybody these days), <code>ifconfig</code> has been deprecated and replaced by the <code>ip</code> commands; however, if you have an older 2.2 or 2.4-based system you may still need to use <code>ifconfig</code>.</p> <p><strong>Troubleshooting steps</strong>:</p> <ol> <li><p>When you start having the problem, first check whether you can ping the address of <code>pppX</code> on your access server.</p> <ul> <li>If you can not ping the ip address of <code>pppX</code> on the other side, then it is highly unlikely your DNS is getting resolved by anything other than a cached response on your uCLinux machine.</li> <li>If you can ping <code>pppX</code>, then try to <code>ping</code> the ip address of your TCP peer and the IP address of the DNS (if it is not on <code>localhost</code>). Unless there is a firewall involved, you must be able to <code>ping</code> it successfully for any of this to work.</li> </ul></li> <li><p>If you can <code>ping</code> the ip address of <code>pppX</code> but you cannot <code>ping</code> your TCP peer's ip address, check your routing table to see whether your default route is still pointing out <code>ppp0</code></p></li> <li><p>If your default route points through <code>ppp0</code>, check whether you can still ping the ip address of the default route.</p></li> <li><p>If you can <code>ping</code> your default route and you can <code>ping</code> the remote host that you're trying to connect to, check the kernel's routing cache for the IP address of the remote TCP host.... look for anything odd or suspicious</p></li> <li><p>If you <em>can</em> <code>ping</code> the remote TCP host (and you need to do about 200 <code>pings</code> to be sure... <code>tcp</code> is sensitive to significant packet loss &amp; GPRS is notoriously lossy), try making a successful <code>telnet &lt;remote_host&gt; &lt;remote_port&gt;</code>. If both are successful, then it's time to start looking inside your software for clues.</p></li> </ol> <p>If you still can't untangle what is happening, please include the output of the aforementioned commands when you come back... as well as how you're starting the <code>ppp</code> connection.</p>