mgetty interfering with diald

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

Hi,

Herbert Betz wrote:
> One of the first sentences in the mgetty-Manual states:
> mgetty handles incoming calls without interfering with outgoing calls.

Yep.

> This is not true on my maschine:

It is, if you set it up correctly.

> when the following is started with inittab:
> mo:23:respawn:/usr/sbin/mgetty /dev/modem

Use of /dev/modem is discouraged.

> ... I cannot get DIALD to work. In /var/log/messages I read the following:
> -----------------------------------------------------------------------
> Jul 10 15:32:25 Herb1 kernel: CSLIP: code copyright 1989 Regents of the
> University of California
> Jul 10 15:32:25 Herb1 kernel: SLIP: version 0.8.4-NET3.019-NEWTTY-MODULAR
> (dynamic channels, max=256) (6 bit encapsulation enabled).
> Jul 10 15:32:25 Herb1 kernel: AX25: KISS encapsulation enabled.
> Jul 10 15:32:25 Herb1 kernel: SLIP linefill/keepalive option.
> Jul 10 15:32:34 Herb1 diald[562]: Running connect (pid = 572).
> Jul 10 15:32:34 Herb1 chat[572]: send (ATZ^M)
> Jul 10 15:32:34 Herb1 chat[572]: expect (OK)
> Jul 10 15:33:19 Herb1 chat[572]: ATZ^M^\^@|^^^^^\^@
> Jul 10 15:33:19 Herb1 diald[562]: Connect script failed.
> Jul 10 15:33:19 Herb1 chat[572]: alarm
> Jul 10 15:33:19 Herb1 chat[572]: Failed
> Jul 10 15:33:20 Herb1 diald[562]: Delaying 30 seconds before clear to
> dial.
> Jul 10 15:33:29 Herb1 mgetty[573]: can't get user id for 'uucp': No such
> file or directory
> -------------------------------------------------------------------------
> 
> All programs lock to /var/lock and point to /dev/modem -> ttyS1 ...

They definitely don't, otherwise you'd see that in mgetty's log file, like
the following excerpt from /var/log/log_mg.tty4c while I do a "cu -l tty4c":

07/15 19:09:56 y4c  waiting...
07/15 19:55:43 y4c    poll returned 1
07/15 19:55:43 y4c   checking lockfiles, locking the line
07/15 19:55:43 y4c   makelock(tty4c) called
07/15 19:55:43 y4c   do_makelock: lock='/usr/spool/uucp/LCK..tty4c'
07/15 19:55:43 y4c  lock not made: lock file exists (pid=13883)
07/15 19:55:43 y4c   lock file exists (dialout)!
07/15 19:55:43 y4c   lockfile found, pid=13883
07/15 19:55:43 y4c    looking for utmp entry... (my PID: 11394)
07/15 19:55:43 y4c   utmp + wtmp entry made
07/15 19:55:43 y4c   lockfile found, pid=13883
07/15 19:55:53 y4c   lockfile found, pid=13883
07/15 19:56:03 y4c   lockfile found, pid=13883
07/15 19:56:13 y4c   lockfile found, pid=13883

If you mess up the locking, the mgetty debug log file will look more like
this (doing an "echo ATI >/dev/tty4c" without locking):

07/15 19:57:35 y4c  waiting...
07/15 19:58:01 y4c   checking lockfiles, locking the line
07/15 19:58:01 y4c   makelock(tty4c) called
07/15 19:58:01 y4c   do_makelock: lock='/usr/spool/uucp/LCK..tty4c'
07/15 19:58:01 y4c   lock made
07/15 19:58:01 y4c  wfr: waiting for ``RING''
07/15 19:58:01 y4c   got: [0a]ATI[0a]
07/15 19:58:01 y4c    CND: ATI
07/15 19:58:11 y4c  mdm_read_byte: read returned -1: Interrupted system call
07/15 19:58:11 y4c  wfr: timeout waiting for RING
07/15 19:58:11 y4c   wfr: rc=-1, drn=0
07/15 19:58:11 y4c  huh? Junk on the line?
07/15 19:58:11 y4c   removing lock file

so this is VERY clear from the mgetty log file whether the locks are set
correctly or not.  Just *look*.

> Substituting the inittab entry above with one of the following
> leads to further errors:
> 
> 1) mo:23:respawn:/usr/sbin/mgetty -x6 -s 38400 modem
> -> sendfax <anyphone> <any.g3> won't dial any more and seems blocked

Seems sendfax is misconfigured.  Look at the sendfax log file.

> 2) mo:23:respawn:/usr/sbin/mgetty -D -x2 -R 45 /dev/modem
> or mo:45:respawn:/usr/sbin/mgetty -D -x2 -R 45 /dev/modem
> -> will not answer the phone on the second or more rings.

Maybe mgetty is misconfigured?  Look at the mgetty log file to find out
what's happening.

Please don't go around telling people that things do not work, or are not
true, unless you provide all relevant data to prove that (chat logfiles
are nice but irrelevant, mgetty log files show all necessary data).

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