mgetty/vgetty problems + solutions.

• Messages sorted by:[ date ][ thread ][ subject ][ author ]

Hi,

On Wed, 22 Sep 1999 20:31:24 +0200, Gert Doering wrote:

>On Tue, Sep 21, 1999 at 05:33:03PM -0700, xy3@email.com wrote:
>> Solution:
>> 
>> Edit ring.c and change the NMBR to NAME  (I'm sure there is a better 
solution 
>> that would work for all modems, but I just wanted mine to work at this time) 
>> like so:
>
>Just increase "rings" by one (in mgetty.config) - this isn't really a
>bug, it's a workaround for a problem with caller ID reporting on ISDN
>modems, which kind of backfired.
>
>Mgetty is a lot more robust concerning unexpected modem responses than
>vgetty, which is in the end what leads to the problem you're observing.
>
>(As for the rest of your question: when I find time to answer it)

I guess I'd like a way to have complete callerID information returned without 
having to set rings above 2 and without it confusing vgetty.

I've been watching the return codes of my callerID and noticed the following:

Some numbers have the full  DATE,TIME,NMBR,NAME fields filled in.  But some 
have DATE,TIME,NMBR=O,MESG=08014F    (no NAME field.. this is an Unknown caller 
of some sort (privacy enabled? out of area? some other reason?)) so I think it 
all must be accounted for and logged.  

Currently the MESG isn't logged (after reading the rockwell docs I believe 
there can be 2 MESG entries, but I've no idea what they are for) but I think 
both should be sent to cnd-program.  

My previous change of NMBR to NAME in ring.c wouldn't work in the above CID 
w/MESG situation and I don't want to increase rings to 3 (it seems like 
cheating .. and too many rings).  There must be a reliable way for it to work 
with all modems, but for now I'll just watch the CID return strings and see if 
I can't get it working for mine.

- john