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
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.
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.
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.