wmark@wb3ffv.ampr.org (Mark Winsor) (02/26/91)
We currently have rfs between two att machines. I was wondering if there was a way to get uucp to use the devices on the second machine (/mach2/dev/tty43) for example. It appears to me that it assumes all devices are in /dev. Any way around this? Thanks, Mark S. Winsor ProVAR, Inc.
les@chinet.chi.il.us (Leslie Mikesell) (03/01/91)
In article <3816@wb3ffv.ampr.org> wmark@wb3ffv.ampr.org (Mark Winsor) writes: >We currently have rfs between two att machines. I was wondering if there was >a way to get uucp to use the devices on the second machine (/mach2/dev/tty43) >for example. It appears to me that it assumes all devices are in /dev. Any >way around this? I just tried this with some '386 machines and it came remarkably close to working. I just used the full pathname of the mounted device in the Devices file and it found it just fine. Apparently uucico and cu place kernel locks on the device itself, because attempting to access the same device from both machines resulted in error "filelock: F_SETLK failed". Cu seemed to work just fine on the RFS'ed device. However, using uucp I would get logged into a remote machine and then uucico would fail after the protocol handshake. rmesg - 'P' got PGed wmesg 'U'g ASSERT ERROR (uucico) pid: 422 (2/28-14:08:54) PKXSTART ret (-1) [File: pk1.c, LINE: 338] Does anyone know what this means? Do some kinds of ioctl()'s not work over RFS even among the same kind of machines, perhaps? (This is with the stock uucp that comes with AT&T's SysVr3.2). Les Mikesell les@chinet.chi.il.us
les@chinet.chi.il.us (Leslie Mikesell) (03/02/91)
In article <1991Feb28.202549.6856@chinet.chi.il.us> les@chinet.chi.il.us (Leslie Mikesell) writes: [Following up my own article about cu/uucp accessing remote tty via RFS] >I just tried this with some '386 machines and it came remarkably close >to working. And now I've tried it with 3B2's and it doesn't come quite as close to working there. The modems are set to only assert carrier detect when a connection is made (the only correct way...) and the Dialer scripts use the \M \m tokens to control CLOCAL while dialing. The dialer goes through the motions of setting CLOCAL, then immediately fails with "lost line" anyway. Seems strange that a large amount of effort has gone into making HDB recognize remote devices and it still was released without working right. Does anyone have an explanation? Am I the first one outside of AT&T to even try using it? Les Mikesell les@chinet.chi.il.us