matt@mips.mitek.com (Matthew Lyle) (03/05/91)
I am trying to setup a uucp connection over ethernet. I've set up all of the files to support this, per the manual. (added uucp to /etc/services, added uucpd to /etc/inetd.conf, added a TCP entry to Devices) When I attempt to establish a connection it fails because no devices are available. Anybody have any ideas what I'm doing wrong? ------ Uutry output ------ mchFind called (abcdefg) name (abcdefg) not found; return FAIL name (OTHER) not found; return FAIL conn(abcdefg) Device Type TCP wanted Internal caller type TCP Internal caller type TCP getto ret -1 Call Failed: NO DEVICES AVAILABLE exit code 101 Conversation Complete: Status FAILED
rob@mother.bates.edu (Rob Spellman) (04/09/91)
Has anybody had any luck setting up UUCP to work over TCP/IP? I looked back through the archives of comp.sys.mips, and saw two similar requests, but I found no responses. I even sent mail to one of the people who posted the question, and they never received a response. I have setup the following files as per the documentation: /etc/services /etc/inetd.conf /usr/lib/uucp/Devices /usr/lib/uucp/Systems and I always get the same response when I try Uutry: Script started on Mon Apr 8 16:39:53 1991 $ ./Uutry dartvax /uucico -r1 -sdartvax -x5 >/tmp/dartvax 2>&1& tmp=/tmp/dartvax mchFind called (dartvax) conn(dartvax) Device Type TCP wanted Internal caller type TCP Internal caller type TCP getto ret -1 Call Failed: NO DEVICES AVAILABLE exit code 101 Conversation Complete: Status FAILED I would appreciate any help. Thanks Rob Spellman rob@mother.bates.edu Computing Support Services Bates College Lewiston, Maine
trevc@tecate.mips.com (Trevor Cotton) (04/09/91)
In article <1991Apr8.204206.2031@mother.bates.edu>, rob@mother.bates.edu (Rob Spellman) writes: |> Has anybody had any luck setting up UUCP to work over TCP/IP? I looked back |> through the archives of comp.sys.mips, and saw two similar requests, but |> I found no responses. I even sent mail to one of the people who posted |> the question, and they never received a response. |> I have it running here between a Magnum3000 and an RC3240 which are both runing RISC/os 4.52 The magnum is called bill, the 3240 ben. They both are set up like :- /etc/services uucp 540/tcp uucpd # uucp daemon /etc/inetd.conf uucpd stream tcp nowait root /usr/etc/uucpd uucpd /usr/lib/uucp/Devices TCP UNIX 0 Any TCP "" /usr/lib/uucp/Permissions LOGNAME=nuucp /etc/passwd nuucp:youguess:10:10:0000-uucp(0000):/usr/spool/uucppublic:/usr/lib/uucp/uucico None of these entries differs from what is shipped, except for the Devices entry is un-commented and the addition of an nuucp passwd. On bill, the following /usr/lib/uucp/Systems entry was added ben Any TCP - - in:--in: nuucp word: youguess On ben, the following /usr/lib/uucp/Systems entry was added bill Any TCP - - in:--in: nuucp word: youguess Here is the output I get from Uutry. ( Note the two FAIL returns from name are because I have no MACHINE entries in the Permissions file ):- Script started on Mon Apr 8 16:58:35 1991 bill,trevc 26 %/usr/lib/uucp/Uutry -r ben /usr/lib/uucp/uucico -r1 -sben -x5 >/tmp/ben 2>&1& tmp=/tmp/ben mchFind called (ben) name (ben) not found; return FAIL name (OTHER) not found; return FAIL conn(ben) Device Type TCP wanted Internal caller type TCP tcpdial host ben, port 540 set interface TCP processdev: calling setdevcfg(uucico, TCP) getto ret 6 expect: (in:) login:got it sendthem (????????) expect: (word:) Password:got it sendthem (????????) Login Successful: System=ben msg-ROK Rmtname ben, Role MASTER, Ifn - 6, Loginuser - trevc rmesg - 'P' got Pge wmesg 'U'g Proto started g *** TOP *** - role=1, wmesg 'H' rmesg - 'H' got HY PROCESS: msg - HY HUP: wmesg 'H'Y cntrl - 0 send OO 0,exit code 0 Conversation Complete: Status SUCCEEDED bill,trevc 27 % script done on Mon Apr 8 16:58:53 1991 Hope this helps, -- --trevc--
rob@mother.bates.edu (Rob Spellman) (04/09/91)
Sorry, I forgot to mention my system. I am running RISCos 4.51 on a MIPS M120/5. Rob Spellman rob@mother.bates.edu Computing Support Services Bates College
tin@smsc.sony.com (Le Tin) (04/09/91)
In article <1991Apr8.204206.2031@mother.bates.edu> rob@mother.bates.edu (Rob Spellman) writes: >Has anybody had any luck setting up UUCP to work over TCP/IP? I looked back >through the archives of comp.sys.mips, and saw two similar requests, but >I found no responses. I even sent mail to one of the people who posted >the question, and they never received a response. > The problem is in getting the correct port setup for UUCP over TCP. Of course, that involves some fairly arcane incantations... Luckily, someone else has already struggled through this and posted the solution. I saved his instructions and now repost it here for those who missed it. - Tin Le +------------------------------------------------------------------------ Path: szebra!claris!apple!bionet!agate!ucbvax!ucsd!usc!cs.utexas.edu!chinacat!balkan!wrangler!bill From: bill@wrangler.WLK.COM (Bill Kennedy) Newsgroups: comp.sys.ncr Subject: ethernet uucp with TLI 3.00.01 Keywords: NLS TLI uucp ethernet Message-ID: <471@wrangler.WLK.COM> Date: 3 Jan 91 20:29:30 GMT Organization: W.L. Kennedy Jr. & Associates, Pipe Creek, TX Lines: 195 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. +------------------------------------------------------------------------ -- .---------------------------------------------------------------------- . Tin Le Work Internet: tin@smsc.Sony.COM . Sony Microsystems UUCP: {uunet,mips}!sonyusa!tin . Work: (408) 944-4157 Home Internet: tin@szebra.uu.net
trevc@tecate.mips.com (Trevor Cotton) (04/10/91)
In article <1991Apr9.164524.6695@smsc.sony.com>, tin@smsc.sony.com (Le Tin) writes: |> In article <1991Apr8.204206.2031@mother.bates.edu> rob@mother.bates.edu (Rob Spellman) writes: |> >Has anybody had any luck setting up UUCP to work over TCP/IP? I looked back |> >through the archives of comp.sys.mips, and saw two similar requests, but |> >I found no responses. I even sent mail to one of the people who posted |> >the question, and they never received a response. |> > |> |> The problem is in getting the correct port setup for UUCP over TCP. Of |> course, that involves some fairly arcane incantations... |> |> Luckily, someone else has already struggled through this and posted the |> solution. I saved his instructions and now repost it here for those who |> missed it. |> |> - Tin Le |> |> +------------------------------------------------------------------------ |> Path: szebra!claris!apple!bionet!agate!ucbvax!ucsd!usc!cs.utexas.edu!chinacat!balkan!wrangler!bill |> From: bill@wrangler.WLK.COM (Bill Kennedy) |> Newsgroups: comp.sys.ncr |> Subject: ethernet uucp with TLI 3.00.01 |> Keywords: NLS TLI uucp ethernet |> Message-ID: <471@wrangler.WLK.COM> |> Date: 3 Jan 91 20:29:30 GMT |> Organization: W.L. Kennedy Jr. & Associates, Pipe Creek, TX |> Lines: 195 |> |> 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! |> UUCP over TCP under RISCOS 4.xx does not use TLI, and hence this post does not apply. Indeed, TLI is not supported under RISCos 4.xx. Please see my previous posting on how to set up UUCP over TCP for RISCos 4.xx. -- --trevc-- Trevor Cotton, Sustaining Engineering, MIPS Computer Systems Inc. MS 6-05, 930 DeGuigne Drive, Sunnyvale, CA 94086 Tel: +1 408 524 7286 Fax: +1 408 524 7521 Email: {wyse,ames,decwrl,pyramid}!mips!trevc trevc@mips.com
nadmin@mercury.uregina.ca (News Administration) (04/10/91)
What version of the o/s are you running. This was broke in 4.50 and fixed in 4.51. Jason Walters University of Regina Systems Manager Regina, Saskatchewan,Canada Computer Science Department (306)585-4977 walter@mercury.uregina.ca regina!mercury!walter ** my opinions are my own...etc...etc.... ** --------------------------------------------------------------
rossc@extro.ucc.su.oz.au (Ross Cartlidge) (04/11/91)
rob@mother.bates.edu (Rob Spellman) writes: >Sorry, I forgot to mention my system. I am running RISCos 4.51 on a >MIPS M120/5. One way of running uucp (or any application which uses tty's) over TCP/IP is to make a tcp connection look like a tty/pty. I have a package which does this. We use it for UUCP, modems, printing, SLIP, etc Get it from archive.su.oz.au in pub/nd/* Due to bugs in RISC/OS with respect to ptys it has never worked as well on RISC/OS as other OS's, but it only causes you problems it something unusual happens. -- ________________________________________________________________________ Ross Rodney Cartlidge | rossc@extro.ucc.su.oz.au University Computing Service, H08 | Phone: +61 2 6923497 University of Sydney, NSW 2006, Australia | FAX: +61 2 6606557