Bug 9182 - modem fails to respond after disconnect
modem fails to respond after disconnect
Status: CLOSED NOTABUG
Product: Red Hat Linux
Classification: Retired
Component: rp3 (Show other bugs)
6.1
i386 Linux
medium Severity high
: ---
: ---
Assigned To: Nalin Dahyabhai
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2000-02-07 11:52 EST by Martin Bly
Modified: 2008-05-01 11:37 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2002-12-13 21:32:52 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Martin Bly 2000-02-07 11:52:23 EST
Two manefestations of the same problem: an internal ISA
modem fails to respond to requests to initiate a dialout:

1/  After a disconnect (user initiated) from a dialup
    session to my ISP, attempts to redial later (minutes
    to hours later) are met with `Sorry, the modem does not
    respond'.   This is only cleared (sometimes) by a
    power off halt and restart.

2/  One in two or so restarts or cold starts results in
    the same `Sorry, the modem does not respond' message.

In either case, attempting connection with /sbin/ifup ppp0
fails to prod the modem to life.

Repeaded dialup works fine on the same hardware with
Win95OSR2 and worked fine on RedHat 6.0 until I upgraded
to 6.1.  I have both the rp3-1.0.1-1 and ppp-2.3.10-3
updates and did have the instantaneous drop and redial
problem that is fixed by rp3-1.0.1-1 .

Martin.
Comment 1 Nalin Dahyabhai 2000-02-07 14:59:59 EST
Is your modem by any chance plug-n-play?  Can you send in the contents of your
/etc/sysconfig/network-scripts/ifcfg-ppp0 and /etc/wvdial.conf files (with any
sensitive information like passwords replaced with dummy data) so that I can try
to figure out where things are going wrong?
Comment 2 Martin Bly 2000-02-08 08:39:59 EST
It isn't a pnp modem.  It is a Pureteck 3911 ISA modem, sitting
at IRQ3 on COM4 (ttyS3).
Comment 3 Nalin Dahyabhai 2000-02-08 19:31:59 EST
I see WVDIALSECT is set to ppp0 in your ifcfg-ppp0 file, and wvdial.conf has
the Modem directive in the section set to "/dev/modem".  Is this symlink
properly set to your modem's port?  Do you perhaps have a stale lock file in
/var/lock/LCK..modem that might not be getting removed properly?
Comment 4 Martin Bly 2000-02-09 19:03:59 EST
No, the /var/lock/LCK..modem file dissapears when I close down successful
connections and doesn't appear to be there when I cold start and get
connection failures.  /dev/modem points to /dev/ttyS3:
% ls -o /dev/modem
lrwxrwxrwx   1 root            5 May  2  1999 /dev/modem -> ttyS3

During a failed connection attempt when the modem fails to respond, the
proceses present are:
  567 tty1     S      0:00 rp3
  569 tty1     S      0:00 /sbin/ppp-watch ifcfg-ppp0
  591 ?        S      0:00 /sbin/ppp-watch ifcfg-ppp0
  593 ttyS3    S      0:00 /usr/sbin/pppd -detach lock modem crtscts
defaultroute usepeerdns mru 1500 mtu 1500 name *login_name* debug /dev/modem
57600 remotename ppp0 ipparam ppp0 linkname ppp0 noauth connect /usr/bin/wvdial
--remotename ppp0 --chat ppp0

with no /usr/bin/wvdial process.  Strange that there are two ppp-watch
processes.

The processes for a sucessfull connection end up as:
  571 tty1     S      0:00 rp3
  595 ?        S      0:00 /sbin/ppp-watch ifcfg-ppp0
  597 ttyS3    S      0:00 /usr/sbin/pppd -detach lock modem crtscts
defaultroute usepeerdns mru 1500 mtu 1500 name mjbly.freeserve.co.uk debug
/dev/modem 57600 remotename ppp0 ipparam ppp0 linkname ppp0 noauth connect
/usr/bin/wvdial --remotename ppp0 --chat ppp0

There were two ppp-watch processes and one with /usr/bin/wvdial.  (Is one
ppp-watch monitoring the wvdial?).
Comment 5 Nalin Dahyabhai 2000-02-29 08:53:59 EST
The ppp-watch program fork()s a child off to bring the connection up or down,
and the parent monitors the process, which is expected.  Can you send in the
log messages generated by the dialer?
Comment 6 Martin Bly 2000-03-16 09:32:59 EST
It's a hardware problem.  Testing over time with a different modem
shows no hint of this problem.

The modem that does show the problem runs its Rockwell chip considerably
hot to the touch so I suspect it has taken a line spike during a storm
some time back.  I can't pin point a storm on date after which the
problem started but it is the most likely cause.

I think we should close this one...
Comment 7 Nalin Dahyabhai 2000-03-16 17:37:59 EST
It's possible, but I've got one last thing you might want to try: change the
init strings in /etc/wvdial.conf (sorry, no way to configure it with rp3) that
wvdial uses to just "ATZ".  Another bug report with a Zoom modem (the last one
I had used a Rockwell chipset) managed to solve the problem this way.  The bug
ID number is 7760.
Comment 8 Martin Bly 2000-07-10 04:46:32 EDT
Makes no difference what init strings I use, the modem still 
misbehaves.

I think this one should be closed out - I have been using a new
modem for a while and that has shown no problems at all with the
same setup as used before.  Put the problem down to a line spike
cooking part of the chip.

Martin.
Comment 9 Alan Cox 2002-12-13 21:32:52 EST
No new reports for a long time, assuming hw funny

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