Bug 4226 - Modem non-responsive after pppd disconnects
Summary: Modem non-responsive after pppd disconnects
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: ppp
Version: 6.0
Hardware: i386
OS: Linux
Target Milestone: ---
Assignee: Michael K. Johnson
QA Contact:
Depends On:
TreeView+ depends on / blocked
Reported: 1999-07-27 18:50 UTC by hdb
Modified: 2008-05-01 15:37 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 1999-09-25 05:32:08 UTC

Attachments (Terms of Use)

Description hdb 1999-07-27 18:50:00 UTC
This is long, so I apologize in advance.

After upgrading from RH5.1 to 6.0 I have developed a modem
related problem.  The best I can tell, no one else seems to
be having this problem so it must be caused by curious
combination of factors. The problem is also sporadic so has
been a little hard to get a grip on, but essentially I wind
up with a completely dead modem. Chat hangs at the first
reference to /dev/modem (or /dev/ttySx) eg, '' ATZ.
Substitute anything you want for ATZ.  statserial hangs,
stty /dev/modem hangs, strace hangs, echo AT > /dev/ttySx
from bash prompt hangs. The last one gives a 'bash:
interrupted system call' when terminated with CTRL-C.  Using
all RH updates on intel. pppd is ppp-2.3.7-2, also tried
2.3.8-1. Modem is an external 56k Diamond.  I've tried
reinstalling various packages too. Modem is ttyS0, mouse on
ttyS1, no other serial devices.  No apparent IRQ conflitts.

The only way back to a sane modem is either reboot or start
minicom letting it initialize the modem and then exit
*without* resetting.  This always works. I presume minicom
is doing its thing at a lower level and is thus bypassing
whatever is flaky at the user level. The modem also works
fine if I use dosemu with a DOS comm program there, even if
the modem is simultaneouly hung in linux. I think this
pretty much eliminates a possible hardware problem. And it
is not a lock file problem, I've searched high and low for

While this scenario can occur randomly it is much more likey
to occur after a dropped connection or if pppd fails to
establish a connection. In fact, I would say pretty much
everytime I'd get a lifeless modem here. It does, however,
occasionally occur even after a routine ppp-down, but is
much less likely in this case.  Another factor may be noisy
phone lines that I am forced to deal with here.  I regularly
have a tough time getting a reliable connection. So maybe
this is a little more of an annoyance to me than someone
that has the good fortune to not have to deal with this.
Perhaps this is a factor either directly or indirectly.
Dunno. But again, this never once happened before the
upgrade, now pretty much a daily event. Other than this
problem, everything else on the system is running

The reason I am digressing here is that I feel there is an
obscure bug somewhere but am not exactly sure where and
probably I should report it but don't know to whom. Have no
idea whether this is pppd not returning modem to a sane
state, or whether it is something else in the OS that pppd
is relying on.

FWIW, this snippet gives me back access to modem when it is

int main(void) {
  minp = open("/dev/modem", O_RDWR | O_NOCTTY | O_NONBLOCK);
  if(minp < 0) {
    perror("cannot open /dev/modem");
    return EXIT_FAILURE;

  retval = tcgetattr ( minp, &old_termios);
  if(retval != 0) {
    perror("cannot use tcgetattr");
    return EXIT_FAILURE;

  old_termios.c_cflag = old_termios.c_cflag | CLOCAL;

  retval = tcsetattr( minp, TCSAFLUSH, & old_termios );
  if(retval != 0) {
    perror("cannot use tcsetattr");
    return EXIT_FAILURE;

  return EXIT_SUCCESS;


I am not nearly smart enough to come up with this. It is
courtesy of Mark Gray who I happened into on the RH list.
Thanks Mark!

While I can now access the modem after running this bit,
pppd will still consistently fail to connect. If I pump a
saved version of 'stty -g' back through stty, then all is
well again.  ;) (This idea also from Mark.) If I was smart
enough I would be better able to give a more precise source
of the problem even though I've been trying to track this
down for 4-5 weeks now.  Maybe someone else can get to the
bottom of it.

Comment 1 Michael K. Johnson 1999-09-25 05:32:59 UTC
As far as I can tell, I have completely solved this problem.

The bad news is that it took a rearchitecting of the whole way
we manage PPP connections.  You can install the new initscripts
from rawhide, along with everything else that the new initscripts
package requires, and try that out, or you can wait for Red Hat
Linux 6.1 and see if it solves your problem.  I'm going to label
this as fixed in the next release; please reopen the bug report
if either of these two approaches fails to solve the problem.

Note You need to log in before you can comment on or make changes to this bug.