RAF@NIHCU.BITNET ("Roger Fajman") (09/02/88)
Since the topic of communications servers has come up, it seems like a good time to throw out my request for recommendations. We currently have a Bridge CS/1 with 32 ports that is hooked up to our IBM mainframe as a milking machine. We are talking 37x5 async ports, not protocol converters. Our biggest complaint about the Bridge CS/1 is that it does not negotiate the Telnet echo option correctly. It says that it will echo and then expects the host to do it. The problem is that our host does not echo, so the user must manually turn on echoing at their end. The other problem with the CS/1 is that it is only 32 ports. We will need a lot more in the future. The CS/1 can be configured with 64 ports, but then does not provode all the modem control signals that we need. So far, 3Com/Bridge has not been very responsive in coming up with a solution to the echo problem. The cisco ASM communications server sounded attractive because it supports up to 96 ports and they say that they do the echo negotiation properly. So we got one in to test and found out in trying to figure out how to configure it that it does not support all of the necessary modem control signals. We need DSR and DCD to come up at the start of a connection and go down at the end. A connection must be broken when the host lowers DTR. And CTS must be lowered when the communications server can't accept more data from the host (our host doesn't support XON/XOFF flow control). Unfortunately, the cisco box can't do flow control on CTS when it is doing the other modem control signals. So we sent it back. So, does anyone have any recommedations for other communications servers for us to look at? We need lots of ports, proper echo negotiation, support for break signals, and full modem control, including hardware flow control. Don't tell me to junk the mainframe. :-)
haas@utah-gr.UUCP (Walt Haas) (09/24/88)
Roger Fajman (RAF@NIHCU.BITNET) writes: > ...We currently have a Bridge CS/1 with 32 ports that is hooked up to our > IBM mainframe as a milking machine... Our biggest complaint about the > Bridge CS/1 is that it does not negotiate the Telnet option correctly. It > says that it will echo and then expects the host to do it. The problem is > that our host does not echo, so the user must manually turn on echoing at > their end... We received from 3com/Bridge a model CS/1 running release 20000 of their TCP software for evaluation. When I TELNET to it from cs.utah.edu, a VAX 8600 running 4.3 BSD, the following actual TELNET parameter negotiation occurs (as observed with an Ethernet monitor): CS/1: WILL SUPPRESS-GO-AHEAD DO SUPPRESS-GO-AHEAD WILL TRANSMIT-BINARY DO TRANSMIT-BINARY WILL ECHO VAX: DO SUPPRESS-GO-AHEAD WILL TERMINAL-TYPE CS/1: DONT TERMINAL-TYPE VAX: WILL SUPPRESS-GO-AHEAD DONT TRANSMIT-BINARY WONT TRANSMIT-BINARY DO ECHO VAX: WONT TERMINAL-TYPE The TELNET ECHO option negotiated here indicates that the CS/1 end of the connection will be responsible for any necessary echoing of keystrokes received from the VAX. In our configuration, the host which is being milked by the CS/1 (a Zenith Z-LAN 500 NCU) does the actual echoing, which is exactly as we want it. If however we were milking a host which was not able to echo for some reason, then we would need to be able to tell the CS/1 to send WONT ECHO in the initial TELNET parameter negotiation, which would have the effect of forcing the VAX to echo. In my study of the User's Guide for the CS/1 I failed to find a way to get the CS/1 to do this (that doesn't mean the CS/1 *can't* do this, of course, just that I couldn't figure out the magic words :-). Cheers -- Walt Haas haas@cs.utah.ed utah-cs!haas