Bug 44950 - vgetty won't answer in voice mode Rockwell
vgetty won't answer in voice mode Rockwell
Status: CLOSED CURRENTRELEASE
Product: Red Hat Linux
Classification: Retired
Component: mgetty (Show other bugs)
6.2
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Jason Vas Dias
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2001-06-18 22:33 EDT by Ken
Modified: 2007-04-18 12:33 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2005-07-20 12:19:36 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
vgetty log file (21.31 KB, text/plain)
2001-06-18 22:43 EDT, Ken
no flags Details

  None (edit)
Description Ken 2001-06-18 22:33:33 EDT
From Bugzilla Helper:
User-Agent: Mozilla/4.72 [en] (X11; U; Linux 2.2.14-5.0 i686)

Description of problem:
With a Rockwell modem:

when vgetty sends
AT#CLS=8

Rockwell responds with:

OK
<DLE><h>

the <DLE><h> is standard according to Rockwell chipset modem manuals.

eventually the <DLE><h> causes vgetty to "leave voice mode"
and issue AT#CLS=0

thus, vgetty never can answer the telephone in voice mode

How reproducible:
Always

Steps to Reproduce:
1. every time vgetty starts up or respawns
2.
3.
	

Actual Results:  see above

Expected Results:  Expected that <DLE><h> would be ignored as normal status
report from modem after switching into voice mode. (per Rockwell chipset
manual).

Additional info:
Comment 1 Ken 2001-06-18 22:43:11 EDT
Created attachment 21286 [details]
vgetty log file
Comment 2 Jason Vas Dias 2005-07-20 12:19:36 EDT
Sorry for the long delay in processing this bug report - it slipped through
the cracks somehow.
Modern mgetty (eg 1.1.33) now handles the <DLE><h> sequence correctly.

Note You need to log in before you can comment on or make changes to this bug.