| UUCP was originally designed to allow systems to exchange files between, and run programs on, remote machines. To enable this, all that was needed was to create logins on both systems for the "UUCP user," which provided both a degree of security and a mechanism for authentication. Next, the UUCP "database" files (which are actually text files, as we'll see later) are edited to allow everything to function correctly. Once everything was set up, users could connect in and run their tasks. Nowadays, UUCP isn't used as much, although some of the files have been utilized by PPP. These are the ones we will be dealing with, and are listed below. The remaining ones are unused, so we'll ignore them to avoid any confusion: /etc/uucp/Devices /etc/uucp/Dialers /etc/uucp/Systems
The first thing we need to do before we can start any configuration work is to check that the packages are installed on the system. Running pkginfo should show us that they are: cesium# pkginfo | grep -i uucp system SUNWbnur Networking UUCP Utilities, (Root) system SUNWbnuu Networking UUCP Utilities, (Usr) cesium# Chat Scripts Chat scripts are used to allow a computer to provide automated responses to a series of "questions" from another machine. For example, UUCP uses them to pass the login information to the remote system when the user is trying to login to it. Chat scripts consist of sequences of words or characters separated by white space and are grouped together as "expect-send" pairs. The first sequence is read as "expect this," the next as "send this," then "expect," then "send," and so on. Note that we always start with an expect string. For example, take the following sequence below: Hello | hiThere | whoAreYou | theSystemDialingIn | Connected |
In this example, we would expect the remote system to send "Hello," reply back with "hiThere," expect it to respond with "whoAreYou," then return "theSystemDialingIn," at which time the remote system would respond with "Connected." The expect-send sequence may also be further broken down into "expect-send-expect" if required. For example, a common portion of a login sequence is as follows: ogin:--ogin: This translates to: "Expect the remote system to send the login prompt, and if it doesn't, we'll send a 'break,' and again expect the login prompt." We have not included the "l" in "login" as we aren't sure how the remote machine displays its prompts. For example, it may use any of the following, or perhaps even something completely different! login: Login: Remote Login: Fri Jan 01 Login:
The only "rule" we can apply, and that normally everyone follows, is that the login prompt ends with "ogin:", which the chat script would match. A similar rule applies to the password prompt, which is why we try to match "assword" (as we'll see later). This convention of matching the last few characters is commonly used to get around these types of issues. The example above shows that it can be very difficult to know exactly what the script should consist of. There is really only one way to confirm this and that is to manually connect to the machine and note down exactly what key sequences you need to enter to successfully gain access. We'll see how to do this a little later when we create ours. Devices File This file contains entries for the hardware devices we are using to establish the link. ACU refers to "Auto Call Unit," which we can think of as our modem. The last field is simply a token name for our configuration, and will be referred to in some other files: cesium# cat /etc/uucp/Devices ACU cua/b - Any dialupModem cesium# We are using a modem connected to /dev/term/b that will be used for all the connections we defineregardless of the connection speed we require. This is why we only need one modem entry defined. OK, that seems easy enough, so let's move on to the dialers file. Dialers File The dialers file allows us to store the settings that will be applied to the modem whenever it is used. Modems can be very awkward pieces of hardware to configure correctly, so once the required settings are obtained they are best stored in this file. In this way, should the modem fail, we won't need to remember what the settings were. We simply swap the hardware (assuming it's the same type!) and let UUCP do the rest. This file also allows us to define numerous modem definitions, connect them all up, and know that, whichever we use, its settings will be correctly applied by UUCP. In the following output, "dialupModem" is the token name that we used earlier in the devices file. It refers to the modem connected on /dev/cua/b. The next field specifies a translation string, which in our case simply indicates we want to alter any "=" and "-" characters to be pauses, which are shown as ",". This is used to allow us to use standard characters ("=" and "-") in the system's file, which will be translated into the correct characters for this particular modem. The remaining fields contain the input for a chat script that will be used to initiate the modem: cesium# grep dialupModem /etc/uucp/Dialers dialupModem =,-, "" P_ZERO "" \dATZ\pE1V1\r\c OK\r ATDT\T\r\c CONNECT STTY=crtscts cesium# Let's break this down into its expect-send sequences and take another look at it. Doing this shows we have the following: "" expect nothing (we always start with an expect string) P_ZERO set the line to be no parity "" expect nothing \d send a delay ATZ perform a reset of the modem to bring it back to a consistent state \p send a pause E1 enable "echo" V1 set verbose return codes \r\c send a return without a new line OK\r expect to receive an "OK" followed by a return ATDT dial the following number, using tone dialing \T pass the telephone number \r\c send a return without a new line CONNECT expect to see the connection string to indicate the remote modem has connected STTY=crtscts set hardware flow control
How do we know what values to set? Most modems nowadays use a common command set (Hayes AT command set), so there are some common settings that apply to most modems. For example, ATE1 nearly always enables "echo." Unfortunately, the settings to apply may also depend on the modem you are communicating with; the only real way to know exactly which settings to use is to read the manual and test them! That said, there are a few settings that we always apply, regardless of the modem. These are the port settings (P_ZERO and STTY=crtscts). These values can be placed in the /etc/uucp/Systems file if you wish, but we have put them here so that they will be applied to every connection that uses this modem. We've already mentioned above that P_ZERO disables parity. A very common problem is for modems to connect, then suddenly disconnectvery often, the cause is incorrect parity settings. Placing an empty expect string and the correct parity setting in the chat script will force UUCP to apply the correct settings and overcome the problem. The available options that can be used are as follows: We also use STTY=crtscts to force hardware flow control, but any options available to stty or termio can actually be used. Systems File This file contains the dialup and login parameters for the system we will be connecting into. Let's take a look at ours and see what it contains: cesium# cat /etc/uucp/Systems theISP Any ACU 115200 1234567890 ogin:--ogin: guest word: guestPassword\n\n otocol: ppp\n\n HELLO cesium# The first field is another token name, which will be used later to refer to this connection. Next, we specify that the remote system can be called at "Any" time. Then we look for an "ACU"-type device capable of a line speed of 115,200. (In our case, this will be the modem connected to port "B.") Next, we have the phone number of the ISP, followed by the script that contains the login information. To create this entry, we dialed into the machine, using tip, and manually logged on to the system. This allows us to take note of the prompts and keystrokes that we need to enter to be able to login successfully. The actual login session is shown below: cesium# tip 9600 /dev/cua/b Connected AT OK ATDT1234567890 Welcome to the ISP's System login: <break> login: guest<return> password: guestPassword<return> <return> protocol: ppp<return> <return> HELLO Working through this, we can see that we first expect the login prompt. We will send a break to kick the machine into life in case we don't see it. This gives the first expect string: ogin:--ogin: Now we send the login name, which becomes the send string: Guest Next we expect to see the password prompt, and we reply with our password. We also need to hit return twice before we see the next prompt, to produce the next expect-send sequence: assword: guestPassword\n\n After this, we see the protocol prompt. Our ISP has told us that we have to specify "ppp" at this point, followed by two returns. This forms the next expect-send sequence: otocol: ppp\n\n Finally, we expect to receive the word "HELLO." Again, this is specified by our ISP and appears when PPP has successfully started on the ISP's side. At this point we have connected and the login procedure is complete so the remaining tasks are ready to complete (PPP, in our case). Checking UUCP Once all the files have being correctly edited, we can start to check the UUCP configuration to make sure it will work when we use it for PPP. We can do this a number of ways, but probably the easiest it to run cu. We've run it with the following debug option below as this will show the sequences that cu is going through: cesium# cu d theISP conn(theISP) Trying entry from '/etc/uucp/Systems' - device type ACU. Device Type ACU wanted Trying device entry 'cua/b' from '/etc/uucp/Devices'. <lines removed for clarity> cesium# We won't show the whole log file as that would take too much space, but you will see lots of entries saying things like "expect," "got it," and "sendthem," which indicates that cu is working through the UUCP files correctly. Eventually you should see the "Connected" string, which shows that the dialup parameters are correct. At this point we are happy that the UUCP configuration is OK (or at least accurate enough to start testing PPP with it). | 
