<!-- <date>$Id: uucp-howto,v 2.0 1997/12/3 18:26:59 Guylhem Exp $ -->

<!-- to add: - how to do uucp over TCP -->

<!doctype linuxdoc system>
<article>

<title>The Linux UUCP HOWTO
<author>Guylhem Aznar <tt>&lt;guylhem at oeil.qc.ca></tt>
<date>v2.0, 6 February 1998

<abstract>
<nidx>UUCP</nidx>
This document describes the setup, care &amp; feeding of UUCP under Linux.

You need to read this if you plan to connect to remote sites via UUCP via a
modem, via a direct-connection, or via Internet.

You probably do *not* need to read this document if don't talk UUCP or if you
don't know what it means.
</abstract>

<toc>

<sect>Introduction, copyright &amp; standard disclaimer<p>

<sect1> Email &amp; spamming <p>

First, convert all "at" in Emails addresses given in this document into
"@".

It's simple for humans, but not for bots searching the web to spam ; therefore
it's enough to protect generous contributors from being spammed.

<sect1> Goals <p>

The intent of this document is to answer some of the questions &amp; comments
that appear to meet the definition of "frequently asked questions" about UUCP
software under Linux genrally &amp; the version in the Linux Debian and
RedHat distributions in particular.

<sect1> New versions <p>

New versions of this document will be periodically posted to
comp.os.linux.announce, comp.answers &amp; news.answers.  They will also be
added to the various anonymous ftp sites who archive such information
including <url name="sunsite FTP"
url="http://sunsite.unc.edu:/pub/Linux/docs/HOWTO">.

In addition, you should be generally able to find this document on the
Linux WorldWideWeb home page at <url name="the LDP page"
url="http://sunsite.unc.edu/LDP/">.

<sect1> Feedback <p>

I am interested in any feedback (please e-mail), positive or negative,
regarding the content of this document.  Definitely contact me if you find
errors or obvious omissions.

I read, but do not necessarily respond to, all e-mail I receive.  Requests for
enhancements will be considered &amp; acted upon based on that day's combination
of available time, merit of the request &amp; daily blood pressure :-)

Flames will quietly go to /dev/null so don't bother.

Feedback concerning the actual format of the document should go to the HOWTO
coordinator: Greg Hankins (<tt>gregh at sunsite.unc.edu</tt>).

<sect1> Copyright <p>

The UUCP-HOWTO is copyrighted (c)1997 Guylhem Aznar.
Distributed under LDP copyright license.
If you have questions, please contact Greg Hankins, the Linux HOWTO coordinator,
at <tt>gregh at sunsite.unc.edu</tt>.

<sect1> Limited warranty <p>

Of course, I disavow any potential liability for the contents of this
document.  Use of the concepts, examples, &amp;/ or other content of this
document is entirely at your own risk.

<sect>Other sources of information<p>
<nidx>UUCP!information resources</nidx>

<sect1> USENET <p>
<nidx>UUCP!information resources!newsgroups</nidx>

There is nothing "special" about configuring &amp; running UUCP under
Linux (any more).  Accordingly, you almost certainly do *NOT* want
to be posting generic UUCP-related questions to the comp.os.linux.*
newsgroups.

Don't post in comp.os.linux hierarchy unless it's really linux specific, for
example: "What's wrong with Debian 1.2 uucp?" or "RedHat 5.0 uucp crashes
when I run it" ...

Let me repeat that.

There is virtually no reason to post anything uucp-related in the
comp.os.linux hierarchy any more.  There are existing newsgroups in the
comp.mail.* hierarchy to handle *ALL* your questions.

<em>
IF YOU POST TO COMP.OS.LINUX.* FOR NON-LINUX-SPECIFIC QUESTIONS, YOU ARE
LOOKING IN THE WRONG PLACE FOR HELP.  THE UUCP EXPERTS HANG OUT IN THE PLACES
INDICATED ABOVE AND GENERALLY DO NOT RUN LINUX.
</em>

<em>
POSTING TO THE LINUX HIERARCHY FOR NON-LINUX-SPECIFIC QUESTIONS WASTES YOUR
TIME AND EVERYONE ELSE'S AND IT FREQUENTLY DELAYS YOU FROM GETTING THE ANSWER
TO YOUR QUESTION.
</em>

The GOOD PLACE is <tt>comp.mail.uucp</tt> since you can get answers for most of
your <idx>UUCP questions</idx>.

<sect1> Mailing Lists <p>
<nidx>UUCP!information resources!mailing lists</nidx>

There is a <idx>Taylor UUCP mailing list</idx>.

To join (or get off) the list, send mail to
<verb>
              taylor-uucp-request@gnu.ai.mit.edu
</verb>

This request goes to a person, not to a program, so please make sure that you
include the address at which you want to receive mail in the text of the
message.

To send a message to the list, send it to
<verb>
             taylor-uucp@gnu.ai.mit.edu
</verb>

<sect1> Other documents from LDP <p>
<nidx>UUCP!information resources!HOWTOs, related</nidx>

There is plenty of exceptional material provided in the other Linux HOWTO
documents &amp; from the Linux DOC project.

In particular, you might want to take a look at the following:

<itemize>
<item>on your own computer in /usr/doc/uucp &amp; /usr/info/uucp* :-)
<item>the Linux Networking Administrators' Guide
<item>the Serial Communications HOWTO
<item>the Ethernet HOWTO
<item>the News HOWTO
<item>the Mail HOWTO
</itemize>

<sect1> Books <p>
<nidx>UUCP!information resources!books</nidx>

HDB &amp; V2 versions of UUCP are documented in about every vendor's
documentation as well as in almost all *nix communications books.

Taylor config. files are currently only documented in the info files provided
with the sources (&amp; in your distribution hopefully). 
The following is a non-inclusive set of books that will help.

<itemize>

<item> <tt>"Managing UUCP &amp; USENET"</tt> from O'Reilly &amp; Associates is in my
opinion the best book out there for figuring out the programs &amp; protocols
involved in being a USENET site.

<item> <tt>"Unix Communications"</tt> from The Waite Group contains a nice
description of all the pieces (&amp; more) &amp; how they fit together.

<item> <tt>"Practical Unix Security"</tt> from O'Reilly &amp; Associates has a
nice discussion of how to secure UUCP.

<item> <tt>"The Internet Complete Reference"</tt> from Osborne is a fine
reference book that explains the various services available on Internet &amp; is
a great source for information on news, mail &amp; various other Internet
resources.

<item>"<tt>The Linux Networking Administrators' Guide</tt>" from Olaf Kirch of
the Linux DOC Project is available on the net &amp; is also published by (at
least) O'Reilly &amp; SSC.  It makes a fine <em>one-stop shopping</em> to learn
about everything you ever imagined you'd need to know about Unix networking.
</itemize>

<sect>Requirements<p> 
<nidx>UUCP!requirements</nidx>

<sect1> Hardware <p>
<nidx>UUCP!requirements!hardware</nidx>

There are no specific hardware requirements for UUCP under Linux.
Basically any Hayes-compatible <idx>modem</idx> works painlessly with UUCP.

In most cases, you'll want the fastest modem you can afford, i.e. 56000 bps
actually.  In general, you want to have a 16550 UART on your serial board or
built into your modem to handle speeds of above 9600 baud.

If you don't know what that last sentence means, please consult the
<em>comp.dcom.modems</em> group or the various fine modem &amp; serial
communications FAQs &amp; periodic postings on USENET.

<sect1> Software <p>
<nidx>UUCP!requirements!software</nidx>
 
UUCP for linux is available everywhere, for example on sunsite.unc.edu.
But before trying to get any version, try to install &amp; make your current uucp
work ; there're many little differences between each linux distribution,
therefore it's easier for you to configure/install your distribution's UUCP
package rather than editing sources for some options, setting the right 
paths &amp; permissions, installing, etc.

But if you prefer sources ...

<p> 1) Unpack <p>

To extract a gzip'd tar archive, I do the following:
<verb>
                gunzip -c filename.tar.z | tar xvf -
</verb>
A "modern" tar can just do a:
<verb>
               tar -zxvf filename.tgz
</verb>

<p> 2) Run "configure" <p>

Type <tt>"sh configure"</tt>.

The configure script will compile a number of test programs to see what is
available on your system &amp; will calculate many things.

The configure script will create <tt>conf.h</tt> from conf.h.in &amp;
<tt>Makefile</tt> from Makefile.in.  It will also create config.status, which
is a shell script which actually creates the files.

<p> 3) Decide where to install <p>

Rather than editing the Makefile.in file in the sources you can get the same
effect by:

<verb>
        "configure --prefix=/usr/lib"
</verb>

<p> 4) Edit "policy.h" for your local system <p>

<itemize>
<item> - set the type of lockfiles you want (HAVE_HDB_LOCKFILES) 
<item> - set the type of config files you want built in
		(HAVE_TAYLOR_CONFIG, HAVE_V2_CONFIG, HAVE_HDB_CONFIG)
<item> - set the type of spool directory structure you want
		(SPOOLDIR_HDB)
<item> - set the type of logging you want (HAVE_HDB_LOGGING)
<item> - set the default search path for commands
		(I added /usr/local/bin to mine)
</itemize>

<p> 5) Then compile &amp; install the software <p>

<itemize>
<item>Type <tt>"make"</tt> to compile.
<item>Type <tt>"make install"</tt> to install.
</itemize>

<sect>Setting up the config files<p>
<nidx>UUCP!config files</nidx>

I recommend you start by installing the attached known-good config. files
included in the document.

<sect1> Installing config. files <p>
<nidx>UUCP!config files!installing</nidx>


Put these file in their "standard" location: <tt>/etc/uucp</tt> on recent
linux distributions or <tt>/usr/lib/uucp</tt> on older ones.

Then make sure that the <tt>permissions</tt> of the files are

<tscreen><verb>
(guylhem@barberouge:uucp)$ ls -l
total 11
-rw-r--r--   1 uucp     uucp          501 Jan 23 11:33 Poll
-rw-r-----   1 uucp     uucp          589 Jan 23 11:34 call
-rw-r-----   1 uucp     uucp         1184 Jan 23 12:06 config
-rw-r-----   1 uucp     uucp          476 Jan 23 12:31 crontab
-rw-r-----   1 uucp     uucp         1256 Jan 23 11:47 dial
-rw-r-----   1 uucp     uucp          486 Jan 23 11:48 passwd
-rw-r-----   1 uucp     uucp          810 Jan 23 11:55 port
-rw-r--r--   1 uucp     uucp         1690 Jan 23 12:04 sys
(guylhem@barberouge:uucp)$
</verb></tscreen>

To change file owner, as root, type:
<tscreen><verb>
(root@barberouge:uucp)$ chown uucp.uucp *
</verb></tscreen>

Then you must change file permissions; as root once again, type:
<tscreen><verb>
(root@barberouge:uucp)# chmod 640 *
(root@barberouge:uucp)# chmod +r Poll sys
</verb></tscreen>

<sect1> <idx>"Poll" file</idx> <p>
<nidx>UUCP!config files!poll file</nidx>

This file is used to set polling timetables for any system.

<tscreen><verb>
schedule polux 01
poll     polux 01
</verb></tscreen>

My machine calls polux at 01:00, that's all!

You can add more line if you must call many other machines, but don't forget to
put the 2 lines (schedule &amp; poll) for each.

<sect1> <idx>"call" file</idx> <p>
<nidx>UUCP!config files!call file</nidx>

It contains your login/password for each system you poll:
<tscreen><verb>
polux uudan password
</verb></tscreen>

My machine uses "uudan" login &amp; "password" password :-) when it polls "polux".
 
As for Poll, adapt this to your situation.

<sect1> <idx>"config" file</idx> <p>
<nidx>UUCP!config files!config file</nidx>

<tscreen><verb>
nodename barberouge                     # The UUCP name of this system

spool /var/spool/uucp                   # The UUCP spool directory
pubdir /var/spool/uucppublic            # The UUCP public directory
logfile /var/log/uucp/log               # The UUCP log file
statfile /var/log/uucp/stats            # The UUCP statistics file
debugfile /var/log/uucp/debug           # The UUCP debugging file

#sysfile        /etc/uucp/sys           # Default "sys"
#portfile       /etc/uucp/port          # Default "port"
#dialfile       /etc/uucp/dial          # Default "dial"
#dialcodefile   /etc/uucp/dialcode      # Default "dialcode"
#callfile       /etc/uucp/call          # Default "call"
#passwdfile     /etc/uucp/passwd        # Default "passwd"

# No commands may be executed by unknowns (empty list of permitted commands)
# Upload is authorized in /var/spool/uucp
unknown commands
unknown pubdir /var/spool/uucp
unknown remote-send ~ !~/upload
unknown remote-receive ~/upload
</verb></tscreen>

Here just replace "barberouge" by your system name ; run "hostname" if you
can't remind it.

<sect1> <idx>"crontab" file</idx> <p>
<nidx>UUCP!config files!crontab file</nidx>

<tscreen><verb>
# Every day just before morning generate reports.
#
0 7 * * *     /usr/lib/uucp/uudemon.day root
#
# Every hour start the uudemon.hr. To actually poll a remote system,
# enter its name in /etc/uucp/Poll. You are encouraged to change the "8".
#
8 * * * *      /usr/lib/uucp/uudemon.hr
</verb></tscreen>

Just run "crontab -u uucp /etc/uucp/crontab" to add it to the others crontabs.

<sect1> <idx>"dial" file</idx> <p>
<nidx>UUCP!config files!dial file</nidx>

<tscreen><verb>
# 1) expect nothing (i.e., continue with step 2)
# 2) send "ATZ", then a carriage return, then sleep for 1 to 2 seconds.
# The \c means to not send a final carriage return.
# 3) wait until the modem echoes "OK", then do the the same for "ATX4" & "OK"
# 4) send "ATDT", then the telephone number (after translating any dialcodes).
# 5) wait until the modem echoes "CONNECT"
# 6) if we get "BUSY", "NO CARRIER" ... during the chat script we abort dialing
# 7) when the call is over, we make sure we hangup the modem


dialer hayes
chat "" ATZ\r\d\c OK\r \dATX4\r\d\c OK\r ATDT\D CONNECT
chat-fail RING
chat-fail NO\sCARRIER
chat-fail ERROR
chat-fail NO\sDIALTONE
chat-fail BUSY
chat-fail NO\sANSWER
chat-fail VOICE
complete \d\d+++\d\dATH\r\c
abort \d\d+++\d\dATH\r\c

# You can also add other dialers: inetd, nullmodem ...
#dialer nullmodem
#complete \d\dexit\r\c
#abort \d\dexit\r\c
</verb></tscreen>

Syntax is complicated ... you'd rather not touch anything here but "ATZ" &amp;
"ATX4" which are my modem init string.

<sect1> <idx>"passwd" file</idx> <p>
<nidx>UUCP!config files!passwd file</nidx>

<tscreen><verb>
#uuguest                guestpassword
</verb></tscreen>

If you allow uucp dialin, just add system/passwords in this file.

It's *that* simple.

But it's recommended for security reasons to make sure each have a separate
account &amp; home directory so you can track things.
 
<sect1> <idx>"port" file</idx> <p>
<nidx>UUCP!config files!port file</nidx>

<tscreen><verb>
# Description for the modem entry
# Debianers, make SURE this device is root:dialout, mode 0660 (crw-rw---)

port ACU
type modem
device /dev/ttyS0
dialer hayes
speed 57600
# hardflow n


# Description for the TCP port - pretty trivial. DON'T DELETE.
# Change service number if non standard, cf /etc/services

port TCP
type tcp
#service 540


# Description for the nullmodem entry
# (ttyS1 means COM2)

port nullmodem
type direct
device /dev/ttyS1
dialer nullmodem
speed 115200
</verb></tscreen>

You shouldn't change anything here ... except your modem port.

On recent distributions with mgetty, it's <tt>/dev/ttySN</tt> while on older
distributions it's <tt>/dev/cuaN</tt>, where N is you serial port:

N starts at 0 &amp; ttyS(N) means COM(N+1), for example, my null-modem is on ttyS1
(COM2) while my modem is on ttyS0 (COM1).

Most of recent modems support hardware flow control, if your doesn't, just
uncomment the line "&num; hardflow n".

<sect1> <idx>"sys" file</idx> <p>
<nidx>UUCP!config files!sys file</nidx>

<tscreen><verb>
# First some defaults. These are for ALL other entries (unless overridden).
#
protocol gvG
protocol-parameter G packet-size 1024
# protocol-parameter G window 7
protocol-parameter G short-packets

#
# Our remote uucp connection.
#
system polux
call-login *
call-password *
local-send /
local-receive /var/spool/uucppublic
remote-send /
remote-receive /var/spool/uucppublic
time any
phone 0111111110
port ACU
chat "" \r\c ogin:-BREAK-ogin:-BREAK- \L word: \P
#chat "" \d\d\r\c ogin: \d\L word: \P

# This is an alternate - it means that if a connection using the above
# "system polux" fails it falls through to this entry.
# Only useful if your service provider has more then one phone number for UUCP.
#
#alternate polux-2
#alias polux-2
#phone 0222222220

# Here's another alternate - we poll the system over TCP/IP.
# This is useful if we have a PPP connection to our provider.
# The first two entries will fail because the modem is busy & we will poll
# over TCP/IP.
#
#alternate polux-tcp
#alias polux-tcp
#time any
#address uucp.polux
#port TCP
#protocol t

#
# Last example - a system that we poll over TCP/IP.
#
#system horizon
#call-login *
#call-password *
#time any
#chat "" \d\d\r\c ogin: \d\L word: \P
#address uucp.horizon.nl
#port TCP
#protocol t
</verb></tscreen>

Here, you must change "polux" by the name of the system you poll &amp; "0111111110"
by its phone number.

"polux-2", "polux-tcp" &amp; "horizon" are just examples of user specific needs ;
if the system you poll has more than one line, define it as "itsname-2" ; if
you call it by PPP sometimes, just define "itsname-tcp" also.

It's useful when chat script fail (busy ...)

<sect1> Now let's test all this <p>
<nidx>UUCP!testing</nidx>

First run:

<tscreen><verb>
(root@barberouge:uucp)# su uucp
(uucp@barberouge:uucp)# /usr/lib/uucp/uuchk
Local node name barberouge
Spool directory /var/spool/uucp
Public directory /var/spool/uucppublic
Lock directory /var/lock
Log file /var/log/uucp/log
Statistics file /var/log/uucp/stats
Debug file /var/log/uucp/debug
Global debugging level
uucico -l will strip login names and passwords
uucico will strip UUCP protocol commands
Start uuxqt once per uucico invocation

System: polux
 When called using any login name
 Call out using port ACU
 The possible ports are:
  Port name ACU
   Port type modem
   Device /dev/ttyS0
   Speed 57600
   Carrier available
   Hardware flow control available
   Dialer hayes
    Chat script "" ATZ\r\d\c OK\r \dATX4\r\d\c OK\r ATDT\D CONNECT
    Chat script timeout 60
    Chat failure strings RING NO\sCARRIER ERROR NO\sDIALTONE BUSY NO\sANSWER VOICE
    Chat script incoming bytes stripped to seven bits
    Wait for dialtone ,
    Pause while dialing ,
    Carrier available
    Wait 60 seconds for carrier
    When complete chat script "" \d\d+++\d\dATH\r\c
    When complete chat script timeout 60
    When complete chat script incoming bytes stripped to seven bits
    When aborting chat script "" \d\d+++\d\dATH\r\c
    When aborting chat script timeout 60
    When aborting chat script incoming bytes stripped to seven bits
 Phone number 0111111110
 Chat script "" \r\c ogin:-BREAK-ogin:-BREAK- \L word: \P
 Chat script timeout 10
 Chat script incoming bytes stripped to seven bits
 Login name uudan
 Password your_password_here
 At any time may call if any work
 May retry the call up to 26 times
 May make local requests when calling
 May make local requests when called
 May send by local request: /
 May send by remote request: /
 May accept by local request: /var/spool/uucppublic
 May receive by remote request: /var/spool/uucppublic
 May execute /usr/bin/uucp /usr/bin/rmail /usr/bin/rnews
 Execution path /bin /usr/bin /usr/local/bin /usr/sbin
 Will leave 50000 bytes available
 Public directory is /var/spool/uucppublic
 Will use protocols gvG
 For protocol G will use the following parameters
  packet-size 1024
  short-packets
</verb></tscreen>

to check if all the informations you've set are correct.

Warning: your mileage may vary ; different distributions use different
paths, regardless Linux FSSTD!

If everything is correct, run:

<tscreen><verb>
	/usr/sbin/uucico -r 1 -x 9 -s remote_system_name
</verb></tscreen>

The <tt>-x 9</tt> will have maximum debugging information written to the
<tt>/var/log/uucp/debug</tt> file for help in initial setup. 

I normally run <tt>-x 4</tt> here since that level logs details that help me
with login problems.
Obviously, this text contains clear informations from your systems file
(account/password) so protect it against world-read.

<sect1> Additional informations <p>
<nidx>UUCP!information resources</nidx>

>From <em>Pierre.Beyssac at emeraude.syseca.fr</em>
<p>
Taylor has more logging levels.  Use -x all to get the highest level possible.

Also, do a <tt>"tail -f /var/log/uucp/debug"</tt> while debugging to watch
things happen on the fly.

<sect>It doesn't work - now what?
<p>
<nidx>UUCP!troubleshooting</nidx>
In general, you can refer to the documentation mentioned above if things don't
work.

You can also refer to your more experienced UUCP neighbors for help.
Usually, it's something like a typo anyway.

<sect>Frequently Asked Questions about Linux UUCP
<p>
<nidx>UUCP!frequently asked questions (see UUCP, FAQ)</nidx>
<nidx>UUCP!FAQ</nidx>

<sect1>Why is all the info here for UUCPs configured in "Taylor" rather than
"HDB" mode?
<p>
<nidx>UUCP!FAQ!Taylor versus HDB mode</nidx>
(religious mode on - I know some people are just as religious about "ease
of use" as I am about "being standard".  That's why they make source code you
can build your own from :-) )

Because IMHO it's the de-facto standard UUCP implementation at this time.
There are thousands of sites with experienced admins &amp; there are many places
you can get incredibly good information concerning the HDB setup.

Moreover, if you know what HDB is, you shouldn't be reading this HOWTO :-)

Use the <tt>uuconv</tt> utility in /usr/sbin to convert config files from
one mode to another.

<sect1>Why do I get "timeout" on connections when I upgraded to uucp-1.04?
<p>
<nidx>UUCP!FAQ!timeout with uucp-1.04</nidx>
<itemize>
<item> from <em>Ed Carp - erc at apple.com</em> 
<p>
If you use a "Direct" device in the Devices file, there's now a
10 second timeout compiled in.  Make the name of the Device anything
other than "Direct".  If you tweak the example /etc/uucp files
provided, you won't have problems with this one.

<item> from <em>Greg Naber - greg at squally.halcyon.com</em> 
<p>
If you get chat script timeouts, you can tweak the sources by 
editing at line 323 in uuconf/syssub.c &amp; changing the default
timeouts from 10 seconds to something larger.

<item> from <em>Ed Rodda - ed at orca.wimsey.bc.ca</em>
<p>
If you get chat script timeouts, typically connecting to other
Taylor sites, a pause after login can fix this.
<verb>
feed Any ACU,ag 38400 5551212 ogin: \c\d "" yourname word: passwd
</verb>  
<item> from <em>Dr. Eberhard W. Lisse - el at lisse.NA</em> 
<p>
Some kernels experience modems hanging up after a couple of seconds.
The following patch sent by Ian Taylor might help.
<tscreen><verb>
*** conn.c.orig Mon Feb 22 20:25:24 1993
--- conn.c      Mon Feb 22 20:33:10 1993
***************
*** 204,209 ****
--- 204,212 ----

     /* Make sure any signal reporting has been done before we set
       fLog_sighup back to TRUE.  */
+   /* SMR: it seems to me if we don't care about SIGHUPS, we should clear
+      the flag before we return  */
+   afSignal[INDEXSIG_SIGHUP] = FALSE;
    ulog (LOG_ERROR, (const char *) NULL);
    fLog_sighup = TRUE;
</verb></tscreen> 
</itemize>

<sect1>Why doesn't HDB anonymous uucp seem to work?
<p>
<nidx>UUCP!FAQ!HDB anonymous uucp failure</nidx>
Taylor in HDB mode seems to be sensitive to white space &amp; blank lines.
To be safe, make sure that there are no blank lines or trailing spaces in the
Permissions file.

Lastly, make sure that you have a file called <tt>remote.unknown</tt> in
/usr/lib/uucp or /etc/uucp &amp; that it's <em>*NOT*</em> executable.

See the O'Reilly &amp; Associates book <tt>"Managing UUCP &amp; USENET"</tt> for
details regarding this file.

<sect1>What does "no matching ports found" mean?
<p>
<nidx>UUCP!FAQ!no matching ports error</nidx>
In all probability, you are attempting to use a dialer that doesn't exist, or
the dialer you've specified in the port files doesn't match up with any
valid devices in the dial file.

<sect1>What are known good config files for HDB mode?
<p>
<nidx>UUCP!FAQ!config files, known good</nidx>
The following are "known-good" config files for Taylor 1.05 under Linux in
HoneyDanBer mode.  They work on kernels of 0.99-8 or later. All files should
be in /usr/lib/uucp or /etc/uucp unless you've tweaked the sources to put the
uucp library elsewhere.

If you *HAVE* put things in non-standard places, be aware that things like
sendmail might get very confused. You need to ensure that all
communications-related programs agree on your idea of "standard" paths.

<verb>
#------------- Devices -------------
# make sure the device (cua1 here) matches your system
# cua N = COM N+1 
#
# here "scout" is the Digicom Scout Plus 19.2 modem I use
# tbfast etc. is for a Telebit Trailblazer Plus modem's various speeds
#
ACU cua1 - 19200 scout
ACU cua1 - 9600 tbfast
ACU cua1 - 1200 tbslow
ACU cua1 - 2400 tbmed

#------------- dialers --------------
# note the setting of the Trailblazer registers "on the fly"
# "scout" is a Digicom Scout Plus (Hayes-like) modem I use here
#
scout	=W-,	"" ATM0DT\T CONNECT
tbfast	=W-,	"" A\pA\pA\pT OK ATS50=255DT\T CONNECT\sFAST
tbslow	=W-,	"" A\pA\pA\pT OK ATS50=2DT\T CONNECT\s1200
tbmed	=W-,	"" A\pA\pA\pT OK ATS50=3DT\T CONNECT\s2400

#-------------- Systems -------------
# this is a very generic entry that will work for most systems
#
# the Any;1 means that you can call once per minute with using -f (force)
# the ACU,g means force "g" protocol rather than Taylor's default "i"
#
fredsys Any;1 ACU,g 19200 scout5555555 "" \r ogin:--ogin: uanon word: uanon 

#-------------------------------- Permissions -------------------------

# Taylor UUCP in HDB mode appears to be sensitive to blank lines.
# Make sure all Permissions lines are real or commented out.
#	
# this is a anonymous uucp entry
#
LOGNAME=nuucp MACHINE=OTHER \
READ=/var/spool/uucp/nuucp \
WRITE=/var/spool/uucp/nuucp \
SENDFILES=yes REQUEST=yes \
COMMANDS=/bin/rmail
# # this is a normal setup for a remote system that talks to us
# note the absolute path to rnews since this site puts things
# in locations that aren't "standard"
#
LOGNAME=fredsys MACHINE=fredsys \
READ=/var/spool/uucp/fredsys:/var/spool/uucp/uucppublic:/files \
WRITE=/var/spool/uucp/fredsys:/var/spool/uucppublic \
SENDFILES=yes REQUEST=yes \
COMMANDS=/bin/rmail:/usr/bin/rnews
#----------------------------------------------------------------------
</verb>
<sect1>Getting uucico to call alternate numbers
<p>
<nidx>UUCP!FAQ!uucico calling alternate numbers</nidx>
The new v1.05 has an added '-z' switch to uucico that will try alternate
numbers for a remote system.

You can else use Taylor mode &amp; "systemyouarecalling-2" (see "sys" in config.
files section for more details)

<sect>Acknowledgements<p>

The following people have helped in the assembly of the information &amp;
experience that helped make this document possible:

Ed Carp, Steve Robbins, Ian Taylor, Greg Naber, Matt Welsh, Pierre Beyssac &amp;
especially many thanks to Vince Skahan for his huge contribution.

If I forgot anybody, my apologies: just email me.

</article>
