ront@sphinx.UChicago.UUCP (Ron Thielen) (01/16/86)
We have been scratching our heads over this one for a while. Any help would be greatly appreciated. I am attempting to establish a UUCP connection between my Pyramid and an AT&T 3B2-400. When we call the 3B2, uucico fires up on their side and identifies their system properly. It then sends LOGIN where my system is expecting OK. My system then gives up with HANDSHAKE FAILED. I know of at least one 4.2BSD VAX experiencing the exact same problem with a different 3B2. The 3B2 doesn't have a source license, and my System V source doesn't give me a clue. We experience the same problem whether running uucico from the 4.2BSD universe or the System V universe on the Pyramid. Here's a script of our conversation. ucb root 1 cd /usr/lib/uucp ucb root 2 uucico -r1 -x9 -spaladin& [1] 1159 ucb root 3 uucp sphinx (1/9-17:44-1159) DEBUG (ENABLED) finds called getto called call: no. paladin for sys paladin Using ACU to call Dialing T(PHONE#) Using hayes dc - /dev/ttyi47 \015\012OK\015\012\015\012CONNECThayes ok login called wanted ogin: \015\012\015\012remote login:got that send (USERID) wanted assword: pcd\015\012Password:got that send (PASSWORD) uucp paladin (1/9-17:45-1159) SUCCEEDED (call to paladin ) imsg >\015\012UNIX System V Release 2.0.4 3B2 Version 2\015\012paladin\015\012Copyright (c) 1984 AT&T\015\012All Rights Reserved\015\012\020< Shere=paladin\000imsg >\020< RLOGIN\000msg-RLOGIN uucp paladin (1/9-17:45-1159) HANDSHAKE FAILED (LOGIN) Hanging up fd = 7 exit code 0 [1] Done uucico -r1 -x9 -spaladin
guy@sun.uucp (Guy Harris) (01/17/86)
> I am attempting to establish a UUCP connection between my Pyramid and a > AT&T 3B2-400. When we call the 3B2, uucico fires up on their side and > identifies their system properly. It then sends LOGIN where my system is > expecting OK. See reply to other similar reported problem. It has nothing whatsoever to do with the UUCP running on the calling side; it could be anything from V7 to System V Release 2, and probably even Honey Danber, and the same problem would occur. The problem is that the *called* side hasn't had its USERFILE (or the Honey Danber equivalents) set up right; System V Release 2's UUCP enforces rules that had never been enforced before, and which people got used to not being enforced. You *must* enable logins for *every* account used by UUCP in the USERFILE or whatever file(s) Honey Danber uses. Guy Harris
larry@kitty.UUCP (Larry Lippman) (01/20/86)
> > I am attempting to establish a UUCP connection between my Pyramid and a > > AT&T 3B2-400. When we call the 3B2, uucico fires up on their side and > > identifies their system properly. It then sends LOGIN where my system is > > expecting OK. > > See reply to other similar reported problem. It has nothing whatsoever to > do with the UUCP running on the calling side; it could be anything from V7 > to System V Release 2, and probably even Honey Danber, and the same problem > would occur. The problem is that the *called* side hasn't had its USERFILE > (or the Honey Danber equivalents) set up right; System V Release 2's UUCP > enforces rules that had never been enforced before, and which people got > used to not being enforced. You *must* enable logins for *every* account > used by UUCP in the USERFILE or whatever file(s) Honey Danber uses. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Generally /usr/lib/uucp/Permissions is the file name. Some of the uucp logfile errors resulting from incorrect entries in the above file are: "HANDSHAKE FAILED" and "REMOTE REJECT AFTER LOGIN". If you have Honey Danber, chances are you have a program called /usr/lib/uucp/uucheck which facilitates checking the correctness of Permissions file entries. I would also suggest the following to simplify uucp troubleshooting and to improve system security: 1. Create (in /etc/passwd) individual uucp logins for EACH remote system; e.g., `uusysx', `uusysy', etc. and block the general entries for `uucp' and `nuucp'. This also gives you additional information for your accounting program, if you run one. 2. Create individual entries for each remote system in the Permissions file, with each entry being in the combined machine/logname format. 3. Disable the "remote.unknown" option. ==> Larry Lippman @ Recognition Research Corp., Clarence, New York <== ==> UUCP {decvax|dual|rocksanne|rocksvax|watmath}!sunybcs!kitty!larry <== ==> VOICE 716/741-9185 {rice|shell}!baylor!/ <== ==> FAX 716/741-9635 {G1, G2, G3 modes} duke!ethos!/ <== ==> seismo!/ <== ==> "Have you hugged your cat today?" ihnp4!/ <==