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> +----------------------------------------------------------------+