This may be long, and may be boring to most, so I apologize in advance.
I have been hanging out on this list because of a modem related problem
I developed after upgrading from RH5.1 to 6.0. The best I can tell, no
one else is 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
eg, '' ATZ. Substitute anything you want for ATZ. statserial hangs,
stty /dev/modem hangs, echo AT > /dev/modem from bash prompt hangs. The
last one gives a 'bash: interrupted system call' when terminated with
CTRL-C. Using all RH updates. pppd is ppp-2.3.7-2, also tried 2.3.8-1.
Kernel is 2.2.5-22.
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.
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 here I'll get a lifeless
modem. 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.
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. If the later, how to hunt this down? Should I even
worry about it? Maybe something isolated to RedHat?
FWIW, this snippet gives me back access to modem when it is hung:
==========================================================
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;
}
close(minp);
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 mailing list. Thanks Mark!
While I can now access the modem after running this bit, pppd will
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.)
Would appreciate feedback from anyone who thinks this is a problem worth
reporting and to whom.
PS -- Please don't think I am complaining. I am very grateful for all
the wonderful goodies Open Source has brought us! If nothing else, maybe
this will help someone else down the line.
--
Hal B
[EMAIL PROTECTED]
--
Linux helps those who help themselves
-
To unsubscribe from this list: send the line "unsubscribe linux-ppp" in
the body of a message to [EMAIL PROTECTED]
