Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!bcm!dimacs.rutgers.edu!aramis.rutgers.edu!athos.rutgers.edu!hedrick From: hedrick@athos.rutgers.edu (Charles Hedrick) Newsgroups: comp.dcom.lans Subject: Re: Looking for terminal server recommendations Message-ID: Date: 15 Jan 91 04:18:18 GMT References: <429@sickkids.UUCP> <89273@lll-winken.LLNL.GOV> Organization: Rutgers Univ., New Brunswick, N.J. Lines: 19 | (3) Provide multi-speed support, and other useful functionality, with | dialout modems. >Not a chance. ... Even if you modified your kernel to allow these >ioctl's against socket connections, there's nothing that could be done >with them since there's no way to pass them down the TCP stream to the >terminal server. May I remind you of RFC 1079. It was invented for this specific purpose. Actually we don't use it for dialout modems, but for a speed-matching problem that involves details you don't want to know, but it does what you want. Cisco terminal servers implement it. So if the software that opens the connection to the terminal server sends the right telnet negotiations, you can get speed change to happen. However I suspect a solution that would work for more vendors would be to use SNMP to set the speed. I don't think this is in the official MIB, but it's a sufficiently obvious thing that I'd expect terminal server vendors to support it in their private MIB's. (Cisco seems to, though I admit I haven't tried it.)