777 lines
35 KiB
Plaintext
777 lines
35 KiB
Plaintext
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.''
|
|
|
|
Downloaded From P-80 Systems 304-744-2253
|
|
|