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 .
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?
It isn't a pnp modem. It is a Pureteck 3911 ISA modem, sitting
at IRQ3 on COM4 (ttyS3).
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?
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
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?).
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?
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...
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.
Makes no difference what init strings I use, the modem still
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.
No new reports for a long time, assuming hw funny