System Administration Guide
Chapter 7, Connecting to other computers with UUCP

Adding entries for remote sites to the Systems file

Adding entries for remote sites to the Systems file

The Systems file (/usr/lib/uucp/Systems) contains the information needed by the uucico daemon to establish a communications link to a remote computer. Each entry in the file represents a computer that can be called by your computer.


NOTE: If you plan to route mail traffic over UUCP, you must also configure MMDF as described in ``Running the MMDF Configuration Manager'' in the Mail and Messaging Guide. 

In addition, the Systems file can be configured to prevent any computer that does not appear in this file from logging in on your computer. More than one entry may be present for a particular computer. The additional entries represent alternative communication paths that can be tried in sequential order.


NOTE: If you are setting up your system as a dial-in only (passive) site that never initiates calls, you only need to add the names of the systems that will be calling you with the keyword ``Never'' as in this example:
   guardian Never


Each entry in the Systems file has the following format (each field must be separated by a space): 

sitename schedule device speed phone login-script

where:

sitename
contains the node name of the remote computer. 

schedule
is a string that indicates the day-of-week and time-of-day when the remote computer can be called.

device
is the device type that should be used to establish the communications link to the remote computer.

speed
indicates the transfer speed (or range) of the device used in establishing the communications link.

phone
provides the phone number of the remote computer for automatic dialers. If you wish to create a portable Systems file that can be used at a number of sites where the dialing prefixes differ (for internal phone systems), refer to ``Creating a portable UUCP Systems file'' .

login-script
contains login information (also known as a ``chat script''). This is explained in ``Creating login scripts''. 

The schedule field

The schedule field consists of three subfields. The first, day, is required. The other two, time and retry, are optional. The syntax is as follows:

day[time][;retry]

The day subfield can contain the following keywords:

Su Mo Tu We
Th Fr Sa
for individual days

Wk
for any weekday (Monday-Friday)

Any
for anytime

Never
for a passive arrangement with the remote computer. If the schedule field is Never, your computer never initiates a call to the remote computer. (This field is ignored when you set up polling with uudemon.poll2; see ``Setting up polling'' for details.) The call must be initiated by the remote computer. In other words, your computer is in a passive mode with respect to the remote computer (see ``Limiting access with the Permissions file'' for details ).
The optional time subfield should be a range of times in 24-hour clock format, such as 0800-1230. If no time is specified, any time of day is assumed to be allowed for the call. A time range that spans 0000 is permitted. For example, 0800-0600 means all times are allowed other than times between 6:00am and 8:00am.

For example, the following permits calls on Mondays, Wednesdays, and Fridays between the hours of 9:00am and noon (the schedule field is in boldface for clarity): 

   grebe MoWeFr0900-1200 ACU D1200 14087672676 ogin:
    nuucp ssword: Crested
You can also specify more than one set of day and time entries by separating them with commas. This is useful for more complex specifications. The following example allows calls from 5:00pm to 8:00pm, Monday through Thursday, and calls any time on Saturday and Sunday. This example would be an effective way to call only when phone rates are low, if immediate transfer is not critical:
   gorgon Wk1700-0800,SaSu ACU D1200 14087672676 ogin:
    nuucp ssword: DontLook
The optional subfield, retry, is available to specify the minimum time (in minutes) before a retry following a failed attempt. The subfield separator is a semicolon (;). For example, the following is interpreted as ``call any time, but wait at least 9 minutes before retrying after a failure occurs'':
   Any;9
By default, UUCP uses a method called exponential backoff to allow retry of failed calls. UUCP does not allow another call to go through until after the retry time has elapsed. This interval expands exponentially as the number of unsuccessful attempts increases. The retry field overrides the exponential backoff algorithm. If you set the retry field to 9, for example, UUCP allows another attempt to connect 9 minutes after each failure. The retry field cannot be set lower than 5 minutes.

UUCP does not automatically try a failed call again. You must have polling set up as described in ``Setting up polling'' or manually invoke uucico(ADM). Any files not transferred due to a connection failure are transferred at the next successful connection to that system.

The device field

The device field selects the device type, in most cases an ACU (Automatic Call Unit). For example, the keyword used in the following field is matched against the first field of Devices file entries:

Systems: gorgon Any ACU D1200 14087672676 ogin:
nuucp ssword: DontLook

Devices: ACU tty2A - 1200 /usr/lib/uucp/dialHA12

Additional documentation on the device field is located in the /usr/lib/uucp/Systems file supplied with your system.

The speed field

This field can contain a letter and speed (for example, C1200, D1200) to differentiate between classes of dialers -- refer to ``The speed field''. Some devices can be used at any speed, so the keyword Any can be used. However, we recommend that you specify the actual range of speeds that can be used. (If Any is used in both Systems and Devices entries, 1200 is assumed.) For example, this field must intersect the speed field in the associated Devices file entry:

Systems: gorgon Any ACU D2400-9600 14087672676 ogin:
nuucp ssword: DontLook

Devices: ACU tty1A - D2400-9600 /usr/lib/uucp/dialHA9600

If information is not required for this field, use a hyphen (-) as a place holder for the field.

Variable rate modems

Some modems can determine the connection baud rate from the carrier sent by a remote system. These modems inform the local system of the connection baud rate before issuing the Carrier Detect (CD) signal. The Hayes 2400 dialer supplied with UUCP detects different connection baud rates and informs UUCP and cu when it exits with a successful connection. 

The speed fields in Devices and Systems can specify a range of baud rates for a connection. If a dialer supports baud rates from 300 to 2400 baud, enter the baud rate range in the speed field of Devices as follows: 

300--2400

If a dialer or modem does not allow variable baud rates, place a single baud rate in the speed field. If a remote system supports several different speeds, place the range of baud rates in the speed field of Systems. If the remote system connects at a single baud rate, place that number in Systems. UUCP passes the highest common speed of the Systems and Devices baud rate ranges to the dialer when connecting. If the dialer connects outside of the baud range in the Systems file, it returns a bad baud rate error. Otherwise, it returns the baud rate of the connection.

The phone field

This field provides the phone number used for the modem dialer. The phone number is made up of an optional alphabetic abbreviation and a numeric part. If an abbreviation is used, it must be one that is listed in the Dialcodes file. (See ``Creating a portable UUCP Systems file'' for details.) For example:

Systems: gorgon Any ACU D1200 CA2676 ogin:
nuucp ssword: DontLook

Dialcodes: CA 9=408767

In this string, an equal sign (=) tells the ACU to wait for a secondary dial tone before dialing the remaining digits. A dash in the string (-) instructs the ACU to pause 2 seconds before dialing the next digit.


NOTE: Most dialers treat the equal sign as a pause, so you may need to use more than one.

Do not use the comma (from the Hayes command set) in a Systems file entry when you wish to indicate a pause. Use hyphens instead.


If your computer is connected to a LAN switch or port selector, you can access other computers that are connected to that switch. The Systems file entries for these computers do not have a phone number in the phone field. Instead, this field contains the token that must be passed on to the switch so it knows which computer your computer wishes to communicate with. (This is usually just the system name.) The associated Devices file entry should have a ``\D'' at the end of the entry to prevent translation using the Dialcodes entry. 

The login-script field

The login-script opens communications between modems, and also recognizes and sends proper login and password sequences. The script a series of space-separated fields and subfields of the following format:

expect send

where expect is the string that is received, and send is the string that is sent when the expect string is received. 

The expect field can be made up of subfields of the following form:

expect[-subsend-subexpect]...

where the subsend is sent if the prior expect is not successfully read and the subexpect following the subsend is the next expected string. To make this distinction clear: the send-expect sequence sends a string if the expect string is received; the subsend-subexpect sends only if the prior expect string is not received within 10 seconds.

For example, with ``login:--login:'', the UUCP program expects ``login:''. If a ``login:'' is received, it goes on to the next field. If it does not get ``login:'', it sends nothing followed by a carriage return, then looks for ``login:'' again. If no characters are initially expected from the remote computer, the null string ("") should be used in the first expect field. Note that all send fields are sent followed by a carriage return unless the send string is terminated with a ``\c''. 

If an expect string starts with a dash, it is interpreted as a null expect string followed by a subsend string. For example, ``--login:'' sends a carriage return and then expects a ``login:''.

The expect string need not be complete; only the trailing characters must be specified, as in ``ogin:''. This avoids difficulties with login strings that use an uppercase letter as in ``Login:'' or ``Password:'', and also difficulties when the line is shared by dial-in and dial-out. 

Creating login scripts

This section explains in greater detail how to create a login (``chat'') script.

Consider the following sample Systems file entry:

   terps Any ACU 1200 18005211980 "" \r ogin:-BREAK-ogin:
    uucpx word: ichore
This is how this script would work during connection:

  1. Nothing is expected initially.

  2. A carriage return is sent and the script waits for the prompt ``ogin:'' (login:).

  3. If it does not receive ``ogin:'', send a BREAK signal.

  4. When ``ogin:'' is finally received, send the login name uucpx.

  5. When the prompt ``word:'' (for Password:) is received, send the password ichore. 
Login scripts often require some experimentation. There are cases that require one or more BREAK sequences before presenting a login (this is often true with variable speed modems). If you cannot obtain the necessary login sequence from the system administrator for a given site, it is a good idea to connect with the site manually. You can accomplish this using cu and find out what must be sent to generate a login prompt. (You can also connect with a system using a uutry for debugging; see ``Testing the UUCP connection'' for details. There are several escape characters that cause specific actions when sent during the login sequence, some of which correspond to keystrokes; these should be included in the script where necessary. 

Table 7-1 Login (Chat) script escape sequences

 ------------------------------------------------------
 Character   Description
 ------------------------------------------------------
 \N          sends a null character (ASCII NULL).
 \b          sends or expects a backspace character.
 \c          if at the end of a string, suppresses the
             carriage return that is normally sent.
             Ignored otherwise.
 \d          delays two seconds before sending or
             reading more characters.
 \p          pauses for approximately ¼ to ½ second.
 \E          starts echo checking. (After this sequence
             is used, whenever a character is
             transmitted, the system waits for the
             character to be received before doing
             anything else.)
 \e          turns echo check off.
 \n          sends or expects a newline character.
 \r          sends or expects a carriage-return.
 \s          sends or expects a space character.
 \t          sends or expects a tab character.
 \\          sends or expects a ``\'' character.
 EOT         sends EOT (end of transmission or <Ctrl>d)
 BREAK       sends a BREAK signal.
 \K          same as BREAK.
 \ddd        collapses the octal digits (ddd) into a
             single character whose value is the ASCII
             character represented by that number (for
             example: \007).
 ""          expects a null string.