mcewan@calgary.UUCP (Duncan McEwan) (04/18/86)
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)
edward@ukecc.UUCP (Edward C. Bennett) (04/22/86)
All this raises the more useful question: 1. Can the 3B2 control its outgoing DTR signal? 2. Can a tty port be opened without the incoming CD signal being high? -- Edward C. Bennett UUCP: ihnp4!cbosgd!ukma!ukecc!edward Kentucky: The state that is being dragged, kicking and screaming, into the 20th century. "Goodnight M.A."
rt@cpsc53.UUCP (Ron Thompson) (04/29/86)
> > All this raises the more useful question: > > 1. Can the 3B2 control its outgoing DTR signal? Let's see if I can get this right- The open raises it, setting BAUD to 0 lowers DTR. It can't be made to go high again without a close and successive open. > > 2. Can a tty port be opened without the incoming CD signal > being high? I think the flag NODELAY (spelling), for the open does this. -- Ron Thompson AT&T Information Systems Customer Programming (404) 982-4217 Atlanta, Georgia Services Center ..{ihnp4,akgua}!cpsc53!rt (Opinions expressed are mine alone.)