Re: 2.0.13 Sockets Stuck on close

Christoph Lameter (
Wed, 21 Aug 1996 14:05:02 -0700 (PDT)

I will follow your suggestions when the situation comes up again. I can
cause the stalling telnet sessions easily but the other two issues are
totally sporadic.

On Wed, 21 Aug 1996, Eric Schenk wrote:
schenk>>As I have reported earlier: Telnet sessions get slower and slower until
schenk>>they come to a standstill. SendQ is showing a couple of kilobytes to
schenk>>be transferred. A ping usually gets the session going again. Also
schenk>>starting up another telnet session to the machine showing the stalling
schenk>>runs at full speed. This is across a PPP Link with a 28.8K Modem between
schenk>>two (or three) machines running 2.0.12/13 with the Debian 1.1
schenk>Hmm. Can you take a tcpdump of a telnet session and mark the slowdown
schenk>times for me? I can't even begin to guess what is going on here.
schenk>It _sounds_ like an MTU mismatch problem, but that should not be
schenk>possible with a PPP link. Hmm, while I'm at it, what kind of Modem is it?
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.

schenk>>It also leads to flaky network behaviour because pppd's sometimes just
schenk>>start looping. They are not part of the kernel network code true.
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.

schenk>>I tried to strace the pppd's but I did not get any output. How can I
schenk>>further observe what is going on?
schenk>How did you attempt to run the strace? pppd does a fork just after
strace -p<process id of the pppd>

schenk>starting so it's a bit difficult to run strace on it directly.
schenk>Try attaching strace to the running pppd process after it starts.
schenk>(Check the strace manual page for how to do that.)
I did the strace when it was already looping and had no output.

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.

{} Snail Mail: FTS Box 466, 135 N.Oakland Ave, Pasadena, CA 91182 {}
{} FISH Internet System Administrator at Fuller Theological Seminary {}
PGP Public Key = FB 9B 31 21 04 1E 3A 33 C7 62 2F C0 CD 81 CA B5