UUCP over TCP/IP

[Conor P. Cahill]

stlouis at unixg.ubc.ca (Phill St. Louis) writes:

>I am trying to get UUCP to function over TCP/IP on InterActive Unix 2.2. 

Here is a posting by Bill Kennedy discussing the above subject.  It should
help you solve your problems.

+ Before I start this, many many thanks to Doug Mc Callum and Dick Dunn
+ at ISC for getting me straightened out on the address that nlsadmin
+ wants to make this work, to Bill Bunton at Tools & Techniques, Austin
+ for persevering as I stumble blundered through it, and to Bob Tracy
+ at CDC San Antonio for getting me started.
+ 
+ If you have no interest in a TLI based uucp over TCP/IP, hit `n' now,
+ but if you ever might, save this article, it will save your hair.
+ 
+ Here's the configuration and the problem.  I have two machines that are
+ networked together using ISC TCP/IP.  One of them has both printers that
+ used to be on a third machine connected by a direct 19.2Kbps uucp link.
+ My old lp scripts sort of went by the board when I no longer had a uucp
+ link to the system that had the printers.  It became obvious to me that I
+ had to figure out how to get uucp to work using TLI across the network.
+ TFM has some information on getting RFS to work, but it's silent with
+ respect to uucp using TLI.  A generous and TLI savvy neighbor, Bob Tracy,
+ was able to get things to almost work, but we kept failing in t_bind, it
+ couldn't allocate the address.  ISC lept to the rescue by explaining how
+ the address had to look for the listener to fundtion but we still (by now,
+ Bill Bunton had agreed to help but was falling into similar potholes)
+ couldn't get the originator's uucico to connect with its destination.  What
+ follows is a step-by-step recipe for something that works.  If there is a
+ more elegant way to do it, please feel free to mark it up and re-post.  If
+ there is any generally available documentation (cookbook please, not theory),
+ please tell us too.
+ 
+ Begin by editing /etc/services and create a port for nls.  We used
+ nls	256/tcp		# TLI port
+ if that doesn't suit you, keep track of the port number because you
+ need it to develop the nls address.  Now choose a name for the nls
+ "net_spec" (see NLSADMIN(1M)), we chose tcp.
+ 
+ Initialize the nls net_spec with nlsadmin -i tcp, it will create a
+ directory, /usr/net/nls/tcp and will create some files in it that it
+ uses to actually start the listener.  Now set up the nls service_code
+ nlsadmin -a 101 -c"/usr/lib/uucp/uucico -r0 -iTLI -u loginid" -y "comment" tcp
+ Here loginid is the name of the system who's going to be logging in, on
+ ssbn it's udunsel and on dunsel it's ussbn, both are no password logins
+ since they are local uucp over the ethernet.  I used "dunsel/ssbn uucico"
+ for the comment, all of this ends up in /usr/net/nls/tcp/dbf, you can make
+ a similar entry for cu, choose another service_code, avoid 105 because
+ that's rfs.
+ 
+ Now you have to work up your network address.  We'd have _never_ figured this
+ out without ISC's help!  This is a hex string that is composed of address
+ family (AF_INET), port number, IP address, and padding zeroes.  Here is the
+ format and an example:
+ \x02000100c0fafa010000000000000000    mapped as
+   aaaappppiiiiiiiizzzzzzzzzzzzzzzz
+   |   |   |       +------------------ sixteen padding zeroes
+   |   |   +-------------------------- IP address 192.250.250.1 co.fa.fa.01
+   |   +------------------------------ port address fm /etc/services (256)
+   +---------------------------------- address family, socket address
+ Obviously your mileage is going to vary, but it shouldn't be hard to figure
+ out from this example.  Hang on to it, you're going to use it more than one
+ place...  You have to tell the listener what address he's going to use
+ nlsadmin -l "\x02000100c0fafa010000000000000000" tcp
+ and that number will appear in /usr/net/nls/tcp/addr to be used when you
+ start nls with nlsadmin -s tcp.  Look at /usr/net/nls/tcp/log to be sure
+ that you've gotten started, "Couldn't allocate address" means he can't
+ get to the address you specified, "Invalid argument" means you don't have
+ the right length.
+ 
+ Now you need to make some entries in /usr/lib/uucp/Systems, Devices, and
+ Dialers.  Remember that ssbn and dunsel don't have passwords on each
+ other, we can drop directly into uucico which is what we specified when
+ we added the 101 service code.
+ 
+ Systems:
+ # ssbn's Systems line for contacting dunsel, 192.250.250.2
+ dunsel Any wlknet Any \x02000100c0fafa020000000000000000
+ # dunsel's Systems line for contacting ssbn, 192.250.250.1
+ ssbn   Any wlknet Any \x02000100c0fafa010000000000000000
+ 
+ Devices:
+ wlknet,eg tcp - - TLI \D nls
+ 
+ Dialers:
+ nls "" "" NLPS:000:001:101\N\c
+ 
+ If you used a service_code other than 101 in the nlsadmin -a, replace the
+ 101 in the Dialers entry with the code you used.  Also note that the Systems
+ lines need the address of the system that they are "calling", choose any
+ convenient Devices name, I used wlknet because that's the network name in my
+ /etc/networks.  Now you're ready to test the connection with Uutry.  It
+ goes by too fast to watch, but it's all recorded in /tmp/systemname.  You
+ might have to go through the usual /usr/lib/uucp/Permissions exercise to
+ make them actually talk to each other, but that's unrelated to nls or TCP/IP
+ (I _think_ :-)
+ 
+ Back to the original problem I had set out to solve, my ssbn resident lp
+ scripts just uux the stuff over to dunsel who is physically connected to
+ the printers.  Here's what I use to get to the dot matrix printer:
+ 
+ user=$2
+ options=$5
+ copies=$4
+ shift; shift; shift; shift; shift
+ files="$*"
+ for file in $files
+ do
+ 	uux -  -a$user "dunsel!lp -o$options -n$copies 2>/dev/null" < $file
+ done
+ 
+ The lp setup on dunsel contains all the stuff that worries about lines
+ per inch, pitch, etc.  That's all passed in options, I don't try to use
+ more than one, so beware of quotes/apostrophes.
+ 
+ You'll get some astonishing transfer rates!  My lamebrained lp approach is
+ what I cobbled together because I don't have lpr/lpd and (you can probably
+ tell :-) probably wouldn't understand them if I did.  Don't forget, I didn't
+ claim that this was elegant, just that it works...
-- 
Conor P. Cahill            (703)430-9247        Virtual Technologies, Inc.
uunet!virtech!cpcahil                           46030 Manekin Plaza, Suite 160
                                                Sterling, VA 22170