See the original report at
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=182018 - if this has
since been fixed, we should let them know.
Description of problem: wvdial fails to correctly redial on BUSY, NO
CARRIER, NO DIAL TONE and other trainsient line 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.
What steps will reproduce the problem?
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).
What is the expected output? What do you see instead?
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
reestablish the link.
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.
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.
Original issue reported on code.google.com by peter.mc...@gmail.com on 26 Apr 2007 at 2:29
Original issue reported on code.google.com by
peter.mc...@gmail.comon 26 Apr 2007 at 2:29