bill@wrangler.WLK.COM (Bill Kennedy) (01/04/91)
This is lengthy, so if you have no interest in making uucp work on your TCP/IP ethernet, please hit `n' now. You might want to save the article though, in case Murphy strikes and you need to implement it in a hurry in the future. It took some time and experimentation to make this work! First the environment where it does work. This system, wrangler, is a Tower 32/400, 4Mb, SCSI, HPSIO-8, and the Sea Change TCP+ package. Attribution to Sea Change for patiently putting up with my bone headed mistakes and nearly total ignorance of TCP/IP and ethernet. I'm not certain that they would have been as eager to take my order if they had known how much grief they were in for :-) If you've been in agony for TCP+ but couldn't round up the $$$, give them a call, it was on sale when I got mine, it might still be on sale. The machines on the network here are: ssbn 192.86.83.1 80386, ISC 2.2 (Vr3.2) and NFS dunsel 192.86.83.2 80386, ISC 2.0.2 (Vr3.2), NFS and RFS wrangler 192.86.83.3 32/400, 3.00.01 and RFS sentinel 192.86.83.4 AT&T 3B2/310, Vr3.1 and RFS (not on ethernet) coldsnap 192.86.83.15 SCO ODT and NFS (not doing TLI uucp) You'll better understand why I'm listing the IP addresses later. First you have to set up the NLS listener. You have already done that if you're running RFS, but for those who haven't, here's the procedure, step-by-step. The documentation that comes with TCP+ is accurate and complete but it's not immune to bone headed incompetence, hopefully this procedure is. I guess I'd better say you need to be super user to do some of these things, so you may as well do them all as su. 1. Set up an NLS service for uucp. TCP+ calls theirs stptcp, I called mine tliuucp. If you have RFS installed, skip this step and use what ever "net_spec" RFS uses. Look in /usr/net/nls, if there are any populated subdirectories, those are the "net_spec" names you already have. I'll assume you have none and you'll use stptcp for your "net_spec". nlsadmin -i stptcp 2. Set up a service code for each machine you want. There are certainly more elegant ways to do this than my example, but there are briars to contend with if you stray too far from my recipe. I used service code 101 for ssbn to contact wrangler and service code 102 for dunsel to contact wrangler. Each of those machines has a service code 103 for when wrangler wants a uucp session with them. That will all make a lot more sense later. Set up what ever service codes you want, but remember that service code 105 is reserved for RFS. nlsadmin -a 101 -c"/usr/lib/uucp/uucico -r0 -iTLI -u ussbn" -yssbn stptcp nlsadmin -a 102 -c"/usr/lib/uucp/uucico -r0 -iTLI -u udunsel" -ydunsel stptcp nlsadmin -a 105 -c/usr/net/servers/rfs/rfsetup -yrfs stptcp Note that you don't need the 105 unless you plan to run RFS and you don't need RFS to run TLI uucp over TCP/IP. I'll not elaborate on RFS (mercifully!) in this article, it's already long. 3. Make sure that you have entries in /etc/services. The ones in wranglers file read nls 1025/tcp (used by AT&T's Network Listener Service) nls-tty 1026/tcp (used by AT&T's Network Listener Service) The port numbers have significance later, on the two 80386's I arbitrarily chose 256, TCP+ comes configured for 1025 and 1026. 4. You must tell NLS what ports to use for listener and terminal service. This is an incredibly obscure number but when you know its components it makes sense. First the commands, then the explanation. nlsadmin -l "\x00020401c0565303" stptcp nlsadmin -t "\x00020402c0565303" stptcp The addresses are composed of the address family, port address, and IP address the listener uses to hook into TCP/IP: 00020401c0565303 aaaappppiiiiiiii wrangler is 192.86.83.3 | | +------- 0xc0=192, 0x56=86, 0x53=83, 0x03=3 | +----------- 0x0401=1025 +--------------- address family is 2, AF_INET for TCP and UDP These two addresses work on the Tower, for some obscure reason the '386en need sixteen trailing zeroes after the IP address. 5. Check to be sure that NLS has those addresses right (I don't think you need the -t address, it's here because it didn't hurt) nlsadmin -l - stptcp (and the system replies) \x00020401c0565303 6. That's all you have to do for NLS, start the listener with nlsadmin -s stptcp and stop it with nlsadmin -k stptcp 7. Now you're ready to set up Systems, Permissions, Devices, and Dialers. Here are wranglers entries for ssbn and dunsel. Systems: ssbn Any wlknet Any \x00020100c0565301 dunsel Any wlknet Any \x00020100c0565302 Permissions: LOGNAME=ussbn VALIDATE=ssbn REQUEST=yes SENDFILES=yes READ=/ WRITE=/ LOGNAME=udunsel VALIDATE=dunsel REQUEST=yes SENDFILES=yes MACHINE=ssbn:dunsel SENDFILES=yes REQUEST=yes COMMANDS=ALL Devices: wlknet,eg tcp - - TLI \D tliuucp Dialers: tliuucp "" "" NLPS:000:001:103\N\c Note that both ssbn and dunsel have nearly unlimited access and permissions on wrangler, all three machines are physically secure in the same room. Use your head when you set yours up. I also have no password requirement, that's why the uucico command is executed directly by the listener when the appropriate service code is heard on the appropriate port. Here are Systems and Dialers entries on ssbn for contacting wrangler: wrangler Any wlknet Any \x00020401c0565303 tliuucp "" "" NLPS:000:001:101\N\c Notice that ssbn always "dials out" with service code 101, dunsel uses 102, and wrangler uses 103. That's why wrangler listens for ssbn on service code 101 and for dunsel on 102, ssbn and dunsel listen for wrangler on service code 103. Those numbers are not related to the IP addresses other than I chose them so that I would not lose track of who is where and what. You could have a more general purpose program to execute, AT&T and ISC distribute one /usr/lib/uucp/nttyserv, but I didn't get it with the NCR system and I don't know if it has a companion with another name. That program just binds itself to the listener and forks off a getty so that you could use cu or uucico. I can see no useful purpose for cu since you probably have rlogin if you have TCP/IP. 8. You're done! Your listener should be running (check it with ps, you should see user root executing listen -n stptcp and the two crazy port addresses). Contact the other machine with Uutry and you'll see them connect and disconnect. You should not encounter any problems, but if you do, here's what all went on when you were doing all of this. When you ran nlsadmin -i, it went out and made a directory /usr/net/nls/net_spec, my example "net_spec" is stptcp. When you ran nlsadmin -a, a line was entered for each service code in /usr/net/nls/net_spec/dbf. DON'T MONKEY WITH dbf! When you did nlsadmin -l and -t an entry was made in the addr file in the same directory. DON'T MONKEY WITH addr! When you started NLS with nlsadmin -s net_spec, it copied log (if there was one) to o.log, made a log file, pid file, and lock files in the same directory. There is an annoying side effect that I haven't tracked down and probably won't; it's a nuisance. For each successful uucp session and from time to time during the session something complains about some kind of bogus ioctl. The complaint is sent to the console on ttyb. Mine reads something like "**** unknown ioctl 21505". When I was sending news batches around and using uux to run wranglers printers it was a pain in the neck, but now it's just a nuisance. So it all comes down to a rather logical question. If you have TCP/IP with rcp, why on earth would you want to run uucp?!? I have users who know how to use uuto that don't know how to use rcp (I'm not sure I'd want those particular people using rcp anyway :-). I also have remote users who use facilities on ssbn and dunsel but wrangler has all of the modems, phones, and printers. Finally, if I'm on ssbn and need to uuto something off-site, I can uuto filename wrangler!remotesite!user and not have to get the file to wrangler and uuto from there. You get some pretty spectacular transfer rates too! :-) Apologies for the length of this. I posted a similar article to sysv386 when I got TLI uucp working between ssbn and dunsel (before wrangler had TCP+) and got a lot of questions about it. The worst part about that was that I arrived at the '386 solution with a lot of help and even more plain old good luck (e.g. port 256 is the *only* one that works and no address will work unless it's padded with 16 zeroes). I had no idea what I was doing and not even a whiff as to why it worked. The questions came from people who *did* know what they were doing and they assumed that because I got it to work, I knew more than they did :-( Let me issue a similar disclaimer... I can't tell you much more than I already have. I can't explain how/why it works and I have no more idea why the unknown ioctl complaint is issued than I do about why the assembler complains about code that the C compiler wrote. If you try this and it doesn't work, I'll try and help in good faith, but please don't get the notion that I have any in-depth knowledge beyond this article. In (merciful!) conclusion, I have also gotten RFS to run and smail3 to handle SMTP mail with TCP/IP. If there's sufficient interest I'll post similar recipes for such stuff. I posted this one because several people asked me to. -- Bill Kennedy usenet {att,cs.utexas.edu,sun!daver}!ssbn!bill internet bill@ssbn.WLK.COM or attmail!ssbn!bill