Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!think.com!sdd.hp.com!elroy.jpl.nasa.gov!decwrl!deccrl!news.crl.dec.com!nntpd.lkg.dec.com!netrix.nac.dec.com!lan_csse From: lan_csse@netrix.nac.dec.com (CSSE LAN Test Account) Newsgroups: comp.unix.ultrix Subject: Re: connection between 2 ultrix machines with null cable Keywords: serial getty login terminal problem bug Message-ID: <22897@shlump.lkg.dec.com> Date: 24 May 91 16:09:11 GMT References: <3751@intvax.UUCP> Sender: news@shlump.lkg.dec.com Distribution: usa Organization: Digital Equipment Lines: 34 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 or +----------------------------------------------------------------+