Bug 9182 - modem fails to respond after disconnect
Summary: modem fails to respond after disconnect
Status: CLOSED NOTABUG
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: rp3   
(Show other bugs)
Version: 6.1
Hardware: i386
OS: Linux
medium
high
Target Milestone: ---
Assignee: Nalin Dahyabhai
QA Contact:
URL:
Whiteboard:
Keywords:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2000-02-07 16:52 UTC by Martin Bly
Modified: 2008-05-01 15:37 UTC (History)
2 users (show)

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


Attachments (Terms of Use)

Description Martin Bly 2000-02-07 16:52:23 UTC
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 19:59:59 UTC
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 13:39:59 UTC
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-09 00:31:59 UTC
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-10 00:03:59 UTC
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 13:53:59 UTC
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 14:32:59 UTC
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 22:37:59 UTC
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 08:46:32 UTC
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-14 02:32:52 UTC
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.