Re: 2.0.13 Sockets Stuck on close

Eric Schenk (
Wed, 21 Aug 1996 17:38:32 -0400

Christoph Lameter <> writes:
>schenk>I've seen at least one USR clone that caused me a similar problem.
>schenk>In any case, you might want to check how often your modem is retransmitting
>schenk>(Your modem should have some kind of self diagnosis output for the last
>schenk>session. Check the modem manual for the exact command, it changes from
>schenk>one brand to the next.)
>When the modem slows down due to transmission problems then the ping
>packets will also be affected. When the telnet session stalls ping does
>still work fine. Cannot be the modem in those cases.

The problem I saw actually could be aleviated by flooding the line
with pings. The problem was that the modem started getting into a state
where it wanted more characters before it would send anything.
Sending pings put it over the edge of its buffer and it started
sending again. This was tracked down to a firmware revision problem
in the cheapo USR clone I had. I understand that real USR 28.8 and 33.3k
modems had the same problem in some firmware revisions.
Anyway, this isn't necessarily the problem you are seeing.

>schenk>Can you be more specific about what you mean here? What observable
>schenk>behavior does pppd exhibit?
>The user hangs up and pppd continues to run. The modem port is not freed
>up and blocked. pppd continually runs in the R state. This happens on a
>busy dialup system once every two weeks or so.

Ok. If you kill pppd does the modem port become usable again, or does
it stay stuck? Also, what are the options passed to pppd (either in
a file like /etc/ppp/options or in the command line).

>I did the strace when it was already looping and had no output.

Hmm. It must be stuck in a loop where it doesn't make
any system calls. Try compiling with "-g", then attach gdb to a
stuck pppd to see where it is looping.

>schenk>Running tcpdump on the ppp interface will give you the traffic
>schenk>that is actually going over the link. This will be much more useful
>schenk>for telling what is going on.

>Its rather difficult to run tcpdump since the machines may be quite busy.
>But I see what I can do next time it happens.

You can give tcpdump a filter rule to have it only dump out packets
for a particular IP address. This might cut things down enough to
be useful if you know the session that is showing the slow down.

-- eric

Eric Schenk www:
Department of Computer Science email:
University of Toronto