Bug 9182
| Summary: | modem fails to respond after disconnect | ||
|---|---|---|---|
| Product: | [Retired] Red Hat Linux | Reporter: | Martin Bly <bly> |
| Component: | rp3 | Assignee: | Nalin Dahyabhai <nalin> |
| Status: | CLOSED NOTABUG | QA Contact: | |
| Severity: | high | Docs Contact: | |
| Priority: | medium | ||
| Version: | 6.1 | CC: | bly, herscheld |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | i386 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| 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: | --- | Target Upstream Version: | |
| Embargoed: | |||
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 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?). 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 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. No new reports for a long time, assuming hw funny |
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.