Path: utzoo!attcan!uunet!zephyr.ens.tek.com!uw-beaver!milton!dali.cs.montana.edu!uakari.primate.wisc.edu!zaphod.mps.ohio-state.edu!ncar!ames!vsi1!daver!kcdev!gentry
From: gentry@kcdev.UUCP (Art Gentry)
Newsgroups: comp.sys.hp
Subject: Re: Dial in and Dial out on the one line
Keywords: Modem,Dial
Message-ID: <1158@kcdev.UUCP>
Date: 19 Sep 90 20:12:36 GMT
References: <1990Sep18.164732.4941@bhpcpd.kembla.oz.au>
Reply-To: gentry@kcdev. (Art Gentry)
Followup-To: comp.sys.hp
Organization: Gentry & Associates
Lines: 46

In article <1990Sep18.164732.4941@bhpcpd.kembla.oz.au> bernd@bhpcpd.kembla.oz.au (Bernd Wechner) writes:
>I'm having a little trouble configuring a modem line to allow both dial
>in and dial out. Dial out is fine if no getty is running and dial in is
>fine while the getty is running. This is our second modem and the
>inittab entry is copied directly from our first. Our first modem runs
>fine for both dial in and dial out.
>
>There is a subtle difference in the getty processes which look like:
>
>>     UID   PID  PPID  C   STIME TTY  TIME COMMAND
>>    root  4887     1  0 16:41:55 b5  0:01 /etc/getty -t 300 ttyb5 m24
>>    root  4868     1  0 16:28:53  ?  0:01 /etc/getty -t 300 tty03 m24
>
>The old modem getty has no tty while the new one keeps ttyb5 open (which
>I suspect is the problem).
>
>The inittab entries for these modems are:
>
>>t8:2:respawn:/etc/getty -t 300 tty03 m24
>>m6:2:respawn:/etc/getty -t 300 ttyb5 m24
>
> [ other unrelevent info deleted ]
>

Two things to fix your problem, one definite, the other depends on how the
500 hardware works (don't know if it's the same as the 800 series).

1) change your inittab entry to read /usr/lib/uucp/uugetty instead of
   /etc/getty.  The reason for this is, getty doesn't understand to
   "turn itself off" during an outgoing connect attempt.  uugetty
   does understand to go to sleep during outcalls.

2) you probably need to create a second device entry for the outgoing
   device.  On the 800 series there is a bit that needs to be set in
   order for the mux driver to behave appropriately.  Both the normal
   incoming dev entry and the outgoing dev entry point to the same
   physical device, but the correct one is called upon depending on
   the direction of the call.

   In my installations, I call the incoming /dev/tty0p1 and the outgoing
   /dev/ttyd0p1.  Both point to mux #0, port #1.

| R. Arthur Gentry   Gentry and Associates  Excelsior Spring, MO   64024 |
| Email: gentry@genco.uucp          ATTMail: attmail!kc4rtm!gentry       |
| The UNIX BBS: 816-221-0475        The Bedroom BBS: 816-637-4183        |
| $include {std_disclaimer.h}       "I will make a guess" - Spock - STIV |