Olaf Kirch - Linux Network Administrator Guide, Second Edition

Similarly, the timegrade field is not checked when a remote system calls in, so any jobs queued for the calling system will be sent. However, the remote system can explicitly request your uucico to restrict itself to a certain spool grade.

The port file tells uucico about the available ports. These are usually modem ports, but other types, such as direct serial lines and TCP sockets, are supported as well.

Like the sys file, port consists of separate entries starting with the keyword port followed by the port name. This name may be used in the sys file's port statement. The name need not be unique; if there are several ports with the same name, uucico will try each in turn until it finds one that is not currently being used.

The port command should be followed immediately by the type statement, which indicates what type of port is described. Valid types are modem , direct for direct connections, and tcp for TCP sockets. If the port command is missing, the port type defaults to modem.

In this section, we cover only modem ports; TCP ports and direct lines are discussed in a later section.

For modem and direct ports, you have to specify the device for calling out using the device directive. Usually, this is the name of a device special file in the /dev directory, like /dev/ttyS1 .

In the case of a modem device, the port entry also determines what type of modem is connected to the port. Different types of modems have to be configured differently. Even modems that claim to be Hayes-compatible aren't always really compatible with one another. Therefore, you have to tell uucico how to initialize the modem and make it dial the desired number. Taylor UUCP keeps the descriptions of all dialers in a file named dial . To use any of these, you have to specify the dialer's name using the dialer command.

Sometimes, you will want to use a modem in different ways, depending on which system you call. For instance, some older modems don't understand when a high-speed modem attempts to connect at 56 kbps; they simply drop the line instead of negotiating a connect at 9,600 bps, for instance. When you know site drop uses such a dumb modem, you have to set up your modem differently when calling them. For this, you need an additional port entry in the port file that specifies a different dialer. Now you can give the new port a different name, such as serial1-slow , and use the port directive in the drop system entry in sys .

A better to distinguish the ports is by the speeds they support. For instance, the two port entries for the above situation may look like this:

# NakWell modem; connect at high speed

port serial1 # port name

type modem # modem port

device /dev/ttyS1 # this is COM2

speed 115200 # supported speed

dialer nakwell # normal dialer

# NakWell modem; connect at low speed

port serial1 # port name

type modem # modem port

device /dev/ttyS1 # this is COM2

speed 9600 # supported speed

dialer nakwell-slow # don't attempt fast connect

The system entry for site drop would now give serial1 as the port name, but request to use it at only 9,600 bps. uucico then automatically uses the second port entry. All remaining sites that have a speed of 115,200 bps in the system entry will be called using the first port entry. By default, the first entry with a matching speed will be used.

The dial file describes the way various dialers are used. Traditionally, UUCP talks of dialers rather than modems, because in earlier times, it was usual practice to have one (expensive) automatic dialing device serve a whole bank of modems. Today, most modems have dialing support built in, so this distinction gets a little blurred.

Nevertheless, different dialers or modems may require a different configuration. You can describe each of them in the dial file. Entries in dial start with the dialer command that gives the dialer's name.

The most important entry besides dialer is the modem chat, specified by the chat command. Similar to the login chat, it consists of a sequence of strings uucico sends to the dialer and the responses it expects in return. It is commonly used to reset the modem to some known state and dial the number. The following sample dialer entry shows a typical modem chat for a Hayes-compatible modem:

# NakWell modem; connect at high speed

dialer nakwell # dialer name

chat "" AT&F OK\r ATH1E0Q0 OK\r ATDT\T CONNECT

chat-fail BUSY

chat-fail ERROR

chat-fail NO\sCARRIER

dtr-toggle true

The modem chat begins with "", the empty expect string. uucico therefore sends the first command AT&F right away. AT&F is the Hayes command to reset the modem to factory default configuration. uucico then waits until the modem has sent OK and sends the next command, which turns off local echo and the like. After the modem returns OK again, uucico sends the dialing command ATDT. The escape sequence \T in this string is replaced with the phone number taken from the system entry sys file. uucico then waits for the modem to return the string CONNECT, which signals that a connection with the remote modem has been established successfully.

Sometimes the modem fails to connect to the remote system; for instance, if the other system is talking to someone else and the line is busy. In this case, the modem returns an error message indicating the reason. Modem chats are not capable of detecting such messages; uucico continues to wait for the expected string until it times out. The UUCP log file therefore only shows a bland "timed out in chat script" instead of the specific reason.

However, Taylor UUCP allows you to tell uucico about these error messages using the chat-fail command as shown above. When uucico detects a chat-fail string while executing the modem chat, it aborts the call and logs the error message in the UUCP log file.

The last command in the example shown above tells UUCP to toggle the Data Terminal Ready (DTR) control line before starting the modem chat. Normally, the serial driver raises DTR when a process opens the device to tell the attached modem that someone wants to talk to it. The dtr-toggle feature then drops DTR, waits a moment, and raises it again. Many modems can be configured to react to a drop of DTR by going off-hook, entering command state, or resetting themselves. [98] Some modems don't seem to like this and occasionally hang.

Absurd as it may sound, using UUCP to transfer data over TCP is not that bad an idea, especially when transferring large amounts of data such as Usenet news. On TCP-based links, news is generally exchanged using the NNTP protocol, through which articles are requested and sent individually without compression or any other optimization. Although adequate for large sites with several concurrent newsfeeds, this technique is very unfavorable for small sites that receive their news over a relatively slow connection such as ISDN. These sites will usually want to combine the qualities of TCP with the advantages of sending news in large batches, which can be compressed and thus transferred with very low overhead. A common way to transfer these batches is to use UUCP over TCP.