How to diagnose a hung ppp connection.

This commit is contained in:
Brian Somers 1999-01-31 18:58:22 +00:00
parent 1841ad7ec8
commit 088ad7e8b1
Notes: svn2git 2020-12-08 03:00:23 +00:00
svn path=/head/; revision=4159

View file

@ -1,4 +1,4 @@
<!-- $Id: network.sgml,v 1.20 1999-01-27 10:01:08 mbarkah Exp $ -->
<!-- $Id: network.sgml,v 1.21 1999-01-31 18:58:22 brian Exp $ -->
<!-- The FreeBSD Documentation Project -->
<sect>
@ -317,6 +317,82 @@ default 10.0.0.2 UGSc 0 0 tun0
<p>Refer to your modem manual for details.
<sect2>
<heading>My connection hangs after a random amount of time</heading>
<p>Many people experience hung connections with no apparent
explaination. The first thing to establish is which side of the
link is hung.
<p>If you are using an external modem, you can simply try using
<tt/ping/ to see if the <tt/TD/ light is flashing when you
transmit data. If it flashes (and the <tt/RD/ light doesn't), the
problem is with the remote end. If <tt/TD/ doesn't flash, the problem
is local. With an internal modem, you'll need to use the <tt/set
server/ command in your <tt/ppp.conf/ file. When the hang occurs,
connect to ppp using pppctl. If your network connection suddenly
revives (ppp was revived due to the activity on the diagnostic socket)
or if you can't connect (assuming the <tt/set socket/ command
succeeded at startup time), the problem is local. If you can connect
and things are still hung, enable local async logging with <tt/set log
local async/ and use <tt/ping/ from another window or terminal to make
use of the link. The async logging will show you the data being
transmitted and received on the link. If data is going out and not
coming back, the problem is remote.
<p>Having established whether the problem is local or remote,
you now have to possibilities:
<sect3>
<heading>The remote end isn't responding</heading>
<p>There's very little you can do about this. Most ISPs will
refuse to help if you're not running a Microsoft OS. You can
<tt/enable lqr/ in your <tt/ppp.conf/ file, allowing ppp to
detect the remote failure and hang up, but this detection is
relatively slow and therefore not that useful. You may want
to avoid telling your ISP that you're running user-ppp....
<p>First, try disabling all local compression by adding the
following to your configuration:
<verb>
disable pred1 deflate deflate24 protocomp acfcomp shortseq vj
deny pred1 deflate deflate24 protocomp acfcomp shortseq vj
</verb>
<p>Then reconnect to ensure that this makes no difference.
If things improve or if the problem is solved completely,
determine which setting makes the difference through trial
and error. This will provide good amunition when you contact
your ISP (although it may make it apparent that you're not
running a Microsoft product).
<p>Before contacting your ISP, enable async logging locally
and wait until the connection hangs again. This may use up
quite a bit of disk space. The last data read from the port
may be of interest. It is usually ascii data, and may even
describe the problem (``Memory fault, core dumped'' ?).
<p>If your ISP is helpful, they should be able to enable logging
on their end, then when the next link drop occurs, they may be
able to tell you why their side is having a problem. Feel free
to send the details to <url url="mailto:brian@Awfulhak.org"
name="brian@Awfulhak.org">, or even to ask your ISP to
contact me directly.
<sect3>
<heading>Ppp is hung</heading>
<p>Your best bet here is to rebuild ppp by adding <tt/CFLAGS+=-g/
and <tt/STRIP=/ to the end of the Makefile, then doing a
<tt/make clean &amp;&amp; make &amp;&amp; make install/. When
ppp hangs, find the ppp process id with <tt/ps ajxww | fgrep ppp/
and run <tt/gdb ppp PID/. From the gdb prompt, you can then use
<tt/bt/ to get a stack trace.
<p>Send the results to <url url="mailto:brian@Awfulhak.org"
name="brian@Awfulhak.org">.
<sect2>
<heading>Nothing happens after the Login OK! message</heading>