force-init-chat for ELSA 56 K

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

Hi,

On Thu, Apr 08, 1999 at 04:14:43PM +0000, Peter Poh wrote:
> I'm running "mgetty: experimental test release 1.1.19-Nov24" on a FreeBSD 3.1
> machine (modem is a ELSA Microlink 56 K). When building and configuring the
> package from the FreeBSD-Port, the installation script didn't give me any
> hints how to define the "force-init-chat"-String, so I assume it is left
> empty in the current configuration. 

It's set to some dark magic that brings back to life a fair number of
modems (it's a combination of +++ATZ and some DLE codes to get a modem 
back from voice playback mode).

Look in "conf_mg.c" for the exact definition.

[..]
> Now to my problem: Due to security considerations I switch off the modem 
> twice a day (via a time-switch) for one minute some time after the dialout
> connection to my UUCP-provider.
> Problems occur when mgetty tries to talk to the modem during this period
> (e.g. to find out if it's still alive). 

Well, mgetty will complain, restart, and succeed.  Sometimes it might take
two or three attempts (if the modem is off for a full minute), but
eventually things should recover.

> From mgetty's log
> 
> *----------------------------------------------------------------------------
> 04/07 04:30:10 aa1  WARNING: DSR is off - modem turned off or bad cable?
> 04/07 04:30:10 aa1  lowering DTR to reset Modem
> 04/07 04:30:10 aa1   tss: set speed to 115200 (341000)
> 04/07 04:30:10 aa1   tio_set_flow_control( HARD )
> 04/07 04:30:10 aa1   waiting for line to clear (VTIME), read: [ff]
> 04/07 04:30:10 aa1  send: ATS0=0Q0&D3&C1[0d]
> 04/07 04:30:10 aa1  waiting for ``OK''
> 04/07 04:30:10 aa1   got:
> 04/07 04:30:30 aa1  timeout in chat script, waiting for `OK'
> 04/07 04:30:30 aa1  init chat timed out, trying force-init-chat
> 04/07 04:30:30 aa1  send: \d[10][03]\d\d\d+++\d\d\d[0d]\dATQ0V1H0[0d]
> 04/07 04:30:34 aa1  waiting for ``OK''
> 04/07 04:30:34 aa1   got:
> 04/07 04:30:54 aa1  timeout in chat script, waiting for `OK'
> 04/07 04:30:54 aa1  init chat failed, exiting...: Interrupted system call
> 04/07 04:30:54 ##### failed in mg_init_data, dev=cuaa1, pid=40745
> 04/07 04:30:54 aa1   removing lock file

Well, yes - this is expected behaviour.  Mgetty will complain, restart,
and try again.

> *--
> 04/07 04:30:55 aa1  mgetty: experimental test release 1.1.19-Nov24
> 04/07 04:30:55 aa1   mgetty.c compiled at Mar  3 1999, 22:59:29
> *----------------------------------------------------------------------------

... or does that mean "total hang at this point"?  Now that would be
pretty bad (and hint at a problem in the serial driver, blocking in the
open() call even if explicitely told not to do so).

> The consequences of this "one minute switch off" are severe: No dialins
> are successful afterwards (e.g. the two modems achieve no CONNECT) and even 
> the following dialout call (from uucico) leads to a "timed out in chat script"
> error (which is 
>   chat    "" ATZ OK \dATV1E0Q0L0 OK \dATDT\D CONNECT
> for the uucico-command).

Looks like the serial driver locks up, or maybe things get stuck in "flow
control off mode" (driver assuming that CTS is low, and it must not send
any further data to the modem.

Can you reproduce the effect by switching the modem off and back on
manually? If no, it's pretty hard to start debugging this - if yes, you
might look at the output of "ltest" (in mgetty/tools) on the serial port
when it's stuck, and see whether it looks unusual, e.g. no CTS.  Or try
setting FLOW_DATA FLOW_NONE - just for testing - , and see what happens.

gert

-- 
USENET is *not* the non-clickable part of WWW!
                                                           //www.muc.de/~gert/
Gert Doering - Munich, Germany                             gert@greenie.muc.de
fax: +49-89-35655025                        gert.doering@physik.tu-muenchen.de