Bug 182018

Summary: Modem time delays in wvdial-1.54.0 broken due to WVstreams problem
Product: Red Hat Enterprise Linux 4 Reporter: Mr. David I. Emery <die>
Component: wvdialAssignee: Ondrej Vasik <ovasik>
Status: CLOSED WONTFIX QA Contact: David Lawrence <dkl>
Severity: medium Docs Contact:
Priority: medium    
Version: 4.0   
Target Milestone: ---   
Target Release: ---   
Hardware: i686   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2010-03-04 09:56:09 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:

Description Mr. David I. Emery 2006-02-19 06:30:48 UTC
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.

Comment 1 RHEL Program Management 2008-02-01 19:13:30 UTC
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 "?".

Comment 2 Ondrej Vasik 2010-03-04 09:56:09 UTC
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.