From rick Tue Mar 24 18:49:14 1992
Received: by rodan.UU.NET (5.61/UUNET-mail-drop)
	id AA29788; Tue, 24 Mar 92 18:49:13 -0500
Date: Tue, 24 Mar 92 18:49:13 -0500
From: rick (Rick Adams)
Message-Id: <9203242349.AA29788@rodan.UU.NET>
To: piers
Subject: uustatus -fyi
Status: OR


>From jh@moon.nbn.com Tue Mar 24 17:32:41 1992
Path: uunet!uunet!moon!jh
From: jh@moon.nbn.com (John Harkin)
Newsgroups: comp.mail.uucp
Subject: Re: .Status file codes for HDB uucp
Message-ID: <1992Mar24.223241.26725@moon.nbn.com>
Date: 24 Mar 92 22:32:41 GMT
References: <1992Mar23.165210.20780@asd.com>
Organization: North Bay Network, San Rafael, CA USA
Lines: 78

scott@asd.com (Scott Barman) writes:

>I know that the files in the .Status directory of the HoneyDanBer UUCP
>contain the status of the connection (and is used by uustat).  However,
>I would like to use it to diagnose problems in advance instead of
>waiting all weekend for a problem that happens Friday evening.

>where can I find a listing of these codes (I
>could not find them in the Sun manuals; I only found the words and them
>saying that it's from the .Status files).

>Please email to me since the time I read news is at a premium these days.

I emailed these to Scott, but since he replied that he had gotten 13
me-toos, I'll post them.  If anyone is interested in the program these
come from, I'll repost it to alt.sources.  It was originally posted in
January, 1989.

Uustatus is a great tool for keeping track of a busy uucp system.  I use
it constantly.  It uses curses to display a screen or window with a line
from each uucp connection.  Data includes the .Status info, plus files
in the queue.

Here is the header from uustatus.c.


/*
*
* uustatus - display UUCP communications status for HDB systems
*
* Written 01/19/89 by Ed Carp
*
* Copyright 1989, by Edwin R. Carp
*
*/

And here is the .sig from the README.


           Ed Carp	 N7EKG/5 (28.3-28.5)	erc@unisec.usi.com
           UniSecure Systems, Inc.;		OS/2, Just say No!
           Round Rock,  Tx; (home) (512) 834-2507
           UUCP:  erc@unisec
           Snail Mail:  2001A Pipersfield
                        Austin, Tx  78758

And finally, here is the info everyone wanted, from uustatus.h.


char *errortext[] =
{
  /* SS_OK			0 */ "SUCCESSFUL",
  /* SS_NO_DEVICE		1 */ "NO DEVICES AVAILABLE",
  /* SS_TIME_WRONG		2 */ "WRONG TIME TO CALL",
  /* SS_INPROGRESS		3 */ "TALKING",
  /* SS_CONVERSATION		4 */ "CONVERSATION FAILED",
  /* SS_SEQBAD			5 */ "BAD SEQUENCE CHECK",
  /* SS_LOGIN_FAILED		6 */ "LOGIN FAILED",
  /* SS_DIAL_FAILED		7 */ "DIAL FAILED",
  /* SS_BAD_LOG_MCH		8 */ "BAD LOGIN/MACHINE COMBINATION",
  /* SS_LOCKED_DEVICE		9 */ "DEVICE LOCKED",
  /* SS_ASSERT_ERROR		10 */ "ASSERT ERROR",
  /* SS_BADSYSTEM		11 */ "SYSTEM NOT IN Systems FILE",
  /* SS_CANT_ACCESS_DEVICE	12 */ "CAN'T ACCESS DEVICE",
  /* SS_DEVICE_FAILED		13 */ "DEVICE FAILED",
  /* SS_WRONG_MCH		14 */ "WRONG MACHINE NAME",
  /* SS_CALLBACK		15 */ "CALLBACK REQUIRED",
  /* SS_RLOCKED			16 */ "REMOTE HAS A LCK FILE FOR ME",
  /* SS_RUNKNOWN		17 */ "REMOTE DOES NOT KNOW ME",
  /* SS_RLOGIN			18 */ "REMOTE REJECT AFTER LOGIN",
  /* SS_UNKNOWN_RESPONSE	19 */ "REMOTE REJECT, UNKNOWN MESSAGE",
  /* SS_STARTUP			20 */ "STARTUP FAILED",
  /* SS_CHAT_FAILED		21 */ "CALLER SCRIPT FAILED",
  /*				22 */ "CALL IN PROGRESS",
};
-- 
John Harkin   +1 415 472-2452   moon!jh   uunet!nbn!jh   jh@nbn.com
North Bay Network - News and mail for Marin county and vicinity




From rick Mon Apr 20 15:11:21 1992
Received: by rodan.UU.NET (5.61/UUNET-mail-drop)
	id AA17465; Mon, 20 Apr 92 15:11:20 -0400
Date: Mon, 20 Apr 92 15:11:20 -0400
From: rick (Rick Adams)
Message-Id: <9204201911.AA17465@rodan.UU.NET>
To: piers
Subject: uucp g - FYI
Status: OR


>From jeh@cmkrnl.com Sat Apr 18 13:14:24 1992
Path: uunet!uunet!cs.utexas.edu!usc!sol.ctr.columbia.edu!spool.mu.edu!agate!dog.ee.lbl.gov!nosc!crash!cmkrnl!jeh
From: jeh@cmkrnl.com
Newsgroups: comp.mail.uucp
Subject: Re: Summary: UUCP: 64-byte packet -> 256-byte packet
Message-ID: <1992Apr18.101424.441@cmkrnl.com>
Date: 18 Apr 92 17:14:24 GMT
References: <1992Apr13.223206.406@arrocha.charlotte.nc.us> <202@mailmak.swb.de>
Organization: Kernel Mode Consulting, San Diego CA
Lines: 35

In article <202@mailmak.swb.de>, theo@mailmak.swb.de (Theo Janssen) writes:
> Well, this is not really a 'Re:' more an additional question.
> I've had a few problems with my remote concerning the packet/window
> sizes. My remote obviously has a fixed window/packet size of 1024/7.

Your remote is seriously broken if this is really true.  A system that "asks
for" 1024/7 (or any other combination) during the INITx sequence is
supposed to accept anything smaller when it's actually receiving packets.   

> So, transfer was always done with outgoing files sent with 1024/7, while
> incoming files were received using the standard 64/3. Although, outgoing
> files were sent, either my uucico or remote's uucico then couldn't manage
> to handle correct acknowledgement or CY for the sent file.
> After compiling and installing Taylor UUCP, the problem has been 'fixed',
> nevertheless i still don't know if it is correct to have different 
> input/output packet sizes. How I said, it works, but is it correct ?

It's supposed to work, that is, a correct uucp implementation will allow for
this.  It's allowed for in Greg Chesson's original paper on the 'g' protocol: 
There are two senders and two receivers, operating pretty much independently;
in the INITx packets, each receiver tells the sender at the other end the
maximum packet and window size that it can receive, and the sender is expected
to comply. 

There seem to be several incorrect implementations out there.  It appears to
me, from watching INITx exchanges with several older uucps, that some
implementors thought that the INITx sequence is a "negotiation" between the two
systems.  It isn't.  Each receiver simply tells the other end's sender "this is
the most I can handle, don't send me any more than that".  

	--- Jamie Hanrahan, Kernel Mode Consulting, San Diego CA
uucp 'g' protocol guru, VMSnet (DECUS uucp) Working Group, and
Chair, VMS Programming and Internals Working Group, U.S. DECUS VAX Systems SIG 
Internet:  jeh@cmkrnl.com, hanrahan@eisner.decus.org, or jeh@crash.cts.com
Uucp:  ...{crash,eisner,uunet}!cmkrnl!jeh



From rick Thu Nov 14 17:39:15 1991
Received: by rodan.UU.NET (5.61/UUNET-mail-drop)
	id AA24306; Thu, 14 Nov 91 17:39:14 -0500
Date: Thu, 14 Nov 91 17:39:14 -0500
From: rick (Rick Adams)
Message-Id: <9111142239.AA24306@rodan.UU.NET>
To: piers
Subject: control file ideas
Status: OR


>From gnu@cygnus.com Thu Dec 13 00:23:29 1990
Received: from cygint.cygnus.com by uunet.uu.net (5.61/1.14) with SMTP 
	id AA22770; Thu, 13 Dec 90 00:23:00 -0500
Received: from localhost by cygnus.com (4.0/SMI-4.0)
	id AA00710; Wed, 12 Dec 90 21:20:06 PST
Message-Id: <9012130520.AA00710@cygnus.com>
To: rick@uunet.uu.net
Cc: gnu@cygnus.com
Subject: uucp control file
Date: Wed, 12 Dec 90 21:20:06 -0800
From: gnu@cygnus.com
Status: R

You mentioned wanting to put a control file into uucp, replacing various
macros and ifdef's.  I have already done this for gnuucp, and thought
you might want to examine what I did.  A sample control file is enclosed
below, and I've pushed the entire gnuucp source (6 shar files) into
uunet:~ftp/tmp.  Each uucp program accepts a "-C control-file" argument,
defaulting to a name specified in the "system-dependent" routine sysdep.c.
No other pathnames are coded into the programs.

Feel free to take whatever parts of gnuucp you like.  Unfortunately, at
first glance it appears that you can't merge any of them with AT&T-
derived sources, since the resulting uucp would be both AT&T-licensed
and copylefted -- a contradiction in terms, so to speak.  However, it 
might be reasonable to take entire gnuucp programs, such as uux.
And you are of course free to take ideas.

If you know of anyone who would like to adopt gnuucp, I'd love to
have it be useful.  I'd put it in comp.sources.unix but I don't have
the time to even merge bugfixes and ports these days, and I don't
want it to spliter into seventeen different versions.

	John

# Our node's name
nodename	hoptoad

#		Where queued (pending) traffic is kept
spool		/var/spool/uucp
#		The human-readable log of all uucp activity
logfile		/var/spool/uucp/LOGFILE
#		The publicly available directory for copying things in or out
pubdir		/var/spool/uucppublic
#		The list of all systems we are in contact with
sysfile		/etc/uucp/L.sys
#		The list of permissions for users and systems to copy files
userfile	/etc/uucp/gnuucp.userfile
#		Where the next sequence number for queue files is kept.
seqfile		/etc/uucp/SEQF
#		Where the program that executes incoming jobs is kept
gnuuxqt		/usr/lib/uucp/uuxqt
#		Where the program that moves files over serial lines is kept
gnuuio		/usr/lib/uucp/uucico

# Definitions of the serial ports used by gnuuio.
# The fields are:  line type   (matches third field in L.sys file)
#			       (ACU = "auto call unit" = the old Unix default)
#		   dialer type (used by dialing code)
#			       (currently must be "hayes" or "none")
#		   device name (which physical device, e.g. cua0 or com1)
#		   baud rate   (1200, 2400, 19200, etc)
port		ACU hayes cua0 1200
port		ACU hayes cua0 2400
port		ACU hayes cua0 300

port		ACU hayes cua1 1200
port		ACU hayes cua1 2400
port		ACU hayes cua1 300

port		ACU hayes cua2 19200

port		ACU hayes cua3 19200

# Definitions of custom time specifications for the second field in L.sys.
# These define periods of time when it's OK to call out.  E.g. the one
# below defines Reach Out America hours.  It can then be used just like
# other words, e.g. "Sa", or "Night", in L.sys lines and other timetables.
timetable	Reachout	Any2200-0800,Sa,Su0000-1700




From rick Thu Nov 14 17:40:23 1991
Received: by rodan.UU.NET (5.61/UUNET-mail-drop)
	id AA24366; Thu, 14 Nov 91 17:40:23 -0500
Path: uunet!cs.utexas.edu!tut.cis.ohio-state.edu!rutgers!att!mtune!rkh
From: rkh@mtune.ATT.COM (Robert Halloran)
Newsgroups: comp.mail.uucp
Subject: Re: uucp protocol selection question.
Message-Id: <7980@mtune.ATT.COM>
Date: 20 Apr 89 13:36:41 GMT
References: <19135@adm.BRL.MIL> <505@lakart.UUCP>
Reply-To: mtune!rkh (Robert Halloran)
Organization: AT&T ISL Middletown NJ USA
Lines: 31
Sender: rick
Apparently-To: piers
Status: OR

In article <505@lakart.UUCP> dg@lakart.UUCP (David Goodenough) writes:
>kadmon!jason@mtxinu.com (Jason Venner) sez:
>> I would like my uucp to try for different protocols depending on what
>> io device the uucico is running on at the time.
>> 
>> Is there a way to specify the preferred protocol?

If you're running HoneyDanBer UUCP, you can specify either in the Systems
or Devices file what protocols are usable.

Devices:

ACU[,protocols] .....

Systems:

system Any[,protocols] ....

where the optional 'protocols' field says what the system will offer when
using that device or calling that system. 

						Bob Halloran
						Distributed Programming
						  Tools Group
=========================================================================
UUCP: {att, rutgers}!mtune!rkh			DDD: (201)957-6034
Internet:   rkh@mtune.ATT.COM			       
USPS: AT&T Bell Labs, 200 Laurel Ave Rm 3G-314 Middletown NJ 07748
Quote: If Basic is for backward children, and Pascal for naughty
  schoolboys, then C is the language for consenting adults - Brian Kernighan
=========================================================================



From rick Thu Nov 14 17:40:38 1991
Received: by rodan.UU.NET (5.61/UUNET-mail-drop)
	id AA24429; Thu, 14 Nov 91 17:40:37 -0500
Received: from okeeffe.Berkeley.EDU by uunet.UU.NET (5.61/1.14) with SMTP 
	id AA20485; Wed, 17 May 89 16:37:46 -0400
Received: by okeeffe.Berkeley.EDU (5.61/1.29)
	id AA10265; Wed, 17 May 89 20:37:59 GMT
Date: Wed, 17 May 89 20:37:59 GMT
From: bostic@okeeffe.Berkeley.EDU (Keith Bostic)
Message-Id: <8905172037.AA10265@okeeffe.Berkeley.EDU>
To: rick@uunet.UU.NET
Subject: Re: pathnames.h
Sender: rick
Status: OR

Sounds good to me; pathnames.h is *all* of the absolute pathnames
used by a program, with the exception of those listed in 
/usr/include/paths.h.  Paths are #ifdef'd as _PATH_WHATEVER.

I've done some of the stuff for pathnames.h in the uucp on okeeffe,
but I didn't hit uucp.h.

Also, speaking of cleanup -- would it be reasonable to:

	break uucp up into multiple directories, one per program
	plus a library directory?  On okeeffe I moved uucpd and
	uuencode/uudecode out of the uucp directory because I get
	a fair number of requests for them, and they're clearly AT&T
	free.  I believe I sent you mail when I did most of this --
	if you decide you don't like it that way, just move them
	back.

	move the old stuff (like mkdir, index, getwd, ioctl, strpbrk)
	out of the main source tree?

--keith


From rick Thu Nov 14 17:40:42 1991
Received: by rodan.UU.NET (5.61/UUNET-mail-drop)
	id AA24612; Thu, 14 Nov 91 17:40:41 -0500
Received: from okeeffe.Berkeley.EDU by uunet.UU.NET (5.61/1.14) with SMTP 
	id AA15484; Thu, 18 May 89 23:34:03 -0400
Received: by okeeffe.Berkeley.EDU (5.61/1.29)
	id AA00556; Fri, 19 May 89 03:34:16 GMT
Date: Fri, 19 May 89 03:34:16 GMT
From: bostic@okeeffe.Berkeley.EDU (Keith Bostic)
Message-Id: <8905190334.AA00556@okeeffe.Berkeley.EDU>
To: rick@uunet.UU.NET
Subject: uucp
Sender: rick
Status: OR


I was thinking -- perhaps the configuration files should go
in /etc/uucp.  The log files to /var/log.  The administration
utilities to /usr/sbin.  The user interfaces to /usr/bin.
The backend programs to /usr/libexec?

--keith


From rick Thu Nov 14 17:41:39 1991
Received: by rodan.UU.NET (5.61/UUNET-mail-drop)
	id AA24622; Thu, 14 Nov 91 17:41:38 -0500
Received: from vixie.sf.ca.us by uunet.uu.net (5.61/1.14) with SMTP 
	id AA26598; Wed, 2 May 90 13:15:21 -0400
Received: by vixie.sf.ca.us; id AA11495; Wed, 2 May 90 10:13:40 -0700
Message-Id: <9005021713.AA11495@vixie.sf.ca.us>
To: rick@uunet.UU.NET (Rick Adams)
Cc: myself at work <vixie@jove.pa.dec.com>
Subject: Re: new uucp? 
In-Reply-To: Your message of Wed, 02 May 90 11:18:33 -0400.
             <9005021518.AA02912@uunet.uu.net> 
Date: Wed, 02 May 90 10:13:38 PDT
From: Paul A Vixie <vixie@vixie.sf.ca.us>
Sender: rick
Status: OR

Using unix domain sockets to pass fd's back and forth is a better idea,
I admit.  Just as long as there's a utility whose source code contains
nothing of AT&T which can be hacked to do connection support.  We don't
add to the rest of uucico very often; I expect that lots of binary-only
sites would be able to hack everything they wanted on uucp if the dialer
part of it were in a different utility.

A logical extension of this is to move the connection-part completely
out of uucico, such that uucico would search L-devices, create a list
of lines and their dialers that matched the current L.sys's connection
type and baud rate and so on; then it would fork off the dialer.

L.sys... (needs to support distinct ACU types per baud rate)
old:	uunet Any ACU 19200 4155551212 ogin:--ogin: Udecwrl word: foobar
	(ACU is sometimes WATS, which currently does but should not need
	a hack to uucico source code, per ACU-type)
	(19200 is ambiguous, since sometimes it's PEP and sometimes it's
	V.42 and sometimes it's HST; also, we've got at least one neighbor
	which we can call at PEP-9600 but not PEP-19200)
	(both of these values should be enumerated in config files, not
	in a compiled-in source-code-level table)
new:	uunet Any ACU PEP-FAST 415...
	uunet Any WATS V42 415...

L-devices... (needs to stop caring so much about baud rates and such)
old:	ACU tty00 tty00 19200 vhayestone "" ATs7=90s58=2s50=255 OK~5
	(ACU is now defined by this file, not treated specially in uucico)
	(I guess we need to maintain the ACUdev-vs-dev split)
	(Baud rate is now a token, defined here as is ACU)
	(acutype is now the name of a program, default path for which
	is settable by PATH= as in L.cmds)
	(What we need is a radical change, since I'd like to hand the
	"dialer" program a list of devices and let it pick any one of
	them; this is best done as a single entry listing multiple
	devices since otherwise we end up with N>1 chat scripts and
	we don't know which one to use).
	(I'd like to be able to specify TCP UUCP in this file, so that
	this type of connection was also set up by an outboard program,
	leaving uucico with just some open file descriptors.  this makes
	it hard to allow for lists of devices since TCP UUCP won't have
	them.)
new:	ACU PEP-FAST * tty00,tty01,tty02,tty03 tb-dialer 19200 s7=90s58=2
	(* = "ACU is always the same as the device"; if you list a specific
	ACU than all devices in the list have to be dialable by it)
	(device list is handed to dialer as a single argv[n] with commas)
	(tb-dialer is the name of a program)
	(19200 and s7=90s58=2 are dialer-specific parameters, different
	for each dialer program)
	(there's no chat script.  i'll explain why in a minute.)
	TCP UUCP * * tcp-dialer
	(* * = placeholders)

This file needs some more notes.  First, we'd supply a generic dialer that
had a big case statement in it for the common types like DIR and ACU HAYES
and maybe TCP UUCP.  The source for this would be ATT-free, so it could be
used as a prototype by binary-only sites.

Second, the lack of a chat script.  It's a fact that a lot of devices need
special chats done on them before the dialer code will actually be facing
a dialer -- telebits hanging off of ethernet terminal servers are a great
example.  But rather than chat scripts, I'd like to be able to cascade the
dialers.  At Ungermann-Bass, for example, I had some telebits hanging off
a terminal server but I ended up reaching that terminal server via a 
terminal server that was connected to a serial port on the VAX.  So even
though the VAX had an ethernet port and XNS-capable sockets (needed to 
reach the remote terminal server), I had to use serial ports.  Bad news.

If I could have told UUCICO to "use this dialer, then use that dialer"
then I would have hacked up an XNS connectifier and let it set up a
connection to the remote, then let the standard telebit dialer do the
rest.

I'm having trouble thinking up a syntax for this, but I know it's something
I want.  And more important, it's something HDB does not have :-) :-)..

Comments?


From rick Thu Nov 14 17:42:39 1991
Received: by rodan.UU.NET (5.61/UUNET-mail-drop)
	id AA24663; Thu, 14 Nov 91 17:42:38 -0500
Received: from batch.UU.NET by uunet.UU.NET with SMTP 
	(5.61/UUNET-uucp-primary) id AA19701; Mon, 19 Aug 91 15:48:03 -0400
Received: by batch.UU.NET (5.61/UUNET-internet-secondary)
	id AA02135; Mon, 19 Aug 91 15:47:54 -0400
From: asp
Message-Id: <9108191947.AA02135@batch.UU.NET>
Subject: Configuration files for new UUCP package (long) (fwd)
To: rick (Rick Adams)
Date: Mon, 19 Aug 91 15:47:54 EDT
X-Mailer: ELM [version 2.3 PL10]
Sender: rick
Status: OR

Don't know if you had seen this message in comp.mail.uucp nor if you
knew of this guy.
	--asp

Forwarded message:
>From ian@airs.com Mon Aug 19 00:34:11 1991
Path: uunet!uunet!airs!ian
From: ian@airs.com (Ian Lance Taylor)
Newsgroups: comp.mail.uucp
Subject: Configuration files for new UUCP package (long)
Message-ID: <2399@airs.com>
Date: 19 Aug 91 04:34:11 GMT
Sender: news@airs.com
Lines: 770

I am nearing completion of a new UUCP package, which I hope to release
for beta test in a week or two (I'll solicit beta testers when I'm
ready; no need to volunteer now).  The package will be released under
the GNU Public License.

In the meantime, I am looking for some feedback on the system of
configuration files that I am using.  I don't find either the
traditional L.sys L-devices L.cmds or the HDB Systems Dialers
Permissions configuration files particularly easy to understand or
sufficiently flexible to specify everything that is useful for a UUCP
system; they are good, but I arrogantly think I can do better.  I
therefore set up my own system.  I hope to write AWK scripts to
convert the traditional styles into my style.

The rest of this post describes the configuration files that I have
implemented.  My goal here, as for anybody who designs configuration
files, is to allow a simple setup to be implemented simply while also
allowing a complex setup to be handled completely.  I welcome any
comments.  I intend to keep a list of people who have made helpful
suggestions or contributions; if you prefer to be anonymous, please
let me know.

*** The configuration files

All the configuration files follow a simple line-oriented keyword
value format.  The first word on each line is a keyword of some sort
(empty lines are ignored).  The rest of the line is interpreted
according to the keyword.  Most keywords are followed by numbers,
boolean values or simple strings (with no embedded spaces).  The '#'
character is used for comments, and everything from a '#' to the end
of the line is ignored.  Everything after the keyword must be on the
same line.  A BOOLEAN may be specified as 'y', 'n', 'Y', 'N', 't',
'f', 'T', or 'F'.

*** The main configuration file

The main configuration file may be specified by the -I option to
uucico.  The default file location is set in the system dependent
header file (sysdep.h).  As all the values that may be specified in it
also have defaults, there need not be a main configuration file at
all.

nodename STRING
hostname STRING
uuname STRING

These keywords are identical.  They specify the UUCP name of the local
host.  If there is no configuration file, an appropriate function will
be used to get the host name, if possible.

spool STRING

Specify the spool directory.  The default is from sysdep.h.  Command
files, work files, temporary files, log files, etc., are stored in
this directory and in subdirectories of it.

sysfile STRING

Specify the system file.  The default is from sysdep.h.  This file
holds information about other systems with which this system
communicates, and is described further below.

portfile STRING

Specify the port file.  The default is from sysdep.h.  This file
describes ports which are used to call other systems and accept calls
from other systems.  It is described further below.  It is optional.

dialfile STRING

Specify the dial file.  The default is from sysdep.h.  This file
describes dialing devices (modems).  It is described further below.
It is optional.

dialcodefile STRING

Specify the dialcode file.  The default is from sysdep.h.  This file
specifies dialcodes that may be used when sending phone numbers to a
modem.  This permits using the same set of phone numbers in different
area-codes and phone systems, by using dialcodes to specify the
calling sequence.  When a phone number goes through dialcode
translation, the leading alphabetic characters are stripped off.  The
dialcode file is read line by line, just like any other configuration
file, and when a line is found whose first word is the same as the
leading characters from the phone number, the second word on the line
(which would normally consist of numbers) replaces the dialcode in the
phone number.  This file is optional.

pubdir STRING

Specify the public directory.  The default is from sysdep.h.  On Unix,
when a file is named using a leading ~/, it is taken from or to the
public directory.

callfile STRING

Specify the call out login name and password file.  The default is
from sysdep.h.  If the call out login name or password for a system
are given as "*" (see the description of the system configuration
file, below), this file is read to get the real login name or
password.  Each line in the file has three words: the system name, the
login name, and the password.  The intention is to permit the system
file to be publically readable; this file must obviously be kept
secure.  This file is optional.

passwdfile STRING

Specify the password to use for login names when uucico is doing its
own login prompting.  The default is from sysdep.h.  Each line in the
file has two words: the login name and the password.  This file is
optional, although it must exist if uucico is to present its own login
prompts.

logfile STRING

Name the log file.  The default is from sysdep.h.  Logging information
is written to this file.

statfile STRING

Name the statistics file.  The default is from sysdep.h.  Statistical
information about file transfers is written to this file.

debug NUMBER

Set the debugging level.  The default is 0.  Numbers between 0 and 9
are relevant; the larger the number, the more debugging information is
output.  This may be overridden by the -x switch to uucico.

unknown STRING ...

The STRING and subsequent arguments are treated as though they
appeared in the system file (see below for a full description).  They
are used to apply to any unknown systems that may call in, probably to
set file transfer permissions and the like.  If the ``unknown''
command is not used, unknown systems are not permitted to call.

*** The system configuration file

This file describes all remote systems known to the UUCP package.  The
first set of commands in the file, up to the first ``system'' command,
specify defaults to be used for all systems.  Subsequently, each set
of commands from the first ``system'' up to the next ``system''
command describe a particular system (default values may be overridden
for specific systems).  There is then another level of defaults, in
that the first set of commands for a particular system, up to the
first ``alternate'' command, specify defaults.  Subsequently, each set
of commands from ``alternate'' up to the next ``alternate'' command
describe an alternate means of calling out or calling in.  When a
system is called, the command before the first ``alternate'' are used
to select a phone number, port and so forth; if the call fails for
some reason, the commands between the first ``alternate'' and the
second are used, and so forth.  When a call is received the various
alternates are checked to permit the login name to specify different
permissions (this will only be done if the first set of commands,
before the first ``alternate'' command, use the ``called-login''
command).

system STRING

Specify the remote system name.  Subsequent commands up to the next
``system'' command refer to this system.

alternate

Start an alternate set of commands, as described above.

alias STRING

Specify an alias for the current system.  The alias may be used by
local uucp and uux commands.  This will also be used when a system
calls in, so that the name used when spooling commands from a system
may be different from the one the system claims for itself.  The
default is to have no aliases.

time STRING

Specify when the system may be called.  Each time specification must
begin with a list containing ``Su'', ``Mo'', ``Tu'', ``We'', ``Th'',
``Fr'', ``Sa'' or ``Wk'' for any weekday or ``Any'' for any day.
Following the day may be a range of hours separated with a hyphen
using 24 hour time.  The range of hours may cross 0; for example
2300-0700 means any time except 7 AM to 11 PM.  If no time is given,
calls may be made at any time on the specified day(s).  Multiple time
specifications may be separated with a vertical bar (|) or a comma
(,).

The time specification may also consist of the single word Never,
which means to never call the system (although the system may be able
to call in) or a single word with a name defined in a previous
timetable (q.v.) command.

The ``time'' command may appear multiple times in a single alternate.
The default value is ``Never''.

timegrade CHARACTER STRING

The CHARACTER is a single character A to Z, a to z, or 0 to 9 and
specifies a grade.  The STRING is a time string as described in the
``time'' command.  All jobs of grade CHARACTER or higher (0 > 9 > A >
Z > a > z) may be run at the specified time.  An ordinary ``time''
command is equivalent to using ``timegrade'' with a grade of z.  If
there are no jobs of a sufficiently high grade according to the time
string, the system will not be called.  Using the -s switch to uucico
to force it to call a system causes it to assume there is a job of
grade 0 waiting to be run.

Note that the ``timegrade'' command serves two purposes: 1) if there
is no job of sufficiently high grade the system will not be called 2)
if the system is called anyway (because the -s switch was given to
uucico) only jobs of sufficiently high grade will be transferred.
However, if the other system calls in, the ``timegrade'' commands are
ignored, and jobs of any grade may be transferred.  Also, the
``timegrade'' command will not prevent the other system from executing
any job it chooses, regardless of who placed the call.

The ``timegrade'' command may appear multiple times without using
``alternate''.  If this command does not appear, there are no
restrictions on what grade of work may be done at what time.

call-timegrade CHARACTER STRING

The CHARACTER is a single character A to Z, a to z, or 0 to 9 and
specifies a grade.  The STRING is a time string as described in the
``time'' command.  If a call is placed to the other system during a
time which matches the time string, the remote system will be
requested to only run jobs of grade CHARACTER or higher.
Unfortunately, there is no way to guarantee that the other system will
obey the request (this UUCP package will, but there are other which
will not); moreover historically job grades are somewhat arbitrary so
specifying a grade will only be meaningful if the other system
cooperates in assigning grades.  This grade restriction only applies
when the other system is called, not when the other system calls in.

The ``call-timegrade'' command may be appear multiple times without
using ``alternate''.  If this command does not appear, the remote
system will be allowed to send whatever grades of work it chooses.

call-local-size NUMBER STRING

The STRING is a time string as described under the ``time'' command.
The NUMBER is the size in bytes of the largest file that should be
transferred at a time matching the time string if the local system
placed the call and the request was made by the local system.  The
size of a file requested from the remote system (as opposed to a file
sent to the remote system) will only be checked if the other system is
running this package (older UUCP code can not handle a maximum size
request).  This command may appear multiple times in a single
alternate.  If this command does not appear, there are no size
restrictions.

call-remote-size NUMBER STRING

Specify the size in bytes of the largest file that should be
transferred at a given time by remote request when the local system
placed the call.  This command may appear multiple times in a single
alternate.  If this command does not appear, there are no size
restrictions.

called-local-size NUMBER STRING

Specify the size in bytes of the largest file that should be
transferred at a given time by local request when the remote system
placed the call.  This command may appear multiple times in a single
alternate. If this command does not appear, there are no size
restrictions.

called-remote-size NUMBER STRING

Specify the size in bytes of the largest file that should be
transferred at a given time by remote request when the remote system
placed the call.  This command may appear multiple times in a single
alternate. If this command does not appear, there are no size
restrictions.

timetable STRING STRING

This is actually not specific to a system.  It can appear anywhere in
the file, and defines a timetable that may be used in subsequently
appearing time commands.  The first string names the timetable entry;
the second is a time string as described in the ``time'' command.

The following timetable commands are predefined (note that the NonPeak
timetable is for compatibility, and no longer has any particular
meaning):

	timetable Evening Wk1705-0755,Sa,Su
	timetable Night Wk2305-0755,Sa,Su2305-1655
	timetable NonPeak Wk1805-0655,Sa,Su

If this command does not appear, then obviously no additional
timetables will be defined.

[ The timetable command doesn't really belong here; perhaps it should
be in the general configuration file? ]

baud NUMBER

Specify the baud rate to use when calling the system.  This will try
all available ports with that baud rate until an unlocked port is
found.  The ports are defined in the port file.  If both the baud and
the port commands appear, the baud rate is used to open the port at a
specified baud.  To allow calls at more than one baud rate, the
``alternate'' command must be used.  If this command does not appear,
there is no default; the baud rate may be specified in the port file,
but if it is not the natural baud rate of the port will be used
(whatever that means on the system).

port STRING

Name a particular port to use when calling the system.  The
information for this port is obtained from the port file.  If this
command does not appear, there is no default; a port must somehow be
specified in order to call out (it may be specified implicitly using
the ``baud'' command or explicitly using the next version of
``port'').

port STRING ...

If more than one string follows the ``port'' command, the subsequent
strings are treated as commands that might appear in the port file
(see the description of the port file, below).  If a port is named (by
using a single string following ``port'') these commands are ignored;
their purpose is to permit specifying the port directly in simple
cases without having to make entries in two different files.  In order
to call out, a port must be specified using some version of the
``port'' command, or by using the ``baud'' command to select ports
from the port file.

phone STRING

Give a phone number to call.  A '=' character in the phone number
means to wait for a secondary dial tone (although only some modems
support this); a '-' character means to pause while dialing for 1
second (again, only some modems support this).  The ``phone'' command
is ignored for a non-modem port.  To use more than one phone number
the ``alternate'' command must be used.  This command must appear in
order to call out on a modem; there is no default.

chat STRINGS

Specify the chat script to use when calling the system.  The chat
script is a series of expect/send pairs.  The first expect may be "",
meaning to begin by sending.  The pairs are separated by blank space;
to include blank space in the string, an escape sequence must be used.
An expect string may include subsend and subexpect strings separated
by hyphens; if the expect string is not seen, the subsend string will
be sent and the next subexpect string will be searched for.  To
include a hyphen in an expect string, an escape sequence must be used.
A carriage return ('\r') is sent after each send string, unless \c
appears at the end.  A sample chat script appears below.  The
following escape sequences are defined in chat scripts:

	"" -- expect a null string (i.e. skip the expect phase)
	EOT -- send an end of transmission character (^D)
	BREAK -- send a break character (may not work on all systems)
	\b -- a backspace character ('\b')
	\c -- suppress trailing carriage return at end of send string
	\d -- delay sending for 1 second
	\K -- same as BREAK (for BNU compatibility)
	\n -- a newline character ('\n')
	\N -- a null character (for BNU compatibility)
	\p -- pause sending for a fraction of a second
	\r -- a carriage return character ('\r')
	\s -- a space character (' ')
	\t -- a tab character ('\t')
	\\ -- a slash character ('\\')
	\DDD -- character DDD, where DDD are up to three octal digits
	\xDDD -- character DDD, where DDD are hexadecimal digits.
	\L -- send the login name
	\P -- send the password

As in C, there may be up to three octal digits following a slash, but
the hexadecimal escape sequence continues as far as possible.  To
follow a hexadecimal escape sequence with a hex digit, use "" as the
next expect or send string (e.g. \x0d "" dave).

Note that in some versions of UUCP, \b denotes a break character.

The default chat script is:

	"" \r\c ogin:-BREAK-ogin:-BREAK-ogin: \L word: \P

Note that carriage return characters are sent after the break
characters, and after the login name and the password.

chat-timeout NUMBER

The number of seconds to wait for an expect string in the chat script
before timing out and sending the next subsend or failing the chat
script entirely.  The default value is 60.

call-login STRING

Specify the login name to send with \L in the chat script.  If the
string is "*" (e.g. ``call-login *'') the login name will be fetched
from the call out login name and password file.  There is no default.

call-password STRING

Specify the password to send with \P in the chat script.  If the
string is "*" (e.g. ``call-password *'') the password will be fetched
from the call-out login name and password file.  There is no default.

called-login STRING

Specify the login name that the system must use when calling in.  If
STRING is "ANY" (e.g. ``called-login ANY'') any login name may be used
(this is only useful to override a default specified in this file).
The case of STRING is significant.  The default value is "ANY".
Different alternates may use different ``called-login'' commands, in
which case the login name will be used to select which alternate is in
effect; this will only work if the first alternate (before the first
``alternate'' command) uses the ``called-login'' command.

callback BOOLEAN

If BOOLEAN is true, then when the remote system calls uucico will hang
up the connection and prepare to call it back.  This is off by default.

sequence BOOLEAN

If BOOLEAN is true, then conversation sequencing is automatically used
for the remote system, so that if somebody manages to spoof as the
remote system, it will be detected the next time the remote system
actually calls.  This is off by default.

protocols STRING

Specifies which protocols to use for the other system, and in which
order to use them.  This would not normally be used.  For example,
``protocols g''.  By default the set of protocols compiled into the
uucico daemon is used.

protocol-parameter CHARACTER STRING ...

CHARACTER is a single character specifying a protocol; the remaining
strings are a command specific to that protocol which will be executed
if that protocol is used.  The typical command will be something like
``window 7'', hence the name protocol-parameter.  The particular
commands are protocol specific.  Currently the 'g' protocol [ which is
the only one implemented anyhow ] supports ``window'',
``packet-size'', ``startup-retries'', ``init-retries'',
``init-timeout'', ``retries'', ``timeout'' and ``garbage'' all of
which take numeric arguments.

call-request BOOLEAN

The BOOLEAN indicates whether when the local system places the call it
may request file transfers (in either direction).  The default is yes.

called-request BOOLEAN

Whether when the other system places the call it may request file
transfers (in either direction).  The default is yes.

request BOOLEAN

Identical to ``call-request BOOLEAN\ncalled-request BOOLEAN.''

call-transfer BOOLEAN

Whether when the local system places the call it may do file transfers
queued up for the remote system.  The default is yes.

called-transfer BOOLEAN

Whether when the other system places the call the local system may do
queued up file transfers.  The default is yes.

transfer BOOLEAN

Identical to ``call-transfer BOOLEAN\ncalled-transfer BOOLEAN.''

local-send STRINGS

Specifies that files in the directories named by the STRINGS may be
sent to the remote system when requested locally (using uucp or uux).
The directories in the list should be separated by whitespace.  A ~
may be used for the public directory (on a UNIX system, this is
typically /var/spool/uucppublic; it may modified with ``pubdir'').
For example:

	local-send ~ /var/spool/ftp/pub

Listing a directory allows all files within the directory and all
subdirectories to be sent.  Directories may be excluded by preceding
them with an exclamation point.  For example:

	local-send /usr/ftp !/usr/ftp/private ~

means that all files in /usr/ftp or the public directory may be sent,
except those files in /usr/ftp/private.  The list of directories is
read from left to right, and the last directory to apply takes effect;
this means that directories should be listed from top down.  The
default is ~.

remote-send STRINGS

Specifies that files in the named directories may be sent to the
remote system when requested by the remote system.  The default is ~.

local-receive STRINGS

Specifies that files may be received into the named directories when
requested by a local user.  The default is ~.

remote-receive STRINGS

Specifies that files may be received into the named directories when
requested by the remote system.  The default is ~.

command-path STRING

Specifies the path (a list of whitespace separated directories) to be
searched to locate commands to execute.  The default is from the
system dependent header file.

commands STRINGS

The list of commands which the remote system is permitted to execute
locally.  For example: ``commands rnews rmail''.  If the value is
``ANY'' (case significant), any commands may be executed.  The default
is from the system dependent header file.

free-space NUMBER

Specify the minimum amount of file system space (in bytes) to leave
free when receiving a file.  If the incoming file will not fit, it
will be rejected.  This will only work when talking to another
instance of this package, since older UUCP packages do not provide the
file size of incoming files.  There is no provision for reserving
space, so it is still possible for multiple uucico daemons to use up
all available file space; a sufficiently large value for
``free-space'' will avoid this problem to some extent.  The default is
from the system dependent header file.  Not all systems may be able to
provide the amount of available space.

pubdir STRING

Specifies the public directory that is used when ~ is specifed in a
file transfer or a list of directories.  This essentially overrides
the public directory specified in the main configuration file for this
system only.  The default is the public directory specified in the
main configuration file.

myname STRING

Specifies the system name to use when calling the remote system.
Also, if ``called-login'' is used and is not "ANY", then when a system
logs in with the specified login name STRING is used as the system
name (because the local system name must be determined before the
remote system has identified itself, using ``myname'' and
``called-login'' together for any system will set the local name for
that login; this means that each locally used system name must have a
unique login name associated with it).  This allows a system to have
different names for an external and an internal network.  The default
is not use to a special local name.


The following are used as default values for all systems; they can be
considered as appearing before the start of the file.

	timetable Evening Wk1705-0755,Sa,Su
	timetable Night Wk2305-0755,Sa,Su2305-1655
	timetable NonPeak Wk1805-0655,Sa,Su
	time Never
	chat "" \r\c ogin:-BREAK-ogin:-BREAK-ogin: \L word: \P
	chat-timeout 60
	callback n
	sequence n
	request y
	transfer y
	local-send ~
	remote-send ~
	local-receive ~
	remove-receive ~
	command-path [ system dependent ]
	commands rnews rmail

*** The port configuration file

The port file may be used to name and describe ports.  The first
command in the file must be ``port''.  All command up to the next
``port'' command then describe that port.  There are different types
of ports, and each type supports its own set of commands.  Each
command indicates which types of ports support it.

port STRING

Introduces and names a port.

type STRING

Define the type of port.  The default is ``modem''.  If this command
appears, it must immediately follow the port command.  The type
defines what commands are subsequently allowed.  Currently the types
``modem'' (for a modem hookup), ``stdin'' (for a connection through
stdin and stdout, as when uucico is run as a login shell) and
``direct'' (for a direct connection to another system) are defined.
[ In the future types ``tcp'' and ``ftp'' should be added.  The type
``ftp'' should allow use of uucp to perform FTP transfers, which would
be convenient to do the transfers late at night, for example. ]

device STRING [ modem and direct only ]

Names the device associated with this port.  If the device is not
named, the port name is taken as the device.  Device names are system
dependent, but a Unix example would be /dev/ttyd0.

baud NUMBER [ modem and direct only ]

The baud rate this port runs at.  If a system specifies a baud rate
but no port name, then all ports which match the baud rate will be
tried in order.  If the baud rate is not specified here and is not
specified by the system, the natural baud rate of the port will be
used by default.

carrier BOOLEAN [ modem only ]

If the argument is TRUE, then after dialing the phone number uucico
will wait for carrier to come on.  This is only supported on a few
systems.  If the argument is FALSE, soft carrier is forced if the
system supports it.  The default is FALSE.

carrier-wait NUMBER [ modem only ]

If the port is supposed to wait for carrier, this may be used to
indicate how many seconds to wait.  The default is 60 seconds.

dial-device STRING [ modem only ]

Dialing instructions should be output to the named device, rather than
to the normal port device.  The default is to output to the normal
port device.

protocol-parameter CHARACTER STRINGS [ any type ]

The same command as the protocol-parameter command used for systems.
This one takes precedence.

dialer STRING [ modem only ]

Name a dialer to use.  The information is looked up in the dialer
file.  There is no default, and some sort of dialer information must
be specified to call out on a modem.

dialer STRING ... [ modem only ]

Execute a dialer command.  If a dialer is named, these commands are
ignored.  They may be used to specify dialer information directly in
simple situations without needing to go to a separate file.  There is
no default, and some sort of dialer information must be specified to
call out on a modem.

*** The dialer configuration file

The dialer configuration file defines dialers.  The first command in
the file must be a ``dialer'' command which names the dialer.
Subsequent commands up to the next ``dialer'' command are associated
with the named dialer.

dialer STRING

Introduces and names a dialer.

chat STRINGS

A set of expect/send pairs, just like a login script, used to dial the
phone.  All the escape sequences defined for the login script may be
used (except for \L and \P) and the following escape sequences may
also be used:

	\D -- send phone number without dialcode translation
	\e -- disable echo checking on send
	\E -- enable echo checking (wait for echo before continuing)
	\T -- send phone number with dialcode translation

When echo checking is enabled then after writing each character to the
dialer the program will wait until the character is echoed.  There is
no default.

chat-timeout NUMBER

The number of seconds to wait for an expect string in the chat script
before timing out and sending the next subsend or failing the chat
script entirely.  The default is 60.

dialtone STRING

A string to output when dialing the phone number which causes the
modem to wait for a secondary dial tone.  This is used to translate
the '=' character in a phone number.  If it is not defined, the '='
character is dropped.

pause STRING

A string to output when dialing the phone number which causes the
modem to wait for 1 second.  This is used to translate the '-'
character in a phone number.  If it is not defined, the '-' character
is dropped.

dtr-toggle BOOLEAN BOOLEAN

If the first argument is TRUE, then DTR is toggled before using the
modem.  This is only supported on some systems and some ports.  The
second BOOLEAN need not be present; if it is, and it is TRUE, the
program will sleep for 1 second after toggling DTR.  The default is
not to toggle DTR.

complete STRING

When the call is finished normally, STRING is sent to the modem.  The
string may contain escape sequences just as a send string in a chat
script.  The default is to send nothing on completion.

abort STRING

If the call is somehow aborted, STRING is sent to the modem.  If this
is not defined, the dialer complete string is sent instead.  The
string may contain escape sequences just as a send string in a chat
script.  The default is to send nothing when the program is aborted.

protocol-parameter CHARACTER STRINGS

Set protocol parameters, as the similar command in the system
configuration file or the port configuration file.  These parameters
take precedence, then those for the port, then those for the system.
[ Currently these only take effect when dialing out, not when
accepting a call ]

*** Brief example

Here is the main configuration file and the system configuration file
actually used here to call uunet.  There is also a call out password
file which, for obvious reasons, is not shown.

The main configuration file (this would be needed if the local name of
this system were airs or airs.airs.com):

nodename airs

The system configuration file (this controls a Telebit 2500 which
calls uunet; uunet tends to have slow response time, so the timeouts
are forced to higher values; the window and packet sizes used for the
'g' protocol are the defaults anyhow, and are the correct values to
trigger Telebit UUCP spoofing).

system uunet
call-login *
call-password *
time night
phone 7389449
chat-timeout 120
port type modem
port device /dev/ttyd0
port baud 19200
port carrier true
port dialer chat "" ATZ\r\d\c OK ATDT\D
port dialer complete \d\d+++\d\dATH\r\c
port dialer abort \d\d+++\d\dATH\r\c
protocol-parameter g window 3
protocol-parameter g packet-size 64
protocol-parameter g timeout 20
protocol-parameter g retries 10
-- 
Ian Taylor | ian@airs.com | First to identify quote wins free e-mail message:
``Learning is not like a coin, which remains physically whole even through
  the most infamous transactions; it is, rather, like a very handsome dress,
  which is worn out through use and ostentation.''




From kre@cs.mu.OZ.AU Wed Nov 13 14:57:45 1991
To: piers@uunet.UU.NET (Piers Lauder)
Subject: Re: hi! 
Date: Thu, 14 Nov 91 06:56:11 +0100
From: Robert Elz <kre@cs.mu.OZ.AU>
Status: OR

    Date:        Wed, 13 Nov 91 14:25:29 EST
    From:        piers@uunet.uu.net (Piers Lauder)

    Donnalyn says she has told you i'm here -

Yes, she did -- I had forgotten you were going, but now I
remember Bob mentioning it at AUUG (maybe you as well, but
Bob went on about it longer for sure...)

    but i will be grateful
    if you manage to restrain yourself from comment.

Hmmm ... am I to have no fun at all?

    anyway, any pet wants that i should include?
    (the basic priority is speedup.)

Apart from implementing all that should have been implemented
initially (window size negotiations, etc, in the f protocol),
just one really - the ability to set your local host name
depending on who you're connecting to (or who is connecting to
you).  Since murtoa went away munnari has to pretend to be
both munnari & mulga for uucp links (it used to just pretend
to be mulga, murtoa was munnari ... yes, I know, weird...)

I have done a very quick hack to munnari's uucp so that this
kind of works, but it is a hack, and shows it.

From rick Tue Nov 19 11:35:50 1991
Date: Tue, 19 Nov 91 11:35:49 -0500
From: rick (Rick Adams)
To: piers
Subject: uucp to look at
Status: OR


this is the most "modern" version. The style is horrible, but the
code seems to do the correct thing.

--rick

>From ian@airs.com Sat Nov 16 14:55:17 1991
Path: uunet!uunet!airs!ian
From: ian@airs.com (Ian Lance Taylor)
Newsgroups: comp.mail.uucp
Subject: Version 1.0 of UUCP package available
Message-ID: <2919@airs.com>
Date: 16 Nov 91 19:55:17 GMT
Sender: news@airs.com
Lines: 67

Version 1.0 of my UUCP package, modestly entitled Taylor UUCP, is now
available on uunet for anonymous FTP or UUCP.  It is entitled
~/tmp/taylor-uucp-1.0.tar.Z.  I have asked James Revell at uunet to
copy it to ~/communications/taylor-uucp-1.0.tar.Z, so it should soon
be available under either name.  It is, obviously, a compressed tar
file.  I will not be providing diffs from my earlier beta release,
since they approach the size of the package itself.

I will take whatever feedback I get after a week or so and post the
possibly slightly changed package to alt.sources and one of the
comp.sources groups (comp.sources.unix, I guess; I don't really
understand the difference between the various groups, so if somebody
would care to explain them to me in e-mail I would be grateful).  If I
do make any patches, I'll post a note here as well.

The package is covered by the Gnu Public License.  It currently runs
only under Unix.

What are the advantages over your current UUCP package?  You get
source code.  It's efficient (running on a MicroVax II GPX using
Ultrix 3.1 talking to uunet over a Telebit 2500, we used to get from
900 to 1000 bytes per second with the system UUCP; we now get 1100 to
1250 bytes per second).  It supports the 'f', 'g' (in all window and
package sizes) and 't' protocols.  If you have a Berkeley sockets
library, it can make TCP connections.  It supports a new configuration
file mechanism which I like (but other people dislike); it also
supports both V2 (traditional) and BNU (HDB) UUCP configuration files.
You can specify a chat script to run when a system calls in, allowing
adjustment of modem parameters on a per system basis.  You can specify
failure strings for chat scripts, allowing the chat script to fail
immediately if the modem returns ``BUSY''.  If you are talking to
another instance of the package, you can restrict file transfers by
size based on the time of day and who placed the call.

What are the disadvantages?  You only get uucico, uuxqt, uux and uucp
(you also get uuchk which reads the log files and tells you how they
are interpreted).  You do not get uulog, uustat, uusched, etc.  If you
already have copies of these programs, you may be able to continue to
use them, but you may not.  The format of the log files, in
particular, is completely different.  The package does not ready
modemcap or acucap files, although you can use V2 configuration files
with a BNU Dialers file or a dialer port written in my new
configuration file format.  The package cannot use dialer programs
directly, although it can with a simple shell script interface.

I've punted on the issue of chat scripts which I raised a while ago in
this group.  There were too many good ideas for me to make sensible
choices.  Instead, I adopted an idea from Greg Woods and other people,
and allow specification of a program to run instead of or as well as a
chat script.  The program will have stdin and stdout attached to the
modem port, and messages written on stderr will be placed in the UUCP
log file.  The exit status is used to indicate success or failure.

If you start using this package, let me know.  If there are any
changes you want, let me know that as well.  I have some thoughts on
what I want to do next, but suggestions are always seriously
considered.  I doubt I will be doing anything dramatic for the next
few months, as nobody is paying me to work on this and my bank account
is down to one months rent, but I intend to keep improving this
program over time.

Thank you for your attention.
-- 
Ian Taylor                  ian@airs.com                  uunet!airs!ian
First person to identify this quote wins a free e-mail message:
``It doesn't matter how obvious the truth is if the truth is that you'll
  never escape.''



From revell Tue Dec  3 18:13:29 1991
From: revell (James R Revell Jr)
Subject: Re: rick claims you are the `L.sys' expert :-)
To: piers@rodan.UU.NET (piers)
Date: Tue, 3 Dec 91 18:13:27 EST
Status: OR

> My query has to do with the single `'' in uunet's L.sys file
> (char 7804, line 201: "binasco Polled Ra'ananna 2400")
>
> Is this intended/legal?

I believe it was intended, although certainly different from what's
done at other places.  For sites we never call (past included), we use
the third field to record the city the site is in.  That site is in
Israel and the city name contains the "'".

The site is connecting, so the usage is valid if not legal.  It may
just be legal locally, but I think it works at other places too.  It's
an undocumented thing though.

Although the third field is parsed regardless of whether calls to the
site are enabled or not, the value of the field is only used
  . when making calls (only the documented values would be useful)
  . with TCP connections.  If the field is "TCP" then subsequent fields
    contain some info, but I don;t believe it must say "TCP" for the
    TCP connection to work.
    

This is sort of like the schedule field supposedly being composed of
the defined keywords and times.  Of course, any undefined keywords
are interpreted as "Polled" if they begin with an uppercase letter,
or "Never" otherwise.  It's a lot easier to prepend a capital letter
to turn off calls without loosing the entry, or to lowercase the first
letter to disable the account entirely.

	-james

From rick Thu Jan 16 18:29:52 1992
Date: Thu, 16 Jan 92 18:29:50 -0500
From: rick (Rick Adams)
To: piers
Subject: uucico restart instructions
Status: OR

>From ian@airs.com Thu Jan 16 00:40:50 1992
Path: uunet!uunet!airs!ian
From: ian@airs.com (Ian Lance Taylor)
Newsgroups: comp.mail.uucp
Subject: Re: resuming transfers (was: Re: PEP Upgrade for T3000?!?!?)
Message-ID: <3320@airs.com>
Date: 16 Jan 92 05:40:50 GMT
References: <23573@celit.fps.com> <936.0501920901@brewhq.swb.de> <23610@celit.fps.com> <1992Jan14.060025.20812@cbnewse.cb.att.com> <3315@airs.com>
Sender: news@airs.com
Lines: 59

ian@airs.com (Ian Lance Taylor) writes:

>Would anybody care to explain the protocol used by SVR4 to resume file
>transfers?

All right, somebody sent me e-mail explaining all.  I won't name him
in case he would rather remain anonymous.  This is what he said:

---------------------------------------
Assume we have two AT&T 5.4 uucico's talking to each other with the SLAVE
machine name 'ucat' and the MASTER machine name 'macaux'.  In the example
below, ^P and ^@ are the SYNC and NULL characters. 

  MASTER calls SLAVE, gets logged in.

  SLAVE starts off with the message:
	^PShere=sys1^@

  MASTER responds by saying it supports Restart (-R):
	^PSsys2 -Q0 -R -U0x1000000 -x9^@

  MASTER responds by saying it supports Restart (-R):
	^PROK -R -U0x1000000 -x9^@

[ In a later mail message I was told that the -U switch gives the
  current ulimit value; a request of a file that exceeds the reported
  ulimit gets ``N10'' (probably RN10). ]

The stage is now set, both sides agree to use the Restart capability.  It has
nothing to do with the protocol selection.  However, the protocol may need a
few lines of change to handle sending and receiving files from any point in
the file.  If machine 'macaux' wants to send the file '/unix' over to
'ucat', this would be the message sent from 'macaux' (MASTER):

  S /unix ~ root -dc D.ucat3686688 644 root dummy 0xf3fd4

The message contains the actual full size of the file '/unix' as a hex
number '0xf3fd4'.  Doesn't matter if this is the 19th time we're tried
resending this file, this number is always the full size of the file.  The
SLAVE will send this message in response:

  SY 0x0

This says that it wants us to start sending the file from offset 0 (beginning
of the file).  If we had already sent part of the file in a previous session
that failed, the SLAVE would send us the offset of where to start as in:

  SY 0xe000

Offsets are rounded in 5.4 to BUFSIZ boundaries (speed improvements I guess).
---------------------------------------

[ This should make it into the next version (1.03) of the Taylor UUCP
  package.]
-- 
Ian Taylor                 ian@airs.com                 uunet!airs!ian
First person to identify this quote wins a free e-mail message:
``Hagenbeck sent a special expedition to Lake Bangweolo; unfortunately
  this expedition did not even find the lake.''



From revell Tue Feb  4 17:51:28 1992
From: revell (James R Revell Jr)
Subject: Re: L.sys fields: what is the minimum number,
To: piers@rodan.UU.NET (piers)
Date: Tue, 4 Feb 92 17:51:27 EST
Status: OR

> and what should one do with lines that have less?
> eg: which of the following are invalid lines:
> 	1:	node
> 	2:	node any
> 	3:	node any acu
> 	4:	node any acu 9600

None of them will allow an incoming connection (because any starts
with a lowercase letter).  If you s/any/Any/ then I think 2,3, & 4
will work for incoming calls.  None will work for outgoing calls
since they're ACU and that requires a number to call (field 5)

There must be a first field, the second field enables incoming and/or
outgoing connections.  I don't think any other fields are required for
incoming calls.

If an outgoing connection is enabled then field three must be present.
Based on the value of field three more fields may be needed too.  I
think ACU just requires two more fields, although a third or more
subsequent fields (the chat script) are needed to be useful on most
systems.  I can think of instances where you wouldn't use a chat script
though.

Don't you love value based parsing.

	-james

From rick Thu Feb 27 17:54:06 1992
From: rick (Rick Adams)
Subject: Re: uucico packet sizes apear to be 64,
To: piers@rodan.UU.NET (Piers Lauder)
Date: Thu, 27 Feb 92 17:54:05 EST
Status: OR

Yes, except there are a LOT of buggy implementations of uucico that
have allocated a 128 byte buffer to hold incoming packets, so
the remote uucico silently core dumps after happily negotiating a
higher packet size.

The way to get around this is to leave the default 64, but allow setting
a higher packet size on teh L.sys line. (This is how HDB does it I think)



From revell Thu Mar  5 02:07:41 1992
From: revell
Subject: Re: why does `callback' use the `user' field in the USERFILE?
To: piers@ghidra.UU.NET (Piers Lauder)
Date: Thu, 5 Mar 92 2:07:37 EST
Status: OR

> Subject: why does `callback' use the `user' field in the USERFILE?

It doesn't to my knowledge.  It uses an option field after the
user,system field and before the pathname fields.

Ie: USERFILE format is
	[username],[system] [c] pathname [pathname ...]

Although I've never really used the callback stuff, I think one would
just end up using something like this in the case of just wanting to
use callback (and not restricting file access any more than normal)

	,system c pathname(s)

That would just cause a message about callback to be printed, the
remote to hangup, and (?) a call to be made to the remote.  Once
the call is made to the remote you check USERFILE from scratch
(and the callback stuff is meaningless then)

I think the callback stuff in HDB is easier to deal with

	-james

From ziegast Fri Mar  6 22:05:58 1992
Subject: Protocol Q.  (fwd)
To: piers
Date: Fri, 06 Mar 92 15:35:22 EST
From: Eric Ziegast <ziegast>
Status: OR

Just FYI...
--
Eric Ziegast

Forwarded message:
> Date:    Wed, 4 Mar 92 18:04:57 -0500 
> From:    ian@airs.com (Ian Lance Taylor) 
> Subject: Protocol Q. 
> To:      uunet!ziegast (Eric Ziegast) 
> 
> Thanks for the bcc:.
> 
> > UUNET supports packet sizes from 64 bytes to 4096 bytes in powers of 2
> > (64, 128, 256, ..., 4096).  Our UUCP prefers window sizes of 7.
> 
> Not that it matters much, but what about 32 byte packets?
> 
> > You really don't want to use 4K packets unless what you're transferring is
> > really big and your connection is reliable.  I'd recommend a packet size
> > of 256 when picking up mail and 512 or 1K for news or other large-file
> > transfers.
> 
> If a packet size other than 64 is being used, Taylor UUCP will
> automatically adjust the packet size downward if the data will fit in
> a smaller packet (a packet size of 64 is treated specially since many
> older UUCP packages will freak out if they see a 32 byte packet).  I
> assume that uunet is running custom UUCP code; I recommend adding this
> simple modification, since it makes a big efficiency difference even
> at smaller block sizes.  One Taylor UUCP user reported:
> 
> Using g, windows 7, size 64, I receive files at approximately .460Kb/s.
> Using g, windows 7, size 512 (non-adjusting blocks)           .661Kb/s.
> Using the new g,7,512                                         .841Kb/s.
> 
> > If you have a Telebit, using spoofing correctly will help more than
> > just increasing the packet size.
> 
> Absolutely.
> -- 
> Ian Taylor                  ian@airs.com                  uunet!airs!ian
> First person to identify this quote wins a free e-mail message:
> ``The will to be stupid is a very powerful force.''

From rick Mon Mar 16 16:12:20 1992
Received: by rodan.UU.NET (5.61/UUNET-mail-drop)
	id AA09319; Mon, 16 Mar 92 16:12:18 -0500
Date: Mon, 16 Mar 92 16:12:18 -0500
From: rick (Rick Adams)
Message-Id: <9203162112.AA09319@rodan.UU.NET>
To: piers
Subject: old uucp notes
Status: OR


>From rkh@mtune.UUCP Thu Apr 20 09:36:41 1989
Path: uunet!cs.utexas.edu!tut.cis.ohio-state.edu!rutgers!att!mtune!rkh
From: rkh@mtune.ATT.COM (Robert Halloran)
Newsgroups: comp.mail.uucp
Subject: Re: uucp protocol selection question.
Message-ID: <7980@mtune.ATT.COM>
Date: 20 Apr 89 13:36:41 GMT
References: <19135@adm.BRL.MIL> <505@lakart.UUCP>
Reply-To: rkh@mtune.UUCP (Robert Halloran)
Organization: AT&T ISL Middletown NJ USA
Lines: 31
Status: OR

In article <505@lakart.UUCP> dg@lakart.UUCP (David Goodenough) writes:
>kadmon!jason@mtxinu.com (Jason Venner) sez:
>> I would like my uucp to try for different protocols depending on what
>> io device the uucico is running on at the time.
>> 
>> Is there a way to specify the preferred protocol?

If you're running HoneyDanBer UUCP, you can specify either in the Systems
or Devices file what protocols are usable.

Devices:

ACU[,protocols] .....

Systems:

system Any[,protocols] ....

where the optional 'protocols' field says what the system will offer when
using that device or calling that system. 

						Bob Halloran
						Distributed Programming
						  Tools Group
=========================================================================
UUCP: {att, rutgers}!mtune!rkh			DDD: (201)957-6034
Internet:   rkh@mtune.ATT.COM			       
USPS: AT&T Bell Labs, 200 Laurel Ave Rm 3G-314 Middletown NJ 07748
Quote: If Basic is for backward children, and Pascal for naughty
  schoolboys, then C is the language for consenting adults - Brian Kernighan
=========================================================================


>From bostic@okeeffe.Berkeley.EDU Thu May 18 23:34:07 1989
Received: from okeeffe.Berkeley.EDU by uunet.UU.NET (5.61/1.14) with SMTP 
	id AA15484; Thu, 18 May 89 23:34:03 -0400
Received: by okeeffe.Berkeley.EDU (5.61/1.29)
	id AA00556; Fri, 19 May 89 03:34:16 GMT
Date: Fri, 19 May 89 03:34:16 GMT
From: bostic@okeeffe.Berkeley.EDU (Keith Bostic)
Message-Id: <8905190334.AA00556@okeeffe.Berkeley.EDU>
To: rick@uunet.UU.NET
Subject: uucp
Status: OR


I was thinking -- perhaps the configuration files should go
in /etc/uucp.  The log files to /var/log.  The administration
utilities to /usr/sbin.  The user interfaces to /usr/bin.
The backend programs to /usr/libexec?

--keith

>From vixie@vixie.sf.ca.us Wed May  2 01:54:14 1990
Received: from vixie.sf.ca.us by uunet.uu.net (5.61/1.14) with SMTP 
	id AA05975; Wed, 2 May 90 01:54:11 -0400
Received: by vixie.sf.ca.us; id AA08114; Tue, 1 May 90 22:52:35 -0700
Message-Id: <9005020552.AA08114@vixie.sf.ca.us>
To: rick@uunet.uu.net (Rick Adams)
Subject: Re: new uucp? 
In-Reply-To: Your message of Tue, 01 May 90 14:41:54 -0400.
             <9005011841.AA02299@uunet.uu.net> 
Date: Tue, 01 May 90 22:52:30 PDT
From: Paul A Vixie <vixie@vixie.sf.ca.us>
Status: OR

I'd like to repeat a request I sent a while ago, with respect to dialers.
What I want to see is a callout interface along the lines of:

if a L-devices (or L-dialers if you add that level of indirection)
says to use some command (e.g., /usr/lib/uucp/dialit), then that
command will be forked with file descriptors 0/1/2 set to the device
and the argv[] set to the name of the system, the baud rate, the
phone number, and whatever else we can think of.  

ideally we'd be able to bind a single command execution to some
number of different ports, but that implies that the command will
open the file descriptors rather than inheriting them.  given the
trouble we've had with acucntrl's semantics, this could be a win.

the command's exit status tells uucico whether the dial was successful.
we might want to have 0=success, 1=failure in the local modem (no dialtone),
and 2=failure at the remote system (busy signal); uucico would either
try the next L-dialers/L-devices entry (ex_status==1) or the next L.sys
entry (ex_status==2), or proceed normally (ex_status==0).

HP's UUCP has something like this, and I remember liking it a lot when
I was running hpsemc and parts of hpda for a while some years back.

Further, I'm willing to actually do this work.  But only if you'll
take it for the 4.4 release.

>From vixie@vixie.sf.ca.us Wed May  2 13:15:25 1990
Received: from vixie.sf.ca.us by uunet.uu.net (5.61/1.14) with SMTP 
	id AA26598; Wed, 2 May 90 13:15:21 -0400
Received: by vixie.sf.ca.us; id AA11495; Wed, 2 May 90 10:13:40 -0700
Message-Id: <9005021713.AA11495@vixie.sf.ca.us>
To: rick@uunet.uu.net (Rick Adams)
Cc: myself at work <vixie@jove.pa.dec.com>
Subject: Re: new uucp? 
In-Reply-To: Your message of Wed, 02 May 90 11:18:33 -0400.
             <9005021518.AA02912@uunet.uu.net> 
Date: Wed, 02 May 90 10:13:38 PDT
From: Paul A Vixie <vixie@vixie.sf.ca.us>
Status: OR

Using unix domain sockets to pass fd's back and forth is a better idea,
I admit.  Just as long as there's a utility whose source code contains
nothing of AT&T which can be hacked to do connection support.  We don't
add to the rest of uucico very often; I expect that lots of binary-only
sites would be able to hack everything they wanted on uucp if the dialer
part of it were in a different utility.

A logical extension of this is to move the connection-part completely
out of uucico, such that uucico would search L-devices, create a list
of lines and their dialers that matched the current L.sys's connection
type and baud rate and so on; then it would fork off the dialer.

L.sys... (needs to support distinct ACU types per baud rate)
old:	uunet Any ACU 19200 4155551212 ogin:--ogin: Udecwrl word: foobar
	(ACU is sometimes WATS, which currently does but should not need
	a hack to uucico source code, per ACU-type)
	(19200 is ambiguous, since sometimes it's PEP and sometimes it's
	V.42 and sometimes it's HST; also, we've got at least one neighbor
	which we can call at PEP-9600 but not PEP-19200)
	(both of these values should be enumerated in config files, not
	in a compiled-in source-code-level table)
new:	uunet Any ACU PEP-FAST 415...
	uunet Any WATS V42 415...

L-devices... (needs to stop caring so much about baud rates and such)
old:	ACU tty00 tty00 19200 vhayestone "" ATs7=90s58=2s50=255 OK~5
	(ACU is now defined by this file, not treated specially in uucico)
	(I guess we need to maintain the ACUdev-vs-dev split)
	(Baud rate is now a token, defined here as is ACU)
	(acutype is now the name of a program, default path for which
	is settable by PATH= as in L.cmds)
	(What we need is a radical change, since I'd like to hand the
	"dialer" program a list of devices and let it pick any one of
	them; this is best done as a single entry listing multiple
	devices since otherwise we end up with N>1 chat scripts and
	we don't know which one to use).
	(I'd like to be able to specify TCP UUCP in this file, so that
	this type of connection was also set up by an outboard program,
	leaving uucico with just some open file descriptors.  this makes
	it hard to allow for lists of devices since TCP UUCP won't have
	them.)
new:	ACU PEP-FAST * tty00,tty01,tty02,tty03 tb-dialer 19200 s7=90s58=2
	(* = "ACU is always the same as the device"; if you list a specific
	ACU than all devices in the list have to be dialable by it)
	(device list is handed to dialer as a single argv[n] with commas)
	(tb-dialer is the name of a program)
	(19200 and s7=90s58=2 are dialer-specific parameters, different
	for each dialer program)
	(there's no chat script.  i'll explain why in a minute.)
	TCP UUCP * * tcp-dialer
	(* * = placeholders)

This file needs some more notes.  First, we'd supply a generic dialer that
had a big case statement in it for the common types like DIR and ACU HAYES
and maybe TCP UUCP.  The source for this would be ATT-free, so it could be
used as a prototype by binary-only sites.

Second, the lack of a chat script.  It's a fact that a lot of devices need
special chats done on them before the dialer code will actually be facing
a dialer -- telebits hanging off of ethernet terminal servers are a great
example.  But rather than chat scripts, I'd like to be able to cascade the
dialers.  At Ungermann-Bass, for example, I had some telebits hanging off
a terminal server but I ended up reaching that terminal server via a 
terminal server that was connected to a serial port on the VAX.  So even
though the VAX had an ethernet port and XNS-capable sockets (needed to 
reach the remote terminal server), I had to use serial ports.  Bad news.

If I could have told UUCICO to "use this dialer, then use that dialer"
then I would have hacked up an XNS connectifier and let it set up a
connection to the remote, then let the standard telebit dialer do the
rest.

I'm having trouble thinking up a syntax for this, but I know it's something
I want.  And more important, it's something HDB does not have :-) :-)..

Comments?

>From cirian@einstein.eds.com Thu Jan 10 13:56:52 1991
Path: uunet!edsews!einstein!cirian
From: cirian@einstein.eds.com (Steve Cirian)
Newsgroups: comp.dcom.modems
Subject: Re: Telebit ATJ6J0?
Summary: decipher atj6j0 output
Message-ID: <247@einstein.eds.com>
Date: 10 Jan 91 18:56:52 GMT
References: <1991Jan9.090037@mathcs.emory.edu>
Organization: EDS/TSD - Troy, MI
Lines: 77
Status: OR

In article <1991Jan9.090037@mathcs.emory.edu>, km@mathcs.emory.edu (Ken Mandelberg) writes:
> There has been some reference in this group to the undocumented status
> info extracted by ATJ6J0 on a trailblazer. Does anyone have documentation?

I saved the following from this newsgroup a while ago:

<<From dnb@chaos.cs.brandeis.edu Tue Apr  3 13:14:28 1990
<<Path: einstein!edsews!uunet!ogicse!mintaka!chaos.cs.brandeis.edu!chaos!dnb
<<From: dnb@chaos.cs.brandeis.edu (David N. Blank)
<<Organization: Brandeis University Computer Science Dept
<<Posted: Tue Apr  3 10:14:28 1990
<<
<<The second, and perhaps less "put your ear on the modem and listen for
<<the train coming, Paleface" advice I got was to use the following
<<(undocumented, hooray!) command: ATJ6J0.  This gives a result of the
<<form:
<<   Raaaaaa Rbbbb Rccc
<<   Tdddddd Feeeeee Rffffff Mgggggg Ehhhhhh
<<   jjj lll mmm
<<   nnn
<<   ooo ppp
<<   Mqqqq
<<  
<< where:
<<    a - count of number of times modem has retrained
<<    b - reason for last retrain:
<<       0) never retrained
<<       1) modem saw too many quiet packets
<<       2) packet error rate too high
<<       3) same packet was retransmitted too often
<<       4) &R command was issued
<<    c - reason for the last "NO CARRIER" message:
<<       0) never reported "NO CARRIER"
<<       1) failed during synch
<<       2) packet size too small
<<       3) carrier lost
<<       4) H0 command issued
<<       5) Illegal switch to 212/v22bis
<<       6) DTR dropped
<<       7) talk/data switch pushed
<<       8) negotiation failed
<<       9) received disconnect packet
<<    d - the number of packets thrown out
<<    e - the number of packets received while full
<<    f - the number of packets retransmitted
<<    g - the number of times the modem missed a line turnaround
<<    h - the number of times the modem didn't have a packet ready to
<<        transmit when it was its trun to send
<<    i - the number of framing errors
<<    j - the number of overrun errors
<<    k/l/m - the 2/4/6 bit S/N ratios
<<    n - the attenuator setting
<<    o - the number of bytes per transmitted packet
<<    p - the number of bytes per received packet
<<    q - the MNP class the modem is operating at
<<
<<Please don't ask me to interpret any of the above for you, I typed it
<<straight from the information Tech support gave me (a nice set of
<<people, BTW). If the above display indicates a problem, I understand
<<you can up the amount of tone used for PEP and twiddle a bit with its
<<operating paramters.  For that info, you should see Tech support.
<<Hope this stuff is useful.
<<         Peace,
<<           dNb
<<        dnb@chaos.cs.brandeis.edu
<<
<<P.S. as a last resort you could try spattering sheep's blood on your
<<modem or conducting a small sacrifice.  It may not help the modem
<<problem, but it does wonders for stress.
<<
<<

-- 
Steve Cirian		~  local girl:  What does BRMC stand for?
750 Tower Drive		~  Johnny:      Black Rebels Motorcycle Club
Troy, MI 48007		~  local girl:  What are you rebelling against?
(313) 265-5738		~  Johnny:      Whattya got?



From rick Mon Mar 16 16:13:49 1992
Received: by rodan.UU.NET (5.61/UUNET-mail-drop)
	id AA09569; Mon, 16 Mar 92 16:13:44 -0500
Date: Mon, 16 Mar 92 16:13:44 -0500
From: rick (Rick Adams)
Message-Id: <9203162113.AA09569@rodan.UU.NET>
To: piers
Subject: more old uucp notes
Status: OR



>From asp Mon Aug 19 15:48:06 1991
Received: from batch.UU.NET by uunet.UU.NET with SMTP 
	(5.61/UUNET-uucp-primary) id AA19701; Mon, 19 Aug 91 15:48:03 -0400
Received: by batch.UU.NET (5.61/UUNET-internet-secondary)
	id AA02135; Mon, 19 Aug 91 15:47:54 -0400
From: asp
Message-Id: <9108191947.AA02135@batch.UU.NET>
Subject: Configuration files for new UUCP package (long) (fwd)
To: rick (Rick Adams)
Date: Mon, 19 Aug 91 15:47:54 EDT
X-Mailer: ELM [version 2.3 PL10]
Status: OR

Don't know if you had seen this message in comp.mail.uucp nor if you
knew of this guy.
	--asp

Forwarded message:
>From ian@airs.com Mon Aug 19 00:34:11 1991
Path: uunet!uunet!airs!ian
From: ian@airs.com (Ian Lance Taylor)
Newsgroups: comp.mail.uucp
Subject: Configuration files for new UUCP package (long)
Message-ID: <2399@airs.com>
Date: 19 Aug 91 04:34:11 GMT
Sender: news@airs.com
Lines: 770

I am nearing completion of a new UUCP package, which I hope to release
for beta test in a week or two (I'll solicit beta testers when I'm
ready; no need to volunteer now).  The package will be released under
the GNU Public License.

In the meantime, I am looking for some feedback on the system of
configuration files that I am using.  I don't find either the
traditional L.sys L-devices L.cmds or the HDB Systems Dialers
Permissions configuration files particularly easy to understand or
sufficiently flexible to specify everything that is useful for a UUCP
system; they are good, but I arrogantly think I can do better.  I
therefore set up my own system.  I hope to write AWK scripts to
convert the traditional styles into my style.

The rest of this post describes the configuration files that I have
implemented.  My goal here, as for anybody who designs configuration
files, is to allow a simple setup to be implemented simply while also
allowing a complex setup to be handled completely.  I welcome any
comments.  I intend to keep a list of people who have made helpful
suggestions or contributions; if you prefer to be anonymous, please
let me know.

*** The configuration files

All the configuration files follow a simple line-oriented keyword
value format.  The first word on each line is a keyword of some sort
(empty lines are ignored).  The rest of the line is interpreted
according to the keyword.  Most keywords are followed by numbers,
boolean values or simple strings (with no embedded spaces).  The '#'
character is used for comments, and everything from a '#' to the end
of the line is ignored.  Everything after the keyword must be on the
same line.  A BOOLEAN may be specified as 'y', 'n', 'Y', 'N', 't',
'f', 'T', or 'F'.

*** The main configuration file

The main configuration file may be specified by the -I option to
uucico.  The default file location is set in the system dependent
header file (sysdep.h).  As all the values that may be specified in it
also have defaults, there need not be a main configuration file at
all.

nodename STRING
hostname STRING
uuname STRING

These keywords are identical.  They specify the UUCP name of the local
host.  If there is no configuration file, an appropriate function will
be used to get the host name, if possible.

spool STRING

Specify the spool directory.  The default is from sysdep.h.  Command
files, work files, temporary files, log files, etc., are stored in
this directory and in subdirectories of it.

sysfile STRING

Specify the system file.  The default is from sysdep.h.  This file
holds information about other systems with which this system
communicates, and is described further below.

portfile STRING

Specify the port file.  The default is from sysdep.h.  This file
describes ports which are used to call other systems and accept calls
from other systems.  It is described further below.  It is optional.

dialfile STRING

Specify the dial file.  The default is from sysdep.h.  This file
describes dialing devices (modems).  It is described further below.
It is optional.

dialcodefile STRING

Specify the dialcode file.  The default is from sysdep.h.  This file
specifies dialcodes that may be used when sending phone numbers to a
modem.  This permits using the same set of phone numbers in different
area-codes and phone systems, by using dialcodes to specify the
calling sequence.  When a phone number goes through dialcode
translation, the leading alphabetic characters are stripped off.  The
dialcode file is read line by line, just like any other configuration
file, and when a line is found whose first word is the same as the
leading characters from the phone number, the second word on the line
(which would normally consist of numbers) replaces the dialcode in the
phone number.  This file is optional.

pubdir STRING

Specify the public directory.  The default is from sysdep.h.  On Unix,
when a file is named using a leading ~/, it is taken from or to the
public directory.

callfile STRING

Specify the call out login name and password file.  The default is
from sysdep.h.  If the call out login name or password for a system
are given as "*" (see the description of the system configuration
file, below), this file is read to get the real login name or
password.  Each line in the file has three words: the system name, the
login name, and the password.  The intention is to permit the system
file to be publically readable; this file must obviously be kept
secure.  This file is optional.

passwdfile STRING

Specify the password to use for login names when uucico is doing its
own login prompting.  The default is from sysdep.h.  Each line in the
file has two words: the login name and the password.  This file is
optional, although it must exist if uucico is to present its own login
prompts.

logfile STRING

Name the log file.  The default is from sysdep.h.  Logging information
is written to this file.

statfile STRING

Name the statistics file.  The default is from sysdep.h.  Statistical
information about file transfers is written to this file.

debug NUMBER

Set the debugging level.  The default is 0.  Numbers between 0 and 9
are relevant; the larger the number, the more debugging information is
output.  This may be overridden by the -x switch to uucico.

unknown STRING ...

The STRING and subsequent arguments are treated as though they
appeared in the system file (see below for a full description).  They
are used to apply to any unknown systems that may call in, probably to
set file transfer permissions and the like.  If the ``unknown''
command is not used, unknown systems are not permitted to call.

*** The system configuration file

This file describes all remote systems known to the UUCP package.  The
first set of commands in the file, up to the first ``system'' command,
specify defaults to be used for all systems.  Subsequently, each set
of commands from the first ``system'' up to the next ``system''
command describe a particular system (default values may be overridden
for specific systems).  There is then another level of defaults, in
that the first set of commands for a particular system, up to the
first ``alternate'' command, specify defaults.  Subsequently, each set
of commands from ``alternate'' up to the next ``alternate'' command
describe an alternate means of calling out or calling in.  When a
system is called, the command before the first ``alternate'' are used
to select a phone number, port and so forth; if the call fails for
some reason, the commands between the first ``alternate'' and the
second are used, and so forth.  When a call is received the various
alternates are checked to permit the login name to specify different
permissions (this will only be done if the first set of commands,
before the first ``alternate'' command, use the ``called-login''
command).

system STRING

Specify the remote system name.  Subsequent commands up to the next
``system'' command refer to this system.

alternate

Start an alternate set of commands, as described above.

alias STRING

Specify an alias for the current system.  The alias may be used by
local uucp and uux commands.  This will also be used when a system
calls in, so that the name used when spooling commands from a system
may be different from the one the system claims for itself.  The
default is to have no aliases.

time STRING

Specify when the system may be called.  Each time specification must
begin with a list containing ``Su'', ``Mo'', ``Tu'', ``We'', ``Th'',
``Fr'', ``Sa'' or ``Wk'' for any weekday or ``Any'' for any day.
Following the day may be a range of hours separated with a hyphen
using 24 hour time.  The range of hours may cross 0; for example
2300-0700 means any time except 7 AM to 11 PM.  If no time is given,
calls may be made at any time on the specified day(s).  Multiple time
specifications may be separated with a vertical bar (|) or a comma
(,).

The time specification may also consist of the single word Never,
which means to never call the system (although the system may be able
to call in) or a single word with a name defined in a previous
timetable (q.v.) command.

The ``time'' command may appear multiple times in a single alternate.
The default value is ``Never''.

timegrade CHARACTER STRING

The CHARACTER is a single character A to Z, a to z, or 0 to 9 and
specifies a grade.  The STRING is a time string as described in the
``time'' command.  All jobs of grade CHARACTER or higher (0 > 9 > A >
Z > a > z) may be run at the specified time.  An ordinary ``time''
command is equivalent to using ``timegrade'' with a grade of z.  If
there are no jobs of a sufficiently high grade according to the time
string, the system will not be called.  Using the -s switch to uucico
to force it to call a system causes it to assume there is a job of
grade 0 waiting to be run.

Note that the ``timegrade'' command serves two purposes: 1) if there
is no job of sufficiently high grade the system will not be called 2)
if the system is called anyway (because the -s switch was given to
uucico) only jobs of sufficiently high grade will be transferred.
However, if the other system calls in, the ``timegrade'' commands are
ignored, and jobs of any grade may be transferred.  Also, the
``timegrade'' command will not prevent the other system from executing
any job it chooses, regardless of who placed the call.

The ``timegrade'' command may appear multiple times without using
``alternate''.  If this command does not appear, there are no
restrictions on what grade of work may be done at what time.

call-timegrade CHARACTER STRING

The CHARACTER is a single character A to Z, a to z, or 0 to 9 and
specifies a grade.  The STRING is a time string as described in the
``time'' command.  If a call is placed to the other system during a
time which matches the time string, the remote system will be
requested to only run jobs of grade CHARACTER or higher.
Unfortunately, there is no way to guarantee that the other system will
obey the request (this UUCP package will, but there are other which
will not); moreover historically job grades are somewhat arbitrary so
specifying a grade will only be meaningful if the other system
cooperates in assigning grades.  This grade restriction only applies
when the other system is called, not when the other system calls in.

The ``call-timegrade'' command may be appear multiple times without
using ``alternate''.  If this command does not appear, the remote
system will be allowed to send whatever grades of work it chooses.

call-local-size NUMBER STRING

The STRING is a time string as described under the ``time'' command.
The NUMBER is the size in bytes of the largest file that should be
transferred at a time matching the time string if the local system
placed the call and the request was made by the local system.  The
size of a file requested from the remote system (as opposed to a file
sent to the remote system) will only be checked if the other system is
running this package (older UUCP code can not handle a maximum size
request).  This command may appear multiple times in a single
alternate.  If this command does not appear, there are no size
restrictions.

call-remote-size NUMBER STRING

Specify the size in bytes of the largest file that should be
transferred at a given time by remote request when the local system
placed the call.  This command may appear multiple times in a single
alternate.  If this command does not appear, there are no size
restrictions.

called-local-size NUMBER STRING

Specify the size in bytes of the largest file that should be
transferred at a given time by local request when the remote system
placed the call.  This command may appear multiple times in a single
alternate. If this command does not appear, there are no size
restrictions.

called-remote-size NUMBER STRING

Specify the size in bytes of the largest file that should be
transferred at a given time by remote request when the remote system
placed the call.  This command may appear multiple times in a single
alternate. If this command does not appear, there are no size
restrictions.

timetable STRING STRING

This is actually not specific to a system.  It can appear anywhere in
the file, and defines a timetable that may be used in subsequently
appearing time commands.  The first string names the timetable entry;
the second is a time string as described in the ``time'' command.

The following timetable commands are predefined (note that the NonPeak
timetable is for compatibility, and no longer has any particular
meaning):

	timetable Evening Wk1705-0755,Sa,Su
	timetable Night Wk2305-0755,Sa,Su2305-1655
	timetable NonPeak Wk1805-0655,Sa,Su

If this command does not appear, then obviously no additional
timetables will be defined.

[ The timetable command doesn't really belong here; perhaps it should
be in the general configuration file? ]

baud NUMBER

Specify the baud rate to use when calling the system.  This will try
all available ports with that baud rate until an unlocked port is
found.  The ports are defined in the port file.  If both the baud and
the port commands appear, the baud rate is used to open the port at a
specified baud.  To allow calls at more than one baud rate, the
``alternate'' command must be used.  If this command does not appear,
there is no default; the baud rate may be specified in the port file,
but if it is not the natural baud rate of the port will be used
(whatever that means on the system).

port STRING

Name a particular port to use when calling the system.  The
information for this port is obtained from the port file.  If this
command does not appear, there is no default; a port must somehow be
specified in order to call out (it may be specified implicitly using
the ``baud'' command or explicitly using the next version of
``port'').

port STRING ...

If more than one string follows the ``port'' command, the subsequent
strings are treated as commands that might appear in the port file
(see the description of the port file, below).  If a port is named (by
using a single string following ``port'') these commands are ignored;
their purpose is to permit specifying the port directly in simple
cases without having to make entries in two different files.  In order
to call out, a port must be specified using some version of the
``port'' command, or by using the ``baud'' command to select ports
from the port file.

phone STRING

Give a phone number to call.  A '=' character in the phone number
means to wait for a secondary dial tone (although only some modems
support this); a '-' character means to pause while dialing for 1
second (again, only some modems support this).  The ``phone'' command
is ignored for a non-modem port.  To use more than one phone number
the ``alternate'' command must be used.  This command must appear in
order to call out on a modem; there is no default.

chat STRINGS

Specify the chat script to use when calling the system.  The chat
script is a series of expect/send pairs.  The first expect may be "",
meaning to begin by sending.  The pairs are separated by blank space;
to include blank space in the string, an escape sequence must be used.
An expect string may include subsend and subexpect strings separated
by hyphens; if the expect string is not seen, the subsend string will
be sent and the next subexpect string will be searched for.  To
include a hyphen in an expect string, an escape sequence must be used.
A carriage return ('\r') is sent after each send string, unless \c
appears at the end.  A sample chat script appears below.  The
following escape sequences are defined in chat scripts:

	"" -- expect a null string (i.e. skip the expect phase)
	EOT -- send an end of transmission character (^D)
	BREAK -- send a break character (may not work on all systems)
	\b -- a backspace character ('\b')
	\c -- suppress trailing carriage return at end of send string
	\d -- delay sending for 1 second
	\K -- same as BREAK (for BNU compatibility)
	\n -- a newline character ('\n')
	\N -- a null character (for BNU compatibility)
	\p -- pause sending for a fraction of a second
	\r -- a carriage return character ('\r')
	\s -- a space character (' ')
	\t -- a tab character ('\t')
	\\ -- a slash character ('\\')
	\DDD -- character DDD, where DDD are up to three octal digits
	\xDDD -- character DDD, where DDD are hexadecimal digits.
	\L -- send the login name
	\P -- send the password

As in C, there may be up to three octal digits following a slash, but
the hexadecimal escape sequence continues as far as possible.  To
follow a hexadecimal escape sequence with a hex digit, use "" as the
next expect or send string (e.g. \x0d "" dave).

Note that in some versions of UUCP, \b denotes a break character.

The default chat script is:

	"" \r\c ogin:-BREAK-ogin:-BREAK-ogin: \L word: \P

Note that carriage return characters are sent after the break
characters, and after the login name and the password.

chat-timeout NUMBER

The number of seconds to wait for an expect string in the chat script
before timing out and sending the next subsend or failing the chat
script entirely.  The default value is 60.

call-login STRING

Specify the login name to send with \L in the chat script.  If the
string is "*" (e.g. ``call-login *'') the login name will be fetched
from the call out login name and password file.  There is no default.

call-password STRING

Specify the password to send with \P in the chat script.  If the
string is "*" (e.g. ``call-password *'') the password will be fetched
from the call-out login name and password file.  There is no default.

called-login STRING

Specify the login name that the system must use when calling in.  If
STRING is "ANY" (e.g. ``called-login ANY'') any login name may be used
(this is only useful to override a default specified in this file).
The case of STRING is significant.  The default value is "ANY".
Different alternates may use different ``called-login'' commands, in
which case the login name will be used to select which alternate is in
effect; this will only work if the first alternate (before the first
``alternate'' command) uses the ``called-login'' command.

callback BOOLEAN

If BOOLEAN is true, then when the remote system calls uucico will hang
up the connection and prepare to call it back.  This is off by default.

sequence BOOLEAN

If BOOLEAN is true, then conversation sequencing is automatically used
for the remote system, so that if somebody manages to spoof as the
remote system, it will be detected the next time the remote system
actually calls.  This is off by default.

protocols STRING

Specifies which protocols to use for the other system, and in which
order to use them.  This would not normally be used.  For example,
``protocols g''.  By default the set of protocols compiled into the
uucico daemon is used.

protocol-parameter CHARACTER STRING ...

CHARACTER is a single character specifying a protocol; the remaining
strings are a command specific to that protocol which will be executed
if that protocol is used.  The typical command will be something like
``window 7'', hence the name protocol-parameter.  The particular
commands are protocol specific.  Currently the 'g' protocol [ which is
the only one implemented anyhow ] supports ``window'',
``packet-size'', ``startup-retries'', ``init-retries'',
``init-timeout'', ``retries'', ``timeout'' and ``garbage'' all of
which take numeric arguments.

call-request BOOLEAN

The BOOLEAN indicates whether when the local system places the call it
may request file transfers (in either direction).  The default is yes.

called-request BOOLEAN

Whether when the other system places the call it may request file
transfers (in either direction).  The default is yes.

request BOOLEAN

Identical to ``call-request BOOLEAN\ncalled-request BOOLEAN.''

call-transfer BOOLEAN

Whether when the local system places the call it may do file transfers
queued up for the remote system.  The default is yes.

called-transfer BOOLEAN

Whether when the other system places the call the local system may do
queued up file transfers.  The default is yes.

transfer BOOLEAN

Identical to ``call-transfer BOOLEAN\ncalled-transfer BOOLEAN.''

local-send STRINGS

Specifies that files in the directories named by the STRINGS may be
sent to the remote system when requested locally (using uucp or uux).
The directories in the list should be separated by whitespace.  A ~
may be used for the public directory (on a UNIX system, this is
typically /var/spool/uucppublic; it may modified with ``pubdir'').
For example:

	local-send ~ /var/spool/ftp/pub

Listing a directory allows all files within the directory and all
subdirectories to be sent.  Directories may be excluded by preceding
them with an exclamation point.  For example:

	local-send /usr/ftp !/usr/ftp/private ~

means that all files in /usr/ftp or the public directory may be sent,
except those files in /usr/ftp/private.  The list of directories is
read from left to right, and the last directory to apply takes effect;
this means that directories should be listed from top down.  The
default is ~.

remote-send STRINGS

Specifies that files in the named directories may be sent to the
remote system when requested by the remote system.  The default is ~.

local-receive STRINGS

Specifies that files may be received into the named directories when
requested by a local user.  The default is ~.

remote-receive STRINGS

Specifies that files may be received into the named directories when
requested by the remote system.  The default is ~.

command-path STRING

Specifies the path (a list of whitespace separated directories) to be
searched to locate commands to execute.  The default is from the
system dependent header file.

commands STRINGS

The list of commands which the remote system is permitted to execute
locally.  For example: ``commands rnews rmail''.  If the value is
``ANY'' (case significant), any commands may be executed.  The default
is from the system dependent header file.

free-space NUMBER

Specify the minimum amount of file system space (in bytes) to leave
free when receiving a file.  If the incoming file will not fit, it
will be rejected.  This will only work when talking to another
instance of this package, since older UUCP packages do not provide the
file size of incoming files.  There is no provision for reserving
space, so it is still possible for multiple uucico daemons to use up
all available file space; a sufficiently large value for
``free-space'' will avoid this problem to some extent.  The default is
from the system dependent header file.  Not all systems may be able to
provide the amount of available space.

pubdir STRING

Specifies the public directory that is used when ~ is specifed in a
file transfer or a list of directories.  This essentially overrides
the public directory specified in the main configuration file for this
system only.  The default is the public directory specified in the
main configuration file.

myname STRING

Specifies the system name to use when calling the remote system.
Also, if ``called-login'' is used and is not "ANY", then when a system
logs in with the specified login name STRING is used as the system
name (because the local system name must be determined before the
remote system has identified itself, using ``myname'' and
``called-login'' together for any system will set the local name for
that login; this means that each locally used system name must have a
unique login name associated with it).  This allows a system to have
different names for an external and an internal network.  The default
is not use to a special local name.


The following are used as default values for all systems; they can be
considered as appearing before the start of the file.

	timetable Evening Wk1705-0755,Sa,Su
	timetable Night Wk2305-0755,Sa,Su2305-1655
	timetable NonPeak Wk1805-0655,Sa,Su
	time Never
	chat "" \r\c ogin:-BREAK-ogin:-BREAK-ogin: \L word: \P
	chat-timeout 60
	callback n
	sequence n
	request y
	transfer y
	local-send ~
	remote-send ~
	local-receive ~
	remove-receive ~
	command-path [ system dependent ]
	commands rnews rmail

*** The port configuration file

The port file may be used to name and describe ports.  The first
command in the file must be ``port''.  All command up to the next
``port'' command then describe that port.  There are different types
of ports, and each type supports its own set of commands.  Each
command indicates which types of ports support it.

port STRING

Introduces and names a port.

type STRING

Define the type of port.  The default is ``modem''.  If this command
appears, it must immediately follow the port command.  The type
defines what commands are subsequently allowed.  Currently the types
``modem'' (for a modem hookup), ``stdin'' (for a connection through
stdin and stdout, as when uucico is run as a login shell) and
``direct'' (for a direct connection to another system) are defined.
[ In the future types ``tcp'' and ``ftp'' should be added.  The type
``ftp'' should allow use of uucp to perform FTP transfers, which would
be convenient to do the transfers late at night, for example. ]

device STRING [ modem and direct only ]

Names the device associated with this port.  If the device is not
named, the port name is taken as the device.  Device names are system
dependent, but a Unix example would be /dev/ttyd0.

baud NUMBER [ modem and direct only ]

The baud rate this port runs at.  If a system specifies a baud rate
but no port name, then all ports which match the baud rate will be
tried in order.  If the baud rate is not specified here and is not
specified by the system, the natural baud rate of the port will be
used by default.

carrier BOOLEAN [ modem only ]

If the argument is TRUE, then after dialing the phone number uucico
will wait for carrier to come on.  This is only supported on a few
systems.  If the argument is FALSE, soft carrier is forced if the
system supports it.  The default is FALSE.

carrier-wait NUMBER [ modem only ]

If the port is supposed to wait for carrier, this may be used to
indicate how many seconds to wait.  The default is 60 seconds.

dial-device STRING [ modem only ]

Dialing instructions should be output to the named device, rather than
to the normal port device.  The default is to output to the normal
port device.

protocol-parameter CHARACTER STRINGS [ any type ]

The same command as the protocol-parameter command used for systems.
This one takes precedence.

dialer STRING [ modem only ]

Name a dialer to use.  The information is looked up in the dialer
file.  There is no default, and some sort of dialer information must
be specified to call out on a modem.

dialer STRING ... [ modem only ]

Execute a dialer command.  If a dialer is named, these commands are
ignored.  They may be used to specify dialer information directly in
simple situations without needing to go to a separate file.  There is
no default, and some sort of dialer information must be specified to
call out on a modem.

*** The dialer configuration file

The dialer configuration file defines dialers.  The first command in
the file must be a ``dialer'' command which names the dialer.
Subsequent commands up to the next ``dialer'' command are associated
with the named dialer.

dialer STRING

Introduces and names a dialer.

chat STRINGS

A set of expect/send pairs, just like a login script, used to dial the
phone.  All the escape sequences defined for the login script may be
used (except for \L and \P) and the following escape sequences may
also be used:

	\D -- send phone number without dialcode translation
	\e -- disable echo checking on send
	\E -- enable echo checking (wait for echo before continuing)
	\T -- send phone number with dialcode translation

When echo checking is enabled then after writing each character to the
dialer the program will wait until the character is echoed.  There is
no default.

chat-timeout NUMBER

The number of seconds to wait for an expect string in the chat script
before timing out and sending the next subsend or failing the chat
script entirely.  The default is 60.

dialtone STRING

A string to output when dialing the phone number which causes the
modem to wait for a secondary dial tone.  This is used to translate
the '=' character in a phone number.  If it is not defined, the '='
character is dropped.

pause STRING

A string to output when dialing the phone number which causes the
modem to wait for 1 second.  This is used to translate the '-'
character in a phone number.  If it is not defined, the '-' character
is dropped.

dtr-toggle BOOLEAN BOOLEAN

If the first argument is TRUE, then DTR is toggled before using the
modem.  This is only supported on some systems and some ports.  The
second BOOLEAN need not be present; if it is, and it is TRUE, the
program will sleep for 1 second after toggling DTR.  The default is
not to toggle DTR.

complete STRING

When the call is finished normally, STRING is sent to the modem.  The
string may contain escape sequences just as a send string in a chat
script.  The default is to send nothing on completion.

abort STRING

If the call is somehow aborted, STRING is sent to the modem.  If this
is not defined, the dialer complete string is sent instead.  The
string may contain escape sequences just as a send string in a chat
script.  The default is to send nothing when the program is aborted.

protocol-parameter CHARACTER STRINGS

Set protocol parameters, as the similar command in the system
configuration file or the port configuration file.  These parameters
take precedence, then those for the port, then those for the system.
[ Currently these only take effect when dialing out, not when
accepting a call ]

*** Brief example

Here is the main configuration file and the system configuration file
actually used here to call uunet.  There is also a call out password
file which, for obvious reasons, is not shown.

The main configuration file (this would be needed if the local name of
this system were airs or airs.airs.com):

nodename airs

The system configuration file (this controls a Telebit 2500 which
calls uunet; uunet tends to have slow response time, so the timeouts
are forced to higher values; the window and packet sizes used for the
'g' protocol are the defaults anyhow, and are the correct values to
trigger Telebit UUCP spoofing).

system uunet
call-login *
call-password *
time night
phone 7389449
chat-timeout 120
port type modem
port device /dev/ttyd0
port baud 19200
port carrier true
port dialer chat "" ATZ\r\d\c OK ATDT\D
port dialer complete \d\d+++\d\dATH\r\c
port dialer abort \d\d+++\d\dATH\r\c
protocol-parameter g window 3
protocol-parameter g packet-size 64
protocol-parameter g timeout 20
protocol-parameter g retries 10
-- 
Ian Taylor | ian@airs.com | First to identify quote wins free e-mail message:
``Learning is not like a coin, which remains physically whole even through
  the most infamous transactions; it is, rather, like a very handsome dress,
  which is worn out through use and ostentation.''



>From ian@airs.com Tue Feb 25 00:09:03 1992
Path: uunet!uunet!airs!ian
From: ian@airs.com (Ian Lance Taylor)
Newsgroups: comp.mail.uucp
Subject: Frequently Asked Questions about UUCP internals
Keywords: FAQ, protocols
Message-ID: <3640@airs.com>
Date: 25 Feb 92 05:09:03 GMT
Sender: news@airs.com
Lines: 773
Status: OR

Here is a FAQ posting that I have worked up.  It is intended to answer
most questions about how UUCP works, what the UUCP protocols are,
etc., in nauseating detail.  It does not answer such useful questions
as how to configure UUCP, how to make an X.25 PAD not trap ^P, etc.,
and other questions for which I am not necessarily qualified to
provide answers.  Let this posting serve as a challenge to other
people to produce more FAQ answers, which can either be folded into
this posting, or, more likely, form a separate posting.

This is the first trial of this posting.  I'll consider any comments,
make a relatively final version, and start posting it every month.
Enjoy!

Frequently Asked Questions about UUCP internals
Last updated 1992-02-25

This article was written by Ian Lance Taylor <ian@airs.com> and I may
even update it periodically.  Send me mail about suggestions or
inaccuracies.

This article describes how the various UUCP protocols work.  It does
not describe how to configure UUCP, nor how to solve UUCP problems,
nor how to deal with UUCP mail.  There are currently no FAQ postings
on any of these topics, and I do not plan to write any.

If you haven't read the news.announce.newusers articles, read them.

I took a lot of the information from Jamie E. Hanrahan's paper in the
Fall 1990 DECUS Symposium, and from Managing UUCP and Usenet by Tim
O'Reilly and Grace Todino (with contributions by several other
people).  The latter includes most of the former, and is published by
	O'Reilly & Associates, Inc.
	632 Petaluma Avenua
	Sebastopol, CA 95472
It is currently in its tenth edition.  The ISBN number is
0-937175-48-X.

Some information is originally due to a Usenet article by Chuck
Wegrzyn.  The information on the 'g' protocol comes partially from a
paper by G.L. Chesson of Bell Laboratories, partially from Jamie E.
Hanrahan's paper, and partially from source code by John Gilmore.  The
information on the 'f' protocol comes from the source code by Piet
Berteema.  The information on the 't' protocol comes from the source
code by Rick Adams.  The information on the 'e' protocol comes from a
Usenet article by Matthias Urlichs.

This article answers the following questions.  If one of these
questions is posted to comp.mail.uucp, you are encouraged to send mail
to the poster referring her or him to this FAQ.  There is no reason to
post a followup, as most of us know the answer already.

*) What is the UUCP protocol?
*) What is the 'g' protocol?
*) What is the 'f' protocol?
*) What is the 't' protocol?
*) What is the 'e' protocol?
*) What is the 'x' protocol?

*) What is the UUCP protocol?

The UUCP protocol is a conversation between two UUCP packages.  A UUCP
conversation consists of three parts: an initial handshake, a series
of file transfer requests, and a final handshake.

Before the initial handshake, the caller will usually have logged in
the called machine and somehow started the UUCP package there.  On
Unix this is normally done by setting the shell of the login name used
to /usr/lib/uucp/uucico.

All messages in the initial handshake begin with a ^P (a byte with the
octal value \020) and end with a null byte (\000).

The initial handshake goes as follows.  It is begun by the called
machine.

called: \020Shere=hostname\000
    The hostname is the UUCP name of the called machine.  Older UUCP
    packages do not output it, and simply send \020Shere\000.

caller: \020Shostname options\000
    The hostname is the UUCP name of the calling machine.  The
    following options may appear (or there may be none):
        -QSEQ
            Report sequence number for this conversation.  The
            sequence number is stored at both sites, and incremented
            after each call.  If there is a sequence number mismatch,
            something has gone wrong (somebody may have broken
            security by pretending to be one of the machines) and the
            call is denied.
        -xLEVEL
            Requests the called system to set its debugging level to
            the specified value.  This is not supported by all
            systems.
        -pGRADE
        -vgrade=GRADE
            Requests the called system to only transfer files of the
            specified grade or higher.  This is not supported by all
            systems.  Some systems support -p, some support -vgrade=.
        -R
            Indicates that the calling UUCP understands how to restart
            failed file transmissions.  Supported only by System V
            Release 4 UUCP.
        -ULIMIT
            Reports the ulimit value of the calling UUCP.  The limit
            is specified as a base 16 number in C notation (e.g.
            -U0x1000000).  This number is the number of 512 byte
            blocks in the largest file which the calling UUCP can
            create.  The called UUCP may not transfer a file larger
            than this.  Supported only by System V Release 4 UUCP.
        -N
            Indicates that the calling UUCP understands the Taylor
            UUCP size limiting extensions.  Supported only by Taylor
            UUCP.

called: \020ROK\000
    There are actually several possible responses.
        ROK
            The calling UUCP is acceptable, and the handshake proceeds
            to the protocol negotiation.  Some options may also
            appear; see below.
        ROKN
            The calling UUCP is acceptable, it specified -N, and the
            called UUCP understands the Taylor UUCP size limiting
            extensions.  Supported only by Taylor UUCP.
        RLCK
            The called UUCP already has a lock for the calling UUCP,
            which normally indicates the two machines are already
            communicating.
        RCB
            The called UUCP will call back.  This may be used to avoid
            impostors (but only one machine out of each pair should
            call back, or no conversation will ever begin).
        RBADSEQ
            The call sequence number is wrong (see the -Q discussion
            above). 
        RLOGIN
            The calling UUCP is using the wrong login name.
        RYou are unknown to me
            The calling UUCP is not known to the called UUCP, and the
            called UUCP does not permit connections from unknown
            systems.
    If the response is ROK, the following options are supported by
    System V Release 4 UUCP.
        -R
            The called UUCP knows how to restart failed file
            transmissions.
        -ULIMIT
            Reports the ulimit value of the called UUCP.  The limit is
            specified as a base 16 number in C notation.  This number
            is the number of 512 byte blocks in the largest file which
            the called UUCP can create.  The calling UUCP may not send
            a file larger than this.
        -xLEVEL
            I'm not sure about this one.  It may request the calling
            UUCP to set its debugging level to the specified value.
    If the response is not ROK (or ROKN) both sides hang up the phone,
    abandoning the call.

called: \020Pprotocols\000
    Note that the called UUCP outputs two strings in a row.  The
    protocols string is a list of UUCP protocols supported by the
    caller.  Each UUCP protocol has a single character name.  These
    protocols are discussed in more detail later in this document.
    For example, the called UUCP might send \020Pgf\000.

caller: \020Uprotocol\000
    The calling UUCP selects which protocol to use out of the
    protocols offered by the called UUCP.  If there are no mutually
    supported protocols, the calling UUCP sends \020UN\000 and both
    sides hang up the phone.  Otherwise the calling UUCP sends
    something like \020Ug\000.

At this point the initial handshake has been completed, and both sides
turn on the selected protocol.  For some protocols (notably 'g') a
further handshake is done at this point.

Each protocol supports a method for sending a command to the remote
system.  This method is used to transmit a series of commands between
the two UUCP packages.  At all times, one package is the master and
the other is the slave.  Initially, the calling UUCP is the master.

If a protocol error occurs during the exchange of commands, both sides
move immediately to the final handshake.

The master will send one of four commands: S, R, X or H.

Any file name referred to below is either an absolute pathname
beginning with "/", a public directory pathname beginning with "~/", a
pathname relative to a user's home directory beginning with "~USER/",
or a spool directory file name.  File names in the spool directory are
not pathnames, but instead are converted to pathnames within the spool
directory by UUCP.  They always begin with "C." (for a command file
created by uucp or uux), "D." (for a data file created by uucp, uux or
by an execution, or received from another system for an execution), or
"X." (for an execution file created by uux or received from another
system).

master: S FROM TO USER -OPTIONS TEMP MODE NOTIFY SIZE
    The S and the - are literal characters.  This is a request by the
    master to send a file to the slave.
        FROM
            The name of the file to send.  If the C option does not
            appear in OPTIONS, the master will actually open and send
            this file.  Otherwise the file has been copied to the
            spool directory, where it is named TEMP.  The slave
            ignores this field unless TO is a directory, in which case
            the basename of FROM will be used as the file name.  If
    	    FROM is a spool directory filename, it must be a data file
    	    created for or by an execution, and must begin with "D.".
        TO
            The name to give the file on the slave.  If this field
            names a directory (a name ending in '/' is taken to name a
            directory even if one does not already exist with that
            name) the file is placed within that directory with the
            basename of FROM.  If TO begins with "X.", an execution
    	    file will be created on the slave.  Otherwise, if TO
    	    begins with "D." it names a data file to be used by some
    	    execution file.  Otherwise, TO may not be in the spool
    	    directory.
        USER
    	    The name of the user who requested the transfer.
    	OPTIONS
    	    A list of options to control the transfer.  The following
            options are defined (all options are single characters):
    	    	C
    	    	    The file has been copied to the spool directory
            	    (the master should use TEMP rather than FROM).
    	    	c
    	    	    The file has not been copied to the spool
            	    directory (this is the default).
    	    	d
    	    	    The slave should create directories as necessary
            	    (this is the default).
    	    	f
    	    	    The slave should not create directories if
            	    necessary, but should fail the transfer instead.
    	    	m
    	    	    The master should send mail to USER when the
            	    transfer is complete.
    	    	n
    	    	    The slave should send mail to NOTIFY when the
            	    transfer is complete.
    	TEMP
    	    If the C option appears in OPTIONS, this names the file to
    	    be sent.  Otherwise if FROM is in the spool directory,
    	    TEMP is the same as FROM.  Otherwise TEMP is a dummy
    	    string, normally "D.0".  After the transfer has been
    	    succesfully completed, the master will delete the file
    	    TEMP.
    	MODE
    	    This is an octal number giving the mode of the file on
    	    MASTER.  If the file is not in the spool directory, the
    	    slave will always create it with mode 0666, except that if
    	    (MODE & 0111) is not zero (the file is executable), the
    	    slave will create the file with mode 0777.  If the file is
    	    in the spool directory, some UUCP packages will use the
    	    algorithm above and some will always create the file with
    	    mode 0600.
    	NOTIFY
    	    This field is only present if the n option appears in
    	    OPTIONS.  When the transfer is successfully completed, the
    	    slave will send mail to NOTIFY, which must be a legal
    	    mailing address on the slave.  If a SIZE field will appear
    	    but the n option does not appear, NOTIFY will be the
    	    string "dummy" or simply a pair of double quotes.
    	SIZE
    	    This field is only present when doing size negotiation,
    	    either with Taylor UUCP or SVR4 UUCP.  It is the size of
    	    the file in bytes.  SVR4 UUCP sends the size in base 16 as
    	    0x.... while Taylor UUCP sends the size as a decimal
    	    integer.

    The slave then responds with an S command response.
    	SY START
    	    The slave is willing to accept the file, and file transfer
    	    begins.  The START field will only be present when using
    	    SVR4 file restart.  It specifies the byte offset into the
    	    file at which to start sending.  If this is a new file,
    	    START will be 0x0.
    	SN2
    	    The slave denies permission to transfer the file.  This
    	    can mean that the destination directory may not be
    	    accessed, or that no requests are permitted.  It implies
    	    that the file transfer will never succeed.
    	SN4
    	    The slave is unable to create the necessary temporary
    	    file.  This implies that the file transfer may succeed
    	    later.
    	SN6
    	    This is only used by Taylor UUCP size negotiation.  It
    	    means that the slave considers the file too large to
    	    transfer at the moment, but it may be possible to transfer
    	    it at some other time.
    	SN7
    	    This is only used by Taylor UUCP size negotiation.  It
    	    means that the slave considers the file too large to ever
    	    transfer.

    If the slave responds with SY, a file transfer begins.  When the
    file transfer is complete, the slave sends a C command response.
    	CY
    	    The file transfer was successful.
    	CN5
    	    The temporary file could not be moved into the final
    	    location.  This implies that the file transfer will never
    	    succeed.

    After the C command response has been received (in the SY case) or
    immediately (in an SN case) the master will send another command.

master: R FROM TO USER -OPTIONS SIZE
    The R and the - are literal characters.  This is a request by the
    master to receive a file from the slave.  I do not know how SVR4
    UUCP implements file transfer restart in this case.
    	FROM
    	    This is the name of the file on the slave which the master
    	    wishes to receive.  It must not be in the spool directory,
    	    and it may not contain any wildcards.
    	TO
    	    This is the name of the file to create on the master.  I
    	    do not believe that it can be a directory.  It may only be
    	    in the spool directory if this file is being requested to
    	    support an execution either on the master or on some
    	    system other than the slave.
    	USER
    	    The name of the user who requested the transfer.
    	OPTIONS
    	    A list of options to control the transfer.  The following
            options are defined (all options are single characters):
    	    	d
    	    	    The master should create directories as necessary
            	    (this is the default).
    	    	f
    	    	    The master should not create directories if
            	    necessary, but should fail the transfer instead.
    	    	m
    	    	    The master should send mail to USER when the
            	    transfer is complete.
    	SIZE
    	    This only appears if Taylor UUCP size negotiation is being
    	    used.  It specifies the largest file which the master is
    	    prepared to accept (when using SVR4 UUCP, this was
    	    specified in the -U option during the initial handshake).

    The slave then responds with an R command response.
    	RY MODE
    	    The slave is willing to send the file, and file transfer
    	    begins.  MODE is the octal mode of the file on the slave.
    	    The master treats this just as the slave does the MODE
    	    argument in the send command, q.v.
    	RN2
    	    The slave is not willing to send the file, either because
    	    it is not permitted or because the file does not exist.
    	    This implies that the file request will never succeed.
    	RN6
    	    This is only used by Taylor UUCP size negotiation.  It
    	    means that the file is too large to send, either because
    	    of the size limit specifies by the master or because the
    	    slave considers it too large.  The file transfer may
    	    succeed later, or it may not (this will be cleared up in a
    	    later release of Taylor UUCP).

    If the slave responds with RY, a file transfer begins.  When the
    file transfer is complete, the master sends a C command.  The
    slave pretty much ignores this, although it may log it.
    	CY
    	    The file transfer was successful.
    	CN5
    	    The temporary file could not be moved into the final
    	    location.

    After the C command response has been sent (in the RY case) or
    immediately (in an RN case) the master will send another command.

master: X FROM TO USER -OPTIONS
    The X and the - are literal characters.  This is a request by the
    master to, in essence, execute uucp on the slave.  The slave
    should execute "uucp FROM TO".
    	FROM
    	    This is the name of the file or files on the slave which
    	    the master wishes to transfer.  It will often contain
    	    wildcard characters, since otherwise an R command will
    	    normally suffice (however, this command can also be used
    	    to request the transfer of a file on the slave to a third
    	    system).  Any wildcards should be expanded on the slave.
    	TO
    	    This is the name of the file or directory to which the
    	    files should be transferred.  This will normally use a
    	    UUCP name.  For example, if the master wishes to receive
    	    the files itself, it would use "master!path".
    	USER
    	    The name of the user who requested the transfer.
    	OPTIONS
    	    A list of options to control the transfer.  It is not
    	    clear which, if any, options are supported by most UUCP
    	    packages.

    The slave then responds with an X command response.
    	XY
    	    The request was accepted, and the appropriate file
   	    transfer commands have been queued up for later
   	    processing.
    	XN
    	    The request was denied.  No particular reason is given.

    In either case, the master will then send another command.

master: H
    This is used by the master to hang up the connection.  The slave
    will respond with an H command response.
    	HY
    	    The slave agrees to hang up the connection.  In this case
    	    the master sends another HY command.  In some UUCP
    	    packages the slave will then send a third HY command.  At
    	    this point the protocol is shut down, and the final
    	    handshake is begun.
    	HN
    	    The slave does not agree to hang up.  In this case the
    	    master and the slave exchange roles.  The next command
    	    will be sent by the former slave, which is the new master.
    	    The roles may be reversed several times during a single
    	    connection.

After the protocol has been shut down, the final handshake is
performed.  This handshake has no real purpose, and some UUCP packages
simply drop the connection rather than do it (in fact, some will drop
the connection immediately after both sides agree to hangup, without
even closing down the protocl).

caller: \020OOOOOO\000
called: \020OOOOOOO\000

That is, the calling UUCP sends six O's and the called UUCP replies
with seven O's.  Some UUCP packages always send six O's.

*) What is the 'g' protocol?

The 'g' protocol is a packet based flow controlled error correcting
protocol that requires an eight bit clear connection.  It is the
original UUCP protocol, and is supported by all UUCP implementations.
Many implementations of it are only able to support small window and
packet sizes, specifically a window size of 3 and a packet size of 64
bytes, but the protocol itself can support up to a window size of 7
and a packet size of 4096 bytes.  Complaints about the inefficiency of
the 'g' protocol generally refer to specific implementations, rather
than the correctly implemented protocol.

The 'g' protocol was originally designed for general packet drivers,
and thus contains some features that are not used by UUCP, including
an alternate data channel and the ability to renegotiate packet and
window sizes during the communication session.

The 'g' protocol is spoofed by many Telebit modems.  When spoofing is
in effect, each Telebit modem uses the 'g' protocol to communicate
with the attached computer, but the data between the modems is sent
using a Telebit proprietary error correcting protocol.  This allows
for very high throughput over the Telebit connection, which, because
it is half-duplex, would not normally be able to handle the 'g'
protocol very well at all.

This discussion of the 'g' protocol explains how it works, but does
not discuss useful error handling techniques.  Some discussion of this
can be found in Jamie E. Hanrahan's paper, cited above.

All 'g' protocol communication is done with packets.  Each packet
begins with a six byte header.  Control packets consist only of the
header.  Data packets contain additional data.

The header is as follows:

    \020
    	Every packet begins with a ^P.
    k (1 <= k <= 9)
    	The k value is always 9 for a control packet.  For a data
    	packet, the k value indicates how must data follows the six
    	byte header.  The amount of data is 2 ** (k + 4), where **
    	indicates exponentiation.  Thus a k value of 1 means 32 data
    	bytes and a k value of 8 means 4096 data bytes.  The k value
    	for a data packet must be between 1 and 8 inclusive.
    checksum low byte
    checksum high byte
    	The checksum value is described below.
    control byte
    	The control packet indicates the type of packet, and is
    	described below.
    xor byte
    	This byte is the xor of k, the checksum low byte, the checksum
    	high byte and the control byte (i.e. the second, third, fourth
    	and fifth header bytes).  It is used to ensure that the header
    	data is valid.

The control byte in the header is composed of three bit fields,
referred to here as TT (two bits), XXX (three bits) and YYY (three
bits).  The control is TTXXXYYY, or (TT << 6) + (XXX << 3) + YYY.

The TT field takes on the following values:
    0
    	This is a control packet.  In this case the k byte in the
    	header must be 9.  The XXX field indicates the type of control
    	packet; these types are described below.
    1
    	This is an alternate data channel packet.  This is not used by
    	UUCP.
    2
    	This is a data packet, and the entire contents of the attached
    	data field (whose length is given by the k byte in the header)
    	are valid.  The XXX and YYY fields are described below.
    3
    	This is a short data packet.  Let the length of the data field
    	(as given by the k byte in the header) be L.  Let the first
    	byte in the data field be B1.  If B1 is less than 128 (if the
    	most significant bit of B1 is 0), then there are L - B1 valid
    	bytes of data in the data field, beginning with the second
    	byte.  If B1 >= 128, let B2 be the second byte in the data
    	field.  Then there are L - ((B1 & 0x7f) + (B2 << 7)) valid
    	bytes of data in the data field, beginning with the third
    	byte.  In all cases L bytes of data are sent (and all data
    	bytes participate in the checksum calculation) but some of the
    	trailing bytes may be dropped by the receiver.   The XXX and
    	YYY fields are described below.

In a data packet (short or not) the XXX field gives the sequence
number of the packet.  Thus sequence numbers can range from 0 to 7,
inclusive.  The YYY field gives the sequence number of the last
correctly received packet.

Each communication direction uses a window which indicates how many
unacknowledged packets may be transmitted before waiting for an
acknowledgement (the window may be different in each direction).  The
window may range from 1 to 7. For example, if the window is 3 and the
last packet acknowledged was packet number 6, packet numbers 7, 0 and
1 may be sent but the sender must wait for an acknowledgement before
sending packet number 2.  This acknowledgement could come as the YYY
field of a data packet or as the YYY field of a RJ or RR control
packet (described below).

Each packet must be transmitted in order (the sender may not skip
sequence numbers).  Each packet must be acknowledged, and each packet
must be acknowledged in order.

In a control packet, the XXX field takes on the following values:
    1 CLOSE
    	The connection should be closed immediately.  This is
    	typically sent when one side has seen too many errors and
    	wants to give up.  It is also sent when shutting down the
    	protocol.  If an unexpected CLOSE packet is received, a CLOSE
    	packet should be sent and the 'g' protocol should halt,
    	causing UUCP to enter the final handshake.
    2 RJ or NAK
    	The last packet was not received correctly.  The YYY field
    	contains the sequence number of the last correctly received
    	packet.
    3 SRJ
    	Selective reject.  The YYY field contains the sequence number
    	of a packet that was not received correctly, and should be
    	retransmitted.  This is not used by UUCP, and most
    	implementations will not recognize it.
    4 RR or ACK
    	Packet acknowledgement.  The YYY field contains the sequence
    	number of the last correctly received packet.
    5 INITC
    	Third initialization packet.  The YYY field contains the
    	maximum window size to use.
    6 INITB
    	Second initialization packet.  The YYY field contains the
    	packet size to use.  It requests a size of 2 ** (YYY + 5);
    	note that this is not the same coding used for the k byte in
    	the packet header (it is 1 less).  Some UUCP implementations
    	can handle any packet size up to that specified; some can only
    	handled exactly the size specified.
    7 INITA
    	First initialization packet.  The YYY field contains the
    	maximum window size to use.

The checksum of a control packet is simply 0xaaaa - the control byte.

The checksum of a data packet is 0xaaaa - (CHECK ^ the control byte),
where ^ denotes exclusive or, and CHECK is the result of the following
routine as run on the contents of the data field (every byte in the
data field participates in the checksum, even for a short data
packet).  This is the routine used by Taylor UUCP, and is a slightly
modified version of a routine which John Gilmore patched from G.L.
Chesson's original paper.  The z argument points to the data and the c
argument indicates how much data there is.

int
igchecksum (z, c)
     register const char *z;
     register int c;
{
  register unsigned int ichk1, ichk2;

  ichk1 = 0xffff;
  ichk2 = 0;

  do
    {
      register unsigned int b;

      /* Rotate ichk1 left.  */
      if ((ichk1 & 0x8000) == 0)
	ichk1 <<= 1;
      else
	{
	  ichk1 <<= 1;
	  ++ichk1;
	}

      /* Add the next character to ichk1.  */
      b = *z++ & 0xff;
      ichk1 += b;

      /* Add ichk1 xor the character position in the buffer counting from
	 the back to ichk2.  */
      ichk2 += ichk1 ^ c;

      /* If the character was zero, or adding it to ichk1 caused an
	 overflow, xor ichk2 to ichk1.  */
      if (b == 0 || (ichk1 & 0xffff) < b)
	ichk1 ^= ichk2;
    }
  while (--c > 0);

  return ichk1 & 0xffff;
}

When the 'g' protocol is started, the calling UUCP sends an INITA
control packet with the window size it wishes the called UUCP to use.
The called UUCP responds with an INITA packet with the window size it
wishes the calling UUCP to use.  Pairs of INITB and INITC packets are
then similarly exchanged.  When these exchanges are completed, the
protocol is considered to have been started.

When a UUCP package transmits a command, it sends one or more data
packets.  All the data packets will normally be complete, although
some UUCP packages may send a the last one as a short packet.  The
UUCP package receiving the command will know when the command has
finished because it will be terminated by a null byte sent as data.
Some UUCP packages require the last byte of the last packet sent to be
null, even if the command ends earlier in the packet.  Some packages
may require all the trailing bytes in the last packet to be null, but
I have not confirmed this.

When a UUCP package sends a file, it will send a sequence of data
packets.  The end of the file is signalled by a short data packet
containing zero valid bytes (it will normally be preceeded by a short
data packet containing the last few bytes in the file).

Note that the sequence numbers cover the entire communication session,
including both command and file data.

When the protocol is shut down, each UUCP package sends a CLOSE
control packet.

*) What is the 'f' protocol?

The 'f' protocol is a seven bit protocol which checksums an entire
file at a time.  It only uses the characters between \040 and \176
(ASCII space and ~) inclusive as well as the carriage return
character.  It can be very efficient for transferring text only data,
but it is very inefficient at transferring eight bit data (such as
compressed news).  It is not flow controlled, and the checksum is
fairly insecure over large files, so using it over a serial connection
requires handshaking (XON/XOFF can be used) and error correcting
modems.  Some people think it should not be used even under those
circumstances.

I believe the 'f' protocol originated in BSD versions of UUCP.  It was
originally intended for transmission over X.25 PAD links.

The 'f' protocol has no startup or finish protocol.  However, both
sides should sleep for a couple of seconds before starting up, because
typically they will switch the terminal into XON/XOFF mode and want to
allow the changes to settle before beginning transmission.

When a UUCP package transmits a command, it simply sends a string
terminated by a carriage return.

When a UUCP package transmits a file, each byte b of the file is
translated according to the following table:

       0 <= b <=  037: 0172, b + 0100 (0100 to 0137)
     040 <= b <= 0171:       b        ( 040 to 0171)
    0172 <= b <= 0177: 0173, b - 0100 ( 072 to  077)
    0200 <= b <= 0237: 0174, b - 0100 (0100 to 0137)
    0240 <= b <= 0371: 0175, b - 0200 ( 040 to 0171)
    0372 <= b <= 0377: 0176, b - 0300 ( 072 to  077)

That is, a byte between \040 and \171 inclusive is transmitted as is,
and all other bytes are prefixed and modified as shown.

When all the file data is sent, a seven byte sequence is sent: two
bytes of \176 followed by four ASCII bytes of the checksum as printed
in base 16 followed by a carriage return.  For example, if the
checksum was 0x1234, this would be sent: "\176\1761234\r".

The checksum is initialized to 0xffff.  For each byte that is sent it
is modified as follows (where b is the byte before it has been
transformed as described above):

      /* Rotate the checksum left.  */
      if ((ichk & 0x8000) == 0)
	ichk <<= 1;
      else
	{
	  ichk <<= 1;
	  ++ichk;
	}

      /* Add the next byte into the checksum.  */
      ichk += b;

When the receiving UUCP sees the checksum, it compares it against its
own calculated checksum and replies with a single character followed
by a carriage return.
    G
    	The file was received correctly.
    R
    	The checksum did not match, and the file should be resent from
    	the beginning.
    Q
    	The checksum did not match, but too many retries have occurred
    	and the communication session should be abandoned.

The sending UUCP checks the returned character and acts accordingly.

*) What is the 't' protocol?

The 't' protocol is intended for TCP links.  It does no error checking
or flow control, and requires an eight bit clear channel.

I believe the 't' protocol originated in BSD versions of UUCP.

When a UUCP package transmits a command, it first gets the length of
the command string, C.  It then sends ((C / 512) + 1) * 512 bytes (the
smallest multiple of 512 which can hold C bytes plus a null byte)
consisting of the command string itself followed by trailing null
bytes.

When a UUCP package sends a file, it sends it in blocks.  Each block
contains at most 1024 bytes of data.  Each block consists of four
bytes containing the amount of data in binary (most significant byte
first, the same format as used by the Unix function htonl) followed by
that amount of data.  The end of the file is signalled by a block
containing zero bytes of data.

*) What is the 'e' protocol?

The 'e' protocol is similar to the 't' protocol.  It does no flow
control or error checking and is intended for use over TCP.

The 'e' protocol originated in versions of HDB UUCP.

When a UUCP package transmits a command, it simply sends the command
as an ASCII string terminated by a null byte.

When a UUCP package transmits a file, it sends the complete size of
the file as an ASCII decimal number.  The ASCII string is padded out
to 20 bytes with null bytes (i.e. if the file is 1000 bytes long, it
sends "1000\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0").  It then sends the
entire file.

*) What is the 'x' protocol?

I believe that the 'x' protocol was intended for use over X.25 virtual
circuits.  It relies on a write of zero bytes being read as zero bytes
without stopping communication.  I have heard that it does not work
correctly.  If someone would care to fill this in more, I would be
grateful.
-- 
Ian Taylor                  ian@airs.com                  uunet!airs!ian
First person to identify this quote wins a free e-mail message:
``The will to be stupid is a very powerful force.''



From rick Thu Mar 19 12:16:25 1992
Received: by rodan.UU.NET (5.61/UUNET-mail-drop)
	id AA21918; Thu, 19 Mar 92 12:16:24 -0500
From: rick (Rick Adams)
Message-Id: <9203191716.AA21918@rodan.UU.NET>
Subject: dialer daemon stuff (fwd)
To: piers (Piers Lauder)
Date: Thu, 19 Mar 92 12:16:23 EST
X-Mailer: ELM [version 2.3 PL10]
Status: OR

This is the model we have been talking about for years for
uucp (and other) dialouts)

--rick

Forwarded message:
> From bostic@vangogh.CS.Berkeley.EDU Wed Mar 18 20:50:35 1992
> Date: Wed, 18 Mar 92 17:49:57 -0800
> From: bostic@vangogh.CS.Berkeley.EDU (Keith Bostic)
> Message-Id: <9203190149.AA14223@vangogh.CS.Berkeley.EDU>
> To: rick@uunet.UU.NET
> Subject: dialer daemon stuff
> 
> From: Benson I. Margulies <benson@odi.com>
> Date: Fri, 05 Jan 90 08:11:59 -0500
> 
> 
>     Good question, I'm not real sure...  I guess I'd be the first person
>     to talk to.  There are two peripheral issues that muddy the waters,
>     somewhat.  The first would be we want to create a dialer daemon that
>     uucp/tip/cu/whatever connect to whenever they want to dial out.  This
>     would be a major win.  We have preliminary code, if you'd be interested
>     in making it all work, we'd be greatly indebted.  The second issue is
>     dial-up ip.  I expect it to be separate from tip, but I'm not sure if
>     that's correct or not, I just haven't thought it out.
> 
>     --keith
> 
> I'd be happy to work on that daemon. However, all I've got to work
> with is SunOS 4.0.3. If you don't mind having to find some other
> victim to tune the results up under real 4.3, I'm game.
> 
> Now, what's the idea? the daemon hands you exclusive access to the
> tty device? The daemon dials the phone? I really want to see
> a generic "chat engine" used for all these dialing applications.
> The structure would look like this:
> 
> - a subroutine interface that says "call this number on that device"
> 
> - a system table that configures a modem type for each tty device
> 
> - a "chat engine" used by most modem types to talk to the modem --
> that is, specify dialing by chat script instead of C code.
> 
> - a set of low level routines used in common by those modems too
> hairy for chat scripts.
> 
> - uucp and tip using this mess
> 
> Specifically in tip, there is a need to pass more modem-specific
> options around somehow. For example, for an MNP or PEP modem, the
> speed that tip sets for the serial port and the speed established for
> the connection need to be different.
> 
> As for slip, I think the current integration in the tip you are
> distributing is silly. If there was a generic dialing mechanism,
> then there could be a "make me a slip connection" command that used
> it.
> 
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> >From bostic Tue Feb 13 09:23:14 1990
> To: /a/staff/bostic/mbox/dialer
> 
> 
> Dialer daemon --
> 	On startup reads /etc/ttys, looks for lines marked with a status
> 	of "out" (dial-in) and "inout" (dial-in, dial-out), also reads
> 	/etc/remote.
> 
> 	Then monitors "inout" lines, do a non-blocking OPEN and a select
> 	for write, if carrier comes on, spawn a getty.
> 
> 	Then listen on a UNIX domain socket for dial requests; request
> 	includes phone number (symbolic, i.e. might not need to know
> 	about dial prefixes, this interfaces with /etc/remote), baud
> 	rate, user id, maybe special requirements, flags (which 1200
> 	or 9600 baud protocol to use, or to use UUCP g protocol for the
> 	Trailblazer).  It selects a free modem, does the dialing, and
> 	returns an open file descriptor.  Does logging of the call.
> 	(Maybe can monitor the line, i.e. do ioctl's or flocks to find out
> 	if carrier is still available, so it can handle it if the program
> 	dies.  This may be more difficult than it sounds...)  Security,
> 	make the UNIX domain socket writeable by root or group dialer only,
> 	so tip/uucp have to be setgid dialer.
> 
> 	How to dial -- do a non-blocking open, set soft carrier with an
> 	ioctl (POSIX supplies this, although 4.3BSD does not yet -- we'll
> 	put it in for testing) then dial, then clear soft carrier, at
> 	which point real carrier should have taken over.  In POSIX, there
> 	is a bit for both soft/hard carrier, you can talk if either one
> 	is set.
> 
> Path: seismo!uunet!husc6!bbn!oberon!cit-vax!ucla-cs!sdcrdcf!trwrb!scgvaxd!wlbr!mutley!root
> From: root@mutley.UUCP (System Administrator)
> Newsgroups: comp.unix.wizards
> Subject: dial in/out lines for modems summary wanted
> Status: RO
> 
> I'm seeking a summary of the implementation ideas which were discussed on
> the net regarding the implementation of shared dial in/out lines for modem
> use.  The concept I am seeking to implement is that which uses separate
> minor device numbers for identifying in- and outgoing modem-line devices.
> 
> I recall the discussion of this method using the following scheme:
> 
> 	incoming:	If line is free and a carrier is detected, open
> 			the line, prevent use by an outgoing-open.  If
> 			the line is in use by an outgoing, regardless
> 			of carrier state, sleep.
> 
> 	outgoing:	If line is free, regardless of carrier, open the
> 			line and prevent use by the incoming device node.
> 			If the line is in use, fail.
> 
> Mentions of using ttyMn and ttymn for modem lines with respect to their
> usage (incoming/outgoing) was also suggested.  Is there a common naming
> mechanism followed using this convention?
> 
> I intend to implement this method in both DZ, DL and DH type drivers.  Any
> summarization to help avoid oversights and errors would be appreciated.
> -- 
> Scott G. Taylor       Pmd Resources, 3709 Old Conejo Rd, Newbury Park, CA 91320
> snidely!mutley!staylor@wlbr.eaton.com                            (805) 499-0367
> ..{ucbvax!voder,seismo!scgvaxd}!wlbr!snidely!mutley!staylor
> 			"I am having fun yet."
> 
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> From: william@ernie.Berkeley.EDU (William Jolitz)
> 
> 	From bostic@okeeffe.Berkeley.EDU Fri Jan  5 12:47:08 1990
> 	To: william@okeeffe.Berkeley.EDU
> 	Subject: Re: fun with tip 
> 	Cc: benson@odi.com
> 	Status: R
> 
> 
> 	Bill, Benson Margulies has expressed interest in working on/with
> 	the dialer daemon/tip/uucp.  When I pinged Mike he said that he
> 	thought you might still be whacking on it.  What's it's status?
> 
> I wish that he had chimed up a week ago, when I last dealt with Mike on
> the subject. I have since opened it up again, and have it half-transmorgified
> into a protocol family(!).
> 
> A little history: Mike and I had an Idea, to handle two-way tty's and
> autodial/autoconnect slip with a connection daemon that arbitrates traffic.
> I implemented the scheme, including client code for tip but not uucp, but
> learned much in the process that showed me the weaknesses in the strategy.
> 
> Thus, the aggresive redesign, which, I know, Mike and I will argue the
> merits of. Contact me in voice mode and I'll tell you all about it, but
> prepare for an hour or two, as it is not as simple as it should be.
> 
> 	Would you be interested in having someone do the integration, or
> 	are you planning to do it yourself?  If the former, Benson would
> 	need copies of the current tip and uucp on okeeffe.  I'm gone for
> 	three weeks, so it would probably be best if you contacted him
> 	yes/no directly.
> 
> Yes I am, although I've kind of got my hands full with other projects
> just at the moment, as I'm trying to make some releases in January of
> 386BSD. February is when I'll have time. Could Benson come by and talk
> with me soon? I had wanted to finish integration onto okeeffe, but have
> been waiting for the kernel to settle down. Will it?
> 
> BTW, the stuff is running on my portable UNIX box (e.g. 4.3), but will
> change much for okeeffe. Mike has sources also.
> 
> 	I've attached Benson's mail to me.
> 
> 	--keith
> 
> 	=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> 	> From odi!odi.com!benson@uunet.UU.NET Fri Jan  5 06:50:48 1990
> 	To: bostic@okeeffe.Berkeley.EDU (Keith Bostic)
> 	Subject: Re: fun with tip 
> 	Date: Fri, 05 Jan 90 08:11:59 -0500
> 	From: Benson I. Margulies <benson@odi.com
> 
> 
> 	    Good question, I'm not real sure...  I guess I'd be the first person
> 	    to talk to.  There are two peripheral issues that muddy the waters,
> 	    somewhat.  The first would be we want to create a dialer daemon that
> 	    uucp/tip/cu/whatever connect to whenever they want to dial out.  This
> 	    would be a major win.  We have preliminary code, if you'd be interested
> 	    in making it all work, we'd be greatly indebted.  The second issue is
> 	    dial-up ip.  I expect it to be separate from tip, but I'm not sure if
> 	    that's correct or not, I just haven't thought it out.
> 
> 	    --keith
> 
> 	I'd be happy to work on that daemon. However, all I've got to work
> 	with is SunOS 4.0.3. If you don't mind having to find some other
> 	victim to tune the results up under real 4.3, I'm game.
> 
> BTW, it does not matter as much with the kernel. You need sockets, and the
> socket feature to pass a file descriptor between unrelated processes. Plus
> minor changes in the serial driver. I hope this is available under 4.0.3.
> 
> 	Now, what's the idea? the daemon hands you exclusive access to the
> 	tty device? The daemon dials the phone?
> 
> 1. The client program(tip) calls a library function, asking for a file desciptor
> attached to a modem of the desired phone-number and baud rate or name.
> 
> 2. The connect daemon (cd) accepts and processes these requests, arbitrates
> for a line, runs a configuration & dialing process to make connection
> and passes back the file descriptor when appropriate.
> 
> 3. Client uses pre-connected file descriptor, and passes it back when finished.
> 
> 	I really want to see a generic "chat engine" used for all
> 	these dialing applications.  The structure would look like
> 	this:
> 
> This part we have not done yet. The current interface to a dialing routine
> is a process with standard input/output to the dialer, std error to requestor's
> tty (if any), and argv[0..N] contains translated number and requested
> options in termcap form (sp#1200), env[0..N] contains standard options from
> hidden configuration file. Status is passed back to requestor process.
> Dialer also needs to know about SIGHUP's!
> 
> Our current dialer process is a rather stupid implementation for Hayes modems.
> 
> Note that with this interface, you can debug dialer programs by running them
> on your terminal and typing back, simulating the modem.
> 
> A generalized "chat" program would be a very good thing to write. I have
> no interest in doing so, although would encourage others to as it would be
> very desireable.
> 
> 	- a subroutine interface that says "call this number on that device"
> 
> This we have, but it proves to be more challenging that expected.
> 
> 	- a system table that configures a modem type for each tty device
> 
> Currently as options on a line of /etc/ttys...
> 
> 	- a "chat engine" used by most modem types to talk to the modem --
> 	that is, specify dialing by chat script instead of C code.
> 
> Not done at all.
> 
> 	- a set of low level routines used in common by those modems too
> 	hairy for chat scripts.
> 
> Ditto.
> 	- uucp and tip using this mess
> 
> Have hacked tip (tip became a tiny program!), but found interesting interface
> problems (subtle). Did not yet bother with uucp, nor a standard interface
> description for others to use. Became struck with how this resembled network
> connection/control interface, and recently have explored adding an protocol
> family for connecting to ttys/modems, thus using existing socket interface
> (connect/listen/...) for program interface, pushing complexity elsewhere.
> Not sure this is a good idea yet!
> 
> 	Specifically in tip, there is a need to pass more modem-specific
> 	options around somehow. For example, for an MNP or PEP modem, the
> 	speed that tip sets for the serial port and the speed established for
> 	the connection need to be different.
> 
> env[0..N] contain modem configuration specific info like link speed, while
> argv[0..N] contain things requested like connection speed.
> 
> 	As for slip, I think the current integration in the tip you are
> 	distributing is silly. If there was a generic dialing mechanism,
> 	then there could be a "make me a slip connection" command that used
> 	it.
> 
> I agree. I have been opposed to it from the start. The whole point of this
> project was to decouple and make connection setup/teardown automatic, so
> that autodial slip could invoke a connection transparently on demand. Thus,
> the routed would then intercept requests for possible slip routes that
> did not map to connected network interfaces, and make a request via
> connectd on the behalf of the intended packet! Routed also could administrate
> the connection, and shut it down when traffic stopped.
> 
> 
> Bill Jolitz
> 
> 


From rick Mon Apr  6 16:25:27 1992
Received: by rodan.UU.NET (5.61/UUNET-mail-drop)
	id AA17163; Mon, 6 Apr 92 16:25:22 -0400
Date: Mon, 6 Apr 92 16:25:22 -0400
From: rick (Rick Adams)
Message-Id: <9204062025.AA17163@rodan.UU.NET>
To: piers
Subject: G
Status: OR


Well, the 'G' protocol is supposed to be what I thought. Maybe it
doesnt like your multiple initbs

Xref: uunet comp.mail.uucp:8523 news.answers:886
Path: uunet!uunet!airs!ian
From: ian@airs.com (Ian Lance Taylor)
Newsgroups: comp.mail.uucp,news.answers
Subject: UUCP Internals Frequently Asked Questions
Keywords: UUCP, protocol, FAQ
Message-ID: <uucp-internals_701861402@airs.com>
Date: 29 Mar 92 09:30:10 GMT
Expires: 10 May 92 09:30:02 GMT
Sender: news@airs.com
Reply-To: ian@airs.com (Ian Lance Taylor)
Followup-To: comp.mail.uucp
Lines: 970
Approved: news-answers-request@MIT.Edu
Supersedes: <uucp-internals_699422592@airs.com>

Archive-name: uucp-internals
Version: 2.1
Last-modified: 1995/02/03 13:15:30

 This article was written by Ian Lance Taylor <ian@airs.com> and I may
 even update it periodically.  Please send me mail about suggestions
 or inaccuracies.

 This article describes how the various UUCP protocols work, and
 discusses some other internal UUCP issues.  It does not describe how
 to configure UUCP, nor how to solve UUCP connection problems, nor how
 to deal with UUCP mail.  There are currently no FAQ postings on any
 of these topics, and I do not plan to write any.

 If you haven't read the news.announce.newusers articles, read them.

 This article is in digest format.  Some newsreaders will be able to
 break it apart into separate articles.  Don't ask me how to do this,
 though.

 This article answers the following questions.  If one of these
 questions is posted to comp.mail.uucp, please send mail to the poster
 referring her or him to this FAQ.  There is no reason to post a
 followup, as most of us know the answer already.

Sources
What are UUCP grades?
What is the format of a UUCP lock file?
What is the UUCP protocol?
What is the 'g' protocol?
What is the 'f' protocol?
What is the 't' protocol?
What is the 'e' protocol?
What is the 'G' protocol?
What is the 'x' protocol?
What is the 'd' protocol?
What is the 'h' protocol?

----------------------------------------------------------------------

From: Sources
Subject: Sources

I took a lot of the information from Jamie E. Hanrahan's paper in the
Fall 1990 DECUS Symposium, and from Managing UUCP and Usenet by Tim
O'Reilly and Grace Todino (with contributions by several other
people).  The latter includes most of the former, and is published by
        O'Reilly & Associates, Inc.
        632 Petaluma Avenua
        Sebastopol, CA 95472
It is currently in its tenth edition.  The ISBN number is
0-937175-48-X.

Some information is originally due to a Usenet article by Chuck
Wegrzyn.  The information on the 'g' protocol comes partially from a
paper by G.L. Chesson of Bell Laboratories, partially from Jamie E.
Hanrahan's paper, and partially from source code by John Gilmore.  The
information on the 'f' protocol comes from the source code by Piet
Berteema.  The information on the 't' protocol comes from the source
code by Rick Adams.  The information on the 'e' protocol comes from a
Usenet article by Matthias Urlichs.

----------------------------------------------------------------------

From: UUCP-grades
Subject: What are UUCP grades?

Modern UUCP packages support grades for each command.  The grades
generally range from 'A' (the highest) to 'Z' followed by 'a' to 'z'.
Some UUCP packages also support '0' to '9' before 'A'.  Some UUCP
packages may permit any ASCII character as a grade.

On UNIX, these grades are encoded in the name of the command file.  A
command file name generally has the form
    C.nnnngssss
where nnnn is the remote system name for which the command is queued,
g is a single character grade, and ssss is a four character sequence
number.  For example, a command file created for the system ``airs''
at grade 'Z' might be named
    C.airsZ2551

The remote system name will be truncated to seven characters, to
ensure that the command file name will fit in the 14 character file
name limit of the traditional UNIX file system.  UUCP packages which
have no other means of distinguishing which command files are intended
for which systems thus require all systems they connect to to have
names that are unique in the first seven characters.  Some UUCP
packages use a variant of this format which truncates the system name
to six characters.  HDB and Taylor UUCP use a different spool
directory format, which allows up to fourteen characters to be used
for each system name.

The sequence number in the command file name may be a decimal integer,
or it may be a hexadecimal integer, or it may contain any alphanumeric
character.  Different UUCP packages are different.

I do not know how command grades are handled in non-UNIX UUCP
packages.

Modern UUCP packages allow you to restrict file transfer by grade
depending on the time of day.  Typically this is done with a line in
the Systems (or L.sys) file like this:
    airs Any/Z,Any2305-0855 ...
This allows only grades 'Z' and above to be transferred at any time.
Lower grades may only be transferred at night.  I believe that this
grade restriction applies to local commands as well as to remote
commands, but I am not sure.  It may only apply if the UUCP package
places the call, not if it is called by the remote system.  Taylor
UUCP can use the ``timegrade'' and ``call-timegrade'' commands to
achieve the same effect (and supports the above format when reading
Systems or L.sys).

This sort of grade restriction is most useful if you know what grades
are being used at the remote site.  The default grades used depend on
the UUCP package.  Generally uucp and uux have different defaults.  A
particular grade can be specified with the -g option to uucp or uux.
For example, to request execution of rnews on airs with grade 'd', you
might use something like
    uux -gd - airs!rnews <article

Uunet queues up mail at grade 'Z' and news at grade 'd'.  The example
above would allow mail to be received at any time, but would only
permit news to be transferred at night.

------------------------------

From: UUCP-lock-file
Subject: What is the format of a UUCP lock file?

This discussion applies only to UNIX.  I have no idea how UUCP locks
ports on other systems.

UUCP creates files to lock serial ports and systems.  On most if not
all systems these same lock files are also used by cu to coordinate
access to serial ports.  On some systems getty also uses these lock
files.

The lock file always contains the process ID of the locking process.
This makes it easy to determine whether a lock is still valid.  The
algorithm is to create a temporary file and then link it to the name
that must be locked.  If the link fails because a file with that name
already exists, the existing file is read to get the process ID.  If
the process still exists, the lock attempt fails.  Otherwise the lock
file is deleted and the locking algorithm is retried.

Older UUCP packages put the lock files in the main UUCP spool
directory, /var/spool/uucp.  HDB UUCP generally puts the lock files in
a directory of their own, usually /var/spool/locks or /etc/locks.

The original UUCP lock file format encoded the process ID as a four
byte binary number.  The order of the bytes is host-dependent.  HDB
UUCP stores the process ID as a ten byte ASCII decimal number, with a
trailing newline.  For example, if process 1570 holds a lock file, it
would contain the eleven characters space, space, space, space, space,
space, one, five, seven, zero, newline.  Some versions of UUCP add a
second line indicating which program created the lock (uucp, cu, or
getty).  I have also seen a third type of UUCP lock file which did not
contain the process ID at all.

The name of the lock file is generally "LCK.." followed by the base
name of the device.  For example, to lock /dev/ttyd0 the file
LCK..ttyd0 would be created.  There are various exceptions.  On SCO
Unix, the lock file name is always forced to lower case even if the
device name has upper case letters.  On the Amiga the lock file name
is apparently formed using the major and minor device numbers rather
than the device name (this is pretty sensible if you think about it).

------------------------------

From: UUCP-protocol
Subject: What is the UUCP protocol?

The UUCP protocol is a conversation between two UUCP packages.  A UUCP
conversation consists of three parts: an initial handshake, a series
of file transfer requests, and a final handshake.

Before the initial handshake, the caller will usually have logged in
the called machine and somehow started the UUCP package there.  On
UNIX this is normally done by setting the shell of the login name used
to /usr/lib/uucp/uucico.

All messages in the initial handshake begin with a ^P (a byte with the
octal value \020) and end with a null byte (\000).

The initial handshake goes as follows.  It is begun by the called
machine.

called: \020Shere=hostname\000
    The hostname is the UUCP name of the called machine.  Older UUCP
    packages do not output it, and simply send \020Shere\000.

caller: \020Shostname options\000
    The hostname is the UUCP name of the calling machine.  The
    following options may appear (or there may be none):
        -QSEQ
            Report sequence number for this conversation.  The
            sequence number is stored at both sites, and incremented
            after each call.  If there is a sequence number mismatch,
            something has gone wrong (somebody may have broken
            security by pretending to be one of the machines) and the
            call is denied.
        -xLEVEL
            Requests the called system to set its debugging level to
            the specified value.  This is not supported by all
            systems.
        -pGRADE
        -vgrade=GRADE
            Requests the called system to only transfer files of the
            specified grade or higher.  This is not supported by all
            systems.  Some systems support -p, some support -vgrade=.
        -R
            Indicates that the calling UUCP understands how to restart
            failed file transmissions.  Supported only by System V
            Release 4 UUCP.
        -ULIMIT
            Reports the ulimit value of the calling UUCP.  The limit
            is specified as a base 16 number in C notation (e.g.
            -U0x1000000).  This number is the number of 512 byte
            blocks in the largest file which the calling UUCP can
            create.  The called UUCP may not transfer a file larger
            than this.  Supported only by System V Release 4 UUCP.
        -N
            Indicates that the calling UUCP understands the Taylor
            UUCP size limiting extensions.  Supported only by Taylor
            UUCP.

called: \020ROK\000
    There are actually several possible responses.
        ROK
            The calling UUCP is acceptable, and the handshake proceeds
            to the protocol negotiation.  Some options may also
            appear; see below.
        ROKN
            The calling UUCP is acceptable, it specified -N, and the
            called UUCP also understands the Taylor UUCP size limiting
            extensions.  Supported only by Taylor UUCP.
        RLCK
            The called UUCP already has a lock for the calling UUCP,
            which normally indicates the two machines are already
            communicating.
        RCB
            The called UUCP will call back.  This may be used to avoid
            impostors (but only one machine out of each pair should
            call back, or no conversation will ever begin).
        RBADSEQ
            The call sequence number is wrong (see the -Q discussion
            above). 
        RLOGIN
            The calling UUCP is using the wrong login name.
        RYou are unknown to me
            The calling UUCP is not known to the called UUCP, and the
            called UUCP does not permit connections from unknown
            systems.
    If the response is ROK, the following options are supported by
    System V Release 4 UUCP.
        -R
            The called UUCP knows how to restart failed file
            transmissions.
        -ULIMIT
            Reports the ulimit value of the called UUCP.  The limit is
            specified as a base 16 number in C notation.  This number
            is the number of 512 byte blocks in the largest file which
            the called UUCP can create.  The calling UUCP may not send
            a file larger than this.
        -xLEVEL
            I'm not sure about this one.  It may request the calling
            UUCP to set its debugging level to the specified value.
    If the response is not ROK (or ROKN) both sides hang up the phone,
    abandoning the call.

called: \020Pprotocols\000
    Note that the called UUCP outputs two strings in a row.  The
    protocols string is a list of UUCP protocols supported by the
    caller.  Each UUCP protocol has a single character name.  These
    protocols are discussed in more detail later in this document.
    For example, the called UUCP might send \020Pgf\000.

caller: \020Uprotocol\000
    The calling UUCP selects which protocol to use out of the
    protocols offered by the called UUCP.  If there are no mutually
    supported protocols, the calling UUCP sends \020UN\000 and both
    sides hang up the phone.  Otherwise the calling UUCP sends
    something like \020Ug\000.

When the caller chooses which protocol to use, most packages will
consider each protocol offered by the called UUCP in turn, and select
the first supported one.  With some versions of HDB UUCP, this can be
modified by giving a list of protocols after the device name in the
Devices file or the Systems file.  In this case the caller will select
the first offered by the called UUCP that is on the list.

Taylor UUCP instead considers each locally supported protocol in turn
and selects the first one supported by the called UUCP.  Unless
overridden by a system specific list of protocols, only protocols that
are reasonable for the type of link in use are considered (for
example, the 't' and 'e' protocols are only considered if the link is
over TCP).

After the protocol has been selected the initial handshake has been
completed, and both sides turn on the selected protocol.  For some
protocols (notably 'g') a further handshake is done at this point.

Each protocol supports a method for sending a command to the remote
system.  This method is used to transmit a series of commands between
the two UUCP packages.  At all times, one package is the master and
the other is the slave.  Initially, the calling UUCP is the master.

If a protocol error occurs during the exchange of commands, both sides
move immediately to the final handshake.

The master will send one of four commands: S, R, X or H.

Any file name referred to below is either an absolute pathname
beginning with "/", a public directory pathname beginning with "~/", a
pathname relative to a user's home directory beginning with "~USER/",
or a spool directory file name.  File names in the spool directory are
not pathnames, but instead are converted to pathnames within the spool
directory by UUCP.  They always begin with "C." (for a command file
created by uucp or uux), "D." (for a data file created by uucp, uux or
by an execution, or received from another system for an execution), or
"X." (for an execution file created by uux or received from another
system).

master: S FROM TO USER -OPTIONS TEMP MODE NOTIFY SIZE
    The S and the - are literal characters.  This is a request by the
    master to send a file to the slave.
        FROM
            The name of the file to send.  If the C option does not
            appear in OPTIONS, the master will actually open and send
            this file.  Otherwise the file has been copied to the
            spool directory, where it is named TEMP.  The slave
            ignores this field unless TO is a directory, in which case
            the basename of FROM will be used as the file name.  If
            FROM is a spool directory filename, it must be a data file
            created for or by an execution, and must begin with "D.".
        TO
            The name to give the file on the slave.  If this field
            names a directory (a name ending in '/' is taken to name a
            directory even if one does not already exist with that
            name) the file is placed within that directory with the
            basename of FROM.  If TO begins with "X.", an execution
            file will be created on the slave.  Otherwise, if TO
            begins with "D." it names a data file to be used by some
            execution file.  Otherwise, TO may not be in the spool
            directory.
        USER
            The name of the user who requested the transfer.
        OPTIONS
            A list of options to control the transfer.  The following
            options are defined (all options are single characters):
                C
                    The file has been copied to the spool directory
                    (the master should use TEMP rather than FROM).
                c
                    The file has not been copied to the spool
                    directory (this is the default).
                d
                    The slave should create directories as necessary
                    (this is the default).
                f
                    The slave should not create directories if
                    necessary, but should fail the transfer instead.
                m
                    The master should send mail to USER when the
                    transfer is complete.
                n
                    The slave should send mail to NOTIFY when the
                    transfer is complete.
        TEMP
            If the C option appears in OPTIONS, this names the file to
            be sent.  Otherwise if FROM is in the spool directory,
            TEMP is the same as FROM.  Otherwise TEMP is a dummy
            string, normally "D.0".  After the transfer has been
            succesfully completed, the master will delete the file
            TEMP.
        MODE
            This is an octal number giving the mode of the file on
            MASTER.  If the file is not in the spool directory, the
            slave will always create it with mode 0666, except that if
            (MODE & 0111) is not zero (the file is executable), the
            slave will create the file with mode 0777.  If the file is
            in the spool directory, some UUCP packages will use the
            algorithm above and some will always create the file with
            mode 0600.
        NOTIFY
            This field may not be present, and in any case is only
            meaningful if the n option appears in OPTIONS.  If the n
            option appears, then when the transfer is successfully
            completed, the slave will send mail to NOTIFY, which must
            be a legal mailing address on the slave.  If a SIZE field
            will appear but the n option does not appear, NOTIFY will
            always be present, typically as the string "dummy" or
            simply a pair of double quotes.
        SIZE
            This field is only present when doing size negotiation,
            either with Taylor UUCP or SVR4 UUCP.  It is the size of
            the file in bytes.  SVR4 UUCP sends the size in base 16 as
            0x.... while Taylor UUCP sends the size as a decimal
            integer (a later version of Taylor UUCP will probably
            change to the SVR4 behaviour).

    The slave then responds with an S command response.
        SY START
            The slave is willing to accept the file, and file transfer
            begins.  The START field will only be present when using
            SVR4 file restart.  It specifies the byte offset into the
            file at which to start sending.  If this is a new file,
            START will be 0x0.
        SN2
            The slave denies permission to transfer the file.  This
            can mean that the destination directory may not be
            accessed, or that no requests are permitted.  It implies
            that the file transfer will never succeed.
        SN4
            The slave is unable to create the necessary temporary
            file.  This implies that the file transfer may succeed
            later.
        SN6
            This is only used by Taylor UUCP size negotiation.  It
            means that the slave considers the file too large to
            transfer at the moment, but it may be possible to transfer
            it at some other time.
        SN7
            This is only used by Taylor UUCP size negotiation.  It
            means that the slave considers the file too large to ever
            transfer.

    If the slave responds with SY, a file transfer begins.  When the
    file transfer is complete, the slave sends a C command response.
        CY
            The file transfer was successful.
        CN5
            The temporary file could not be moved into the final
            location.  This implies that the file transfer will never
            succeed.

    After the C command response has been received (in the SY case) or
    immediately (in an SN case) the master will send another command.

master: R FROM TO USER -OPTIONS SIZE
    The R and the - are literal characters.  This is a request by the
    master to receive a file from the slave.  I do not know how SVR4
    UUCP implements file transfer restart in this case.
        FROM
            This is the name of the file on the slave which the master
            wishes to receive.  It must not be in the spool directory,
            and it may not contain any wildcards.
        TO
            This is the name of the file to create on the master.  I
            do not believe that it can be a directory.  It may only be
            in the spool directory if this file is being requested to
            support an execution either on the master or on some
            system other than the slave.
        USER
            The name of the user who requested the transfer.
        OPTIONS
            A list of options to control the transfer.  The following
            options are defined (all options are single characters):
                d
                    The master should create directories as necessary
                    (this is the default).
                f
                    The master should not create directories if
                    necessary, but should fail the transfer instead.
                m
                    The master should send mail to USER when the
                    transfer is complete.
        SIZE
            This only appears if Taylor UUCP size negotiation is being
            used.  It specifies the largest file which the master is
            prepared to accept (when using SVR4 UUCP, this was
            specified in the -U option during the initial handshake).

    The slave then responds with an R command response.
        RY MODE
            The slave is willing to send the file, and file transfer
            begins.  MODE is the octal mode of the file on the slave.
            The master treats this just as the slave does the MODE
            argument in the send command, q.v.
        RN2
            The slave is not willing to send the file, either because
            it is not permitted or because the file does not exist.
            This implies that the file request will never succeed.
        RN6
            This is only used by Taylor UUCP size negotiation.  It
            means that the file is too large to send, either because
            of the size limit specifies by the master or because the
            slave considers it too large.  The file transfer may
            succeed later, or it may not (this will be cleared up in a
            later release of Taylor UUCP).

    If the slave responds with RY, a file transfer begins.  When the
    file transfer is complete, the master sends a C command.  The
    slave pretty much ignores this, although it may log it.
        CY
            The file transfer was successful.
        CN5
            The temporary file could not be moved into the final
            location.

    After the C command response has been sent (in the RY case) or
    immediately (in an RN case) the master will send another command.

master: X FROM TO USER -OPTIONS
    The X and the - are literal characters.  This is a request by the
    master to, in essence, execute uucp on the slave.  The slave
    should execute "uucp FROM TO".
        FROM
            This is the name of the file or files on the slave which
            the master wishes to transfer.  It will often contain
            wildcard characters, since otherwise an R command will
            normally suffice (however, this command can also be used
            to request the transfer of a file on the slave to a third
            system).  Any wildcards should be expanded on the slave.
        TO
            This is the name of the file or directory to which the
            files should be transferred.  This will normally use a
            UUCP name.  For example, if the master wishes to receive
            the files itself, it would use "master!path".
        USER
            The name of the user who requested the transfer.
        OPTIONS
            A list of options to control the transfer.  It is not
            clear which, if any, options are supported by most UUCP
            packages.

    The slave then responds with an X command response.
        XY
            The request was accepted, and the appropriate file
            transfer commands have been queued up for later
            processing.
        XN
            The request was denied.  No particular reason is given.

    In either case, the master will then send another command.

master: H
    This is used by the master to hang up the connection.  The slave
    will respond with an H command response.
        HY
            The slave agrees to hang up the connection.  In this case
            the master sends another HY command.  In some UUCP
            packages the slave will then send a third HY command.  At
            this point the protocol is shut down, and the final
            handshake is begun.
        HN
            The slave does not agree to hang up.  In this case the
            master and the slave exchange roles.  The next command
            will be sent by the former slave, which is the new master.
            The roles may be reversed several times during a single
            connection.

After the protocol has been shut down, the final handshake is
performed.  This handshake has no real purpose, and some UUCP packages
simply drop the connection rather than do it (in fact, some will drop
the connection immediately after both sides agree to hangup, without
even closing down the protocl).

caller: \020OOOOOO\000
called: \020OOOOOOO\000

That is, the calling UUCP sends six O's and the called UUCP replies
with seven O's.  Some UUCP packages always send six O's.

------------------------------

From: UUCP-g
Subject: What is the 'g' protocol?

The 'g' protocol is a packet based flow controlled error correcting
protocol that requires an eight bit clear connection.  It is the
original UUCP protocol, and is supported by all UUCP implementations.
Many implementations of it are only able to support small window and
packet sizes, specifically a window size of 3 and a packet size of 64
bytes, but the protocol itself can support up to a window size of 7
and a packet size of 4096 bytes.  Complaints about the inefficiency of
the 'g' protocol generally refer to specific implementations, rather
than the correctly implemented protocol.

The 'g' protocol was originally designed for general packet drivers,
and thus contains some features that are not used by UUCP, including
an alternate data channel and the ability to renegotiate packet and
window sizes during the communication session.

The 'g' protocol is spoofed by many Telebit modems.  When spoofing is
in effect, each Telebit modem uses the 'g' protocol to communicate
with the attached computer, but the data between the modems is sent
using a Telebit proprietary error correcting protocol.  This allows
for very high throughput over the Telebit connection, which, because
it is half-duplex, would not normally be able to handle the 'g'
protocol very well at all.

This discussion of the 'g' protocol explains how it works, but does
not discuss useful error handling techniques.  Some discussion of this
can be found in Jamie E. Hanrahan's paper, cited above.

All 'g' protocol communication is done with packets.  Each packet
begins with a six byte header.  Control packets consist only of the
header.  Data packets contain additional data.

The header is as follows:

    \020
        Every packet begins with a ^P.
    k (1 <= k <= 9)
        The k value is always 9 for a control packet.  For a data
        packet, the k value indicates how must data follows the six
        byte header.  The amount of data is 2 ** (k + 4), where **
        indicates exponentiation.  Thus a k value of 1 means 32 data
        bytes and a k value of 8 means 4096 data bytes.  The k value
        for a data packet must be between 1 and 8 inclusive.
    checksum low byte
    checksum high byte
        The checksum value is described below.
    control byte
        The control packet indicates the type of packet, and is
        described below.
    xor byte
        This byte is the xor of k, the checksum low byte, the checksum
        high byte and the control byte (i.e. the second, third, fourth
        and fifth header bytes).  It is used to ensure that the header
        data is valid.

The control byte in the header is composed of three bit fields,
referred to here as TT (two bits), XXX (three bits) and YYY (three
bits).  The control is TTXXXYYY, or (TT << 6) + (XXX << 3) + YYY.

The TT field takes on the following values:
    0
        This is a control packet.  In this case the k byte in the
        header must be 9.  The XXX field indicates the type of control
        packet; these types are described below.
    1
        This is an alternate data channel packet.  This is not used by
        UUCP.
    2
        This is a data packet, and the entire contents of the attached
        data field (whose length is given by the k byte in the header)
        are valid.  The XXX and YYY fields are described below.
    3
        This is a short data packet.  Let the length of the data field
        (as given by the k byte in the header) be L.  Let the first
        byte in the data field be B1.  If B1 is less than 128 (if the
        most significant bit of B1 is 0), then there are L - B1 valid
        bytes of data in the data field, beginning with the second
        byte.  If B1 >= 128, let B2 be the second byte in the data
        field.  Then there are L - ((B1 & 0x7f) + (B2 << 7)) valid
        bytes of data in the data field, beginning with the third
        byte.  In all cases L bytes of data are sent (and all data
        bytes participate in the checksum calculation) but some of the
        trailing bytes may be dropped by the receiver.   The XXX and
        YYY fields are described below.

In a data packet (short or not) the XXX field gives the sequence
number of the packet.  Thus sequence numbers can range from 0 to 7,
inclusive.  The YYY field gives the sequence number of the last
correctly received packet.

Each communication direction uses a window which indicates how many
unacknowledged packets may be transmitted before waiting for an
acknowledgement (the window may be different in each direction).  The
window may range from 1 to 7. For example, if the window is 3 and the
last packet acknowledged was packet number 6, packet numbers 7, 0 and
1 may be sent but the sender must wait for an acknowledgement before
sending packet number 2.  This acknowledgement could come as the YYY
field of a data packet or as the YYY field of a RJ or RR control
packet (described below).

Each packet must be transmitted in order (the sender may not skip
sequence numbers).  Each packet must be acknowledged, and each packet
must be acknowledged in order.

In a control packet, the XXX field takes on the following values:
    1 CLOSE
        The connection should be closed immediately.  This is
        typically sent when one side has seen too many errors and
        wants to give up.  It is also sent when shutting down the
        protocol.  If an unexpected CLOSE packet is received, a CLOSE
        packet should be sent in reply and the 'g' protocol should
        halt, causing UUCP to enter the final handshake.
    2 RJ or NAK
        The last packet was not received correctly.  The YYY field
        contains the sequence number of the last correctly received
        packet.
    3 SRJ
        Selective reject.  The YYY field contains the sequence number
        of a packet that was not received correctly, and should be
        retransmitted.  This is not used by UUCP, and most
        implementations will not recognize it.
    4 RR or ACK
        Packet acknowledgement.  The YYY field contains the sequence
        number of the last correctly received packet.
    5 INITC
        Third initialization packet.  The YYY field contains the
        maximum window size to use.
    6 INITB
        Second initialization packet.  The YYY field contains the
        packet size to use.  It requests a size of 2 ** (YYY + 5).
        Note that this is not the same coding used for the k byte in
        the packet header (it is 1 less).  Some UUCP implementations
        can handle any packet size up to that specified; some can only
        handled exactly the size specified.
    7 INITA
        First initialization packet.  The YYY field contains the
        maximum window size to use.

The checksum of a control packet is simply 0xaaaa - the control byte.

The checksum of a data packet is 0xaaaa - (CHECK ^ the control byte),
where ^ denotes exclusive or, and CHECK is the result of the following
routine as run on the contents of the data field (every byte in the
data field participates in the checksum, even for a short data
packet).  This is the routine used by Taylor UUCP, and is a slightly
modified version of a routine which John Gilmore patched from G.L.
Chesson's original paper.  The z argument points to the data and the c
argument indicates how much data there is.

int
igchecksum (z, c)
     register const char *z;
     register int c;
{
  register unsigned int ichk1, ichk2;

  ichk1 = 0xffff;
  ichk2 = 0;

  do
    {
      register unsigned int b;

      /* Rotate ichk1 left.  */
      if ((ichk1 & 0x8000) == 0)
        ichk1 <<= 1;
      else
        {
          ichk1 <<= 1;
          ++ichk1;
        }

      /* Add the next character to ichk1.  */
      b = *z++ & 0xff;
      ichk1 += b;

      /* Add ichk1 xor the character position in the buffer counting from
         the back to ichk2.  */
      ichk2 += ichk1 ^ c;

      /* If the character was zero, or adding it to ichk1 caused an
         overflow, xor ichk2 to ichk1.  */
      if (b == 0 || (ichk1 & 0xffff) < b)
        ichk1 ^= ichk2;
    }
  while (--c > 0);

  return ichk1 & 0xffff;
}

When the 'g' protocol is started, the calling UUCP sends an INITA
control packet with the window size it wishes the called UUCP to use.
The called UUCP responds with an INITA packet with the window size it
wishes the calling UUCP to use.  Pairs of INITB and INITC packets are
then similarly exchanged.  When these exchanges are completed, the
protocol is considered to have been started.

When a UUCP package transmits a command, it sends one or more data
packets.  All the data packets will normally be complete, although
some UUCP packages may send the last one as a short packet.  The
command string is sent with a trailing null byte, to let the receiving
package know when the command is finished.  Some UUCP packages require
the last byte of the last packet sent to be null, even if the command
ends earlier in the packet.  Some packages may require all the
trailing bytes in the last packet to be null, but I have not confirmed
this.

When a UUCP package sends a file, it will send a sequence of data
packets.  The end of the file is signalled by a short data packet
containing zero valid bytes (it will normally be preceeded by a short
data packet containing the last few bytes in the file).

Note that the sequence numbers cover the entire communication session,
including both command and file data.

When the protocol is shut down, each UUCP package sends a CLOSE
control packet.

------------------------------

From: UUCP-f
Subject: What is the 'f' protocol?

The 'f' protocol is a seven bit protocol which checksums an entire
file at a time.  It only uses the characters between \040 and \176
(ASCII space and ~) inclusive as well as the carriage return
character.  It can be very efficient for transferring text only data,
but it is very inefficient at transferring eight bit data (such as
compressed news).  It is not flow controlled, and the checksum is
fairly insecure over large files, so using it over a serial connection
requires handshaking (XON/XOFF can be used) and error correcting
modems.  Some people think it should not be used even under those
circumstances.

I believe the 'f' protocol originated in BSD versions of UUCP.  It was
originally intended for transmission over X.25 PAD links.

The 'f' protocol has no startup or finish protocol.  However, both
sides typically sleep for a couple of seconds before starting up,
because they switch the terminal into XON/XOFF mode and want to allow
the changes to settle before beginning transmission.

When a UUCP package transmits a command, it simply sends a string
terminated by a carriage return.

When a UUCP package transmits a file, each byte b of the file is
translated according to the following table:

       0 <= b <=  037: 0172, b + 0100 (0100 to 0137)
     040 <= b <= 0171:       b        ( 040 to 0171)
    0172 <= b <= 0177: 0173, b - 0100 ( 072 to  077)
    0200 <= b <= 0237: 0174, b - 0100 (0100 to 0137)
    0240 <= b <= 0371: 0175, b - 0200 ( 040 to 0171)
    0372 <= b <= 0377: 0176, b - 0300 ( 072 to  077)

That is, a byte between \040 and \171 inclusive is transmitted as is,
and all other bytes are prefixed and modified as shown.

When all the file data is sent, a seven byte sequence is sent: two
bytes of \176 followed by four ASCII bytes of the checksum as printed
in base 16 followed by a carriage return.  For example, if the
checksum was 0x1234, this would be sent: "\176\1761234\r".

The checksum is initialized to 0xffff.  For each byte that is sent it
is modified as follows (where b is the byte before it has been
transformed as described above):

      /* Rotate the checksum left.  */
      if ((ichk & 0x8000) == 0)
        ichk <<= 1;
      else
        {
          ichk <<= 1;
          ++ichk;
        }

      /* Add the next byte into the checksum.  */
      ichk += b;

When the receiving UUCP sees the checksum, it compares it against its
own calculated checksum and replies with a single character followed
by a carriage return.
    G
        The file was received correctly.
    R
        The checksum did not match, and the file should be resent from
        the beginning.
    Q
        The checksum did not match, but too many retries have occurred
        and the communication session should be abandoned.

The sending UUCP checks the returned character and acts accordingly.

------------------------------

From: UUCP-t
Subject: What is the 't' protocol?

The 't' protocol is intended for TCP links.  It does no error checking
or flow control, and requires an eight bit clear channel.

I believe the 't' protocol originated in BSD versions of UUCP.

When a UUCP package transmits a command, it first gets the length of
the command string, C.  It then sends ((C / 512) + 1) * 512 bytes (the
smallest multiple of 512 which can hold C bytes plus a null byte)
consisting of the command string itself followed by trailing null
bytes.

When a UUCP package sends a file, it sends it in blocks.  Each block
contains at most 1024 bytes of data.  Each block consists of four
bytes containing the amount of data in binary (most significant byte
first, the same format as used by the UNIX function htonl) followed by
that amount of data.  The end of the file is signalled by a block
containing zero bytes of data.

------------------------------

From: UUCP-e
Subject: What is the 'e' protocol?

The 'e' protocol is similar to the 't' protocol.  It does no flow
control or error checking and is intended for use over TCP.

The 'e' protocol originated in versions of HDB UUCP.

When a UUCP package transmits a command, it simply sends the command
as an ASCII string terminated by a null byte.

When a UUCP package transmits a file, it sends the complete size of
the file as an ASCII decimal number.  The ASCII string is padded out
to 20 bytes with null bytes (i.e. if the file is 1000 bytes long, it
sends "1000\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0").  It then sends the
entire file.

------------------------------

From: UUCP-G
Subject: What is the 'G' protocol?

The 'G' protocol is used by SVR4 UUCP.  It is identical to the 'g'
protocol, except that it is possible to modify the window and packet
sizes.  The SVR4 implementation of the 'g' protocol apparently is
fixed at a packet size of 64 and a window size of 7.  I do not know
why SVR4 didn't simply make the 'g' protocol adjustable.

------------------------------

From: UUCP-x
Subject: What is the 'x' protocol?

I believe that the 'x' protocol was intended for use over X.25 virtual
circuits.  It relies on a write of zero bytes being read as zero bytes
without stopping communication.  I have heard that it does not work
correctly.  If someone would care to fill this in more, I would be
grateful.

------------------------------

From: UUCP-d
Subject: What is the 'd' protocol?

This is apparently used for DataKit connections, and relies on a write
of zero bytes being read as zero bytes, much as the 'x' protocol does.
I don't really know anything else about it.

------------------------------

From: UUCP-h
Subject: What is the 'h' protocol?

This is apparently used in some places with HST modems.  It does no
error checking, and is not that different from the 't' protocol.  I
don't know the details.

------------------------------

From: Thanks
Subject: Thanks

Besides the papers and information acknowledged at the top of this
article, the following people have contributed help, advice,
suggestions and information:
    celit!billd@UCSD.EDU (Bill Davidson)
    Matthew Farwell <dylan@ibmpcug.co.uk>
    "Jonathan I. Kamens" <jik@pit-manager.MIT.EDU>
    david nugent <david@csource.oz.au>
    joey@tessi.UUCP (Joey Pruett)
    Larry Rosenman <ler@lerami.lerctr.org>
    Rich Salz <rsalz@bbn.com>
    kls@ditka.Chicago.COM (Karl Swartz)
    jon@console.ais.org (Jon Zeeff)

------------------------------

End of UUCP Internals Frequently Asked Questions
******************************
-- 
Ian Taylor                     ian@airs.com                    uunet!airs!ian
First person to identify this quote wins a free e-mail message:
``Do you make a grievance of weighing so many pounds only, instead of three
  hundred?  Then why fret about living so many years only, instead of more?''


