Red Hat Bugzilla – Bug 182018
Modem time delays in wvdial-1.54.0 broken due to WVstreams problem
Last modified: 2010-03-04 04:56:09 EST
Description of problem: wvdial fails to correctly redial on BUSY, NO CARRIER, NO DIAL TONE and other trainsientl ine errors on a USR Sportster external 56K modem. Problem traced with the aid of a AR Datascope to failures in continue_select(timeout) calls intended to provide short time delays to allow the modem to recover from errors. Current version of code (1.54.0) generates NO measurable time delays when these calls are executed resulting in a fast burst of characters that causes the modem to go deaf until reset by dropping DTR. Version-Release number of selected component (if applicable): wvdial-1.54.0 How reproducible: Attempt to connect to ISP with the phone line unplugged from the modem Steps to Reproduce: 1. Establish a connection with a dial up ISP with higher level options set to make the connection persist (eg redial on disconnect or line error). 2. Unplug phone line from modem interrupting session with ISP. 3. Observe interaction between modem and host on Datascope (or any other RS-232 monitoring tool). Actual results: Modem will be reset and reinitialized then attempt to redial and return a NO DIAL TONE error Then wvdial will fire off a <CR><CR><CR>ATDT<ISP phone number> sequence at high speed with no time delays before or between the <CR>s or the ATDT and the modem will just sit there and hang. This will keep repeating every 30 seconds with the modem staying hung and not attempting to dial or make any further NO DIAL TONE error reports. Expected results: With the time delays coded into wvdial (in wvdialer.cc) actually working, the modem will keep attempting to dial (an audible click of the line relay in my antique Sportster 56 K) and keep reporting back NO DIAL TONE until one reconnects the phone line when it will then happily redial the ISP and restablish the link. Additional info: Problem traced to failure of continue_select calls in the WVstream:: class library used for IO by wvdial. Replacing them with explicit modem->select calls to do the time delays makes everything hunky dory. Currently have no idea what is broken about continue_select mechanism, but hack fix makes the modem redial when it is supposed to and keep my secondary connection up 24/7 as it should be.
This request was evaluated by Red Hat Product Management for inclusion, but this component is not scheduled to be updated in the current Red Hat Enterprise Linux release. If you would like this request to be reviewed for the next minor release, ask your support representative to set the next rhel-x.y flag to "?".
I'm sorry for not addressing the issue in RHEL-4. As libwvstreams nor wvdial are not scheduled for update in RHEL-4.9, I'm closing that bugzilla WONTFIX. If you are still experiencing the issue with RHEL-5, feel free to reopen it against RHEL-5.