[comp.unix.ultrix] connection between 2 ultrix machines with null cable

bjanell@intvax.UUCP (Benjamin J. Anello ) (05/15/91)

I am having a problem getting a connection between two ultrix computers.
My ultimate goal is to use uucp between these systems.  It seems that
I can get the connection to work if I reboot 1 machine but after a few
connections, the characters only travel in one direction (ie: I can send
characters but I can't receive them.)  I've got shared set on the
terminal line and the getty process is running (in fact, I caught the
receiving machine out of getty and into login) but my sending host still
acts like it is not receiving the login prompt (using uucico with the
flags -r1 and -x9).  It still looks for ogin:.

Is there something out there that locks terminal lines such that they
receive characters and not send any?  Any help would be appreciated :)

Thanks

BJA

lan_csse@netrix.nac.dec.com (CSSE LAN Test Account) (05/24/91)

In article <3751@intvax.UUCP> bjanell@intvax.UUCP (Benjamin J. Anello ) writes:
>I am having a problem getting a connection between two ultrix computers.
>My ultimate goal is to use uucp between these systems.  It seems that
>I can get the connection to work if I reboot 1 machine but after a few
>connections, the characters only travel in one direction (ie: I can send
>characters but I can't receive them.)  I've got shared set on the
>terminal line and the getty process is running (in fact, I caught the
>receiving machine out of getty and into login) but my sending host still
>acts like it is not receiving the login prompt (using uucico with the
>flags -r1 and -x9).  It still looks for ogin:.

About 90% of the time this problem (which bites SLIP as badly as it does
UUCP) is due to one of the components of the link (usually a modem) having
software flow control (^S/^Q, aka XON/XOFF) enabled.  It doesn't take long
for a binary protocol like UUCP or SLIP to send a ^S down the line, and
then things sorta stop.  Or sometimes they don't stop, but any ^S gets
dropped from the packet, and retransmission doesn't help.  There shouldn't
be a ^S in the login exchange, but once flow control has been enabled,
you'd be surprised at how often they get generated.

In another 9% of the cases, it's because a modem is being used in both
directions, and a lot of them don't like this.  I have a CDS-296 and a
Codex-2264 here, and both have the property that if you make a call out
through them, then they won't respond to incoming calls until you turn
them off and back on again.  I don't know why this is.  There's no hint
of it in the manuals, and all the registers seem unchanged.  When I ask
their respective CS people, they act like I'm crazy for even considering
using an outgoing modem for incoming calls.  Well, maybe I am crazy...

Then there's the last 1% of the cases that are inexplicable...

+----------------------------------------------------------------+
Reply-to: John Chambers <jc@sppip7.lkg.dec.com> or <ub40.enet::jc> 
+----------------------------------------------------------------+