Submission for Unix-PC

[Bill Carpenter]

On 8 Dec 89 00:39:38 GMT, gatelist at zorch.SF-Bay.ORG said:

gatelist> In order for me to be able to use this, I need a program
gatelist> that is somewhat like cu, but instead of placing a call, it
gatelist> waits around for an incoming call.  I guess it also need to

I ran into dialback modems a while back.  Below is what I did.  This
was using HDB "cu".  I have never tried it with stock "cu".  If anyone
does, perhaps they could post the result, good or bad.
--
   Bill Carpenter         att!ho5cad!wjc  or  attmail!bill
================================================================
Date: Fri, 5 Feb 88 09:18 EST
From: wjc
>From wjc  Fri Feb  5 09:18:56 1988
To: ...
Subject: answering calls with "cu"

A couple months ago, we were jointly wondering how we could answer an
incoming data call on the UnixPC and end up in terminal emulation.  We
discussed this in the context of using the "ct" utility from another
Unix host (we're apparently still waiting for the new secure version
of "ct" to be issued).

Well, here's good news.  At OCW, they don't use a modem password;
instead, they use a dialback modem.  That is, you call in, type your
security ID, it hangs up and calls you back on a pre-programmed phone
number.  That means that I had to attack with fervor the problem of
answering an incoming call for terminal emulation.

This method works for the UnixPC with the latest HDB uucp and cu from
The Store!  It seems like it would probably work with other uucp
versions and other types of machines that have modems directly
connected to them, but I'm conjecturing a little.

A.  File stuff.  Make an entry like this in your uucp Systems file:

	hullo Any hullo Any -

There is nothing magic about the token "hullo".  You just need
something that isn't otherwise special or built-in for uucp.

Make an entry like this in your uucp Devices file:

	hullo ph1,M - Any direct

Again, nothing special about "hullo" except that it must match the
token in the Systems file.  The token "direct" is special to uucp.
The entry "ph1,M" identifies the Unix device, so you could use "ph0"
or "tty000" (if you had an external modem on /dev/tty000), etc.  The
",M" is an undocumented item used by the dialing routines.  It means
the port has modem control.  When uucp or cu opens the device, the
open() call won't return until it sees Carrier Detect or some similar
modem magic.

B.  Command stuff.  Imagine that your phone is just about to ring with
that incoming data call.  You can answer it by using:

	getoff.sh ph1    # kills the uugetty on the line
	cu hullo         # will tell you it's "connected" right away
	<your terminal session here>
	geton.sh ph1     # optional, restores the uugetty

If you do the "cu" while the phone is ringing, it will be answered as
soon as "cu" kicks in.  If you "cu" before it rings, then it will be
answered quickly (first ring).  In either case, bang a few CR's or
whatever, since you're connected to the line and it might need
autobauding on the other end.

When you exit "cu", the connection won't be broken right away.  It
takes 30 seconds or so.  This is due to the normal mechanisms in the
phone, but we don't normally see it with "cu" since we normally
inititate the call.  What you get is a race condition between the
phone network disconnecting you and Datakit (or whatever) timing out
and hanging up.  I guess it doesn't matter much.

NOTES:

I'm not completely sure how some of this works, so there are possibly
some better combinations of things to do, especially with the uucp
file entries.

I also tried doing this via the Office phone stuff.  It claims that if
you don't use a phone number, it will spawn async_main in what looks
like an answer mode.  Alas, you can't get past the error message that
it gives you about the missing phone number, so I guess we'll never
know.

Yes, I did find out about the ",M" by reading the uucp source code.  I
guess you could consider that a form of documentation.

	Bill Carpenter
	(AT&T gateways)!ho5cad!wjc