Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site vaxb.calgary.UUCP
Path: utzoo!utcsri!ubc-vision!alberta!calgary!mcewan
From: mcewan@calgary.UUCP (Duncan McEwan)
Newsgroups: net.micro.att,net.unix-wizards
Subject: 3B2/300 uucp ports & Permissions
Message-ID: <81@vaxb.calgary.UUCP>
Date: Thu, 17-Apr-86 21:57:57 EST
Article-I.D.: vaxb.81
Posted: Thu Apr 17 21:57:57 1986
Date-Received: Thu, 17-Apr-86 23:49:22 EST
Organization: U. of Calgary, Calgary, Ab.
Lines: 48
Keywords: AT&T 3B2/300, SVR2.0, uucp, tty ports

We have two AT&T 3B2/300s with SVR2.0 which are directly connected via
UUCP. One of the systems is also connected to a Pyramid 90x via a Micom
switch. The direct link between 3B2s uses uugetty at both ends to
provide a bi-directional link, but the link to the Micom switch is
outgoing only, and so the tty port must be turned off.
 
The problem is that the outgoing link to the Micom will only work
through the contty port, and not tty11 for example, whereas the
bidirectional direct link will successfully work through any port.
 
Testing was done using cu, which would only connect through to the Micom
via tty11 after a shutdown, but even then would not send any data.
Subsequent tries would result in the message CAN'T ACCESS DEVICE.
Swapping the direct link (which was on contty) with the Micom line
(which was on tty11) resulted in both links working well.
 
I suspect that the explanation is related to the difference between
uugetty and having a line turned off. I did try playing around with
/etc/gettydefs but to no avail. Although the system is now working
reasonably well I would be interested to know why it was not. Any ideas?
 
 
This second part is not a request for information, but more of a
warning, and help for those who may be wondering why their machines will
not communicate.
 
Concerning the 3B2/300s which are directly connected via UUCP, the Basic
Networking Utilities documentation specifies that in the Permissions
file, the MACHINE and LOGNAME entries may be combined into a single
entry. If this is done, neither machine can contact the other, the error
being Remote Reject After Login. It may be significant that the
permissions have been specified as relaxed as possible, i.e. so that
each machine has total access to the other. Splitting the Permissions
entries apart results in successful communication.
 
 
Ray Brownrigg
Applied Mathematics Division
DSIR (Department of Scientific and Industrial Research)
Wellington
New Zealand
 
UUCP:	...!alberta!calgary!mcewan	(U of Calgary)
or	...!seismo!munnari!natmlab!dsir	(Sydney, Australia, which
					doesn't get mod.micro.att)
or 	...!seismo!munnari!vuw90x!ray	(Victoria University of
					Wellington, New Zealand, which
					doesn't either)