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: http://www.cs.toronto.edu/~schenk
Department of Computer Science email: schenk@cs.toronto.edu
University of Toronto