dyer@spdcc.COM (Steve Dyer) (06/05/89)
I'm considering buying a Cisco terminal server (actually a t-server/router) to replace a SLIP line and hardwired dialins to a machine. I'd like to know whether people have had any success in using Cisco terminal servers for dialin UUCP traffic. I've used UUCP over Annex/rlogin tty lines for over a year without any problems whatsoever. I understand that the rlogin protocol isn't supposed to be transparent, but it was literally never a problem in this particular installation. -- Steve Dyer dyer@ursa-major.spdcc.com aka {ima,harvard,rayssd,linus,m2c}!spdcc!dyer dyer@arktouros.mit.edu
hedrick@geneva.rutgers.edu (Charles Hedrick) (06/05/89)
rutgers.edu is a major UUCP backbone node. All of its dialup UUCP traffic goes through cisco terminal servers. At one point I implemented a modification to uucpd that would allow you to connect directly to it from the terminal server. This would avoid having a telnetd or rlogind sitting there copying characters. I believe we got this code working but I'm not sure we're using it very much. telnetd uses enough CPU time that I think you might want to consider this approach if you expect to do a lot of traffic. In order to get good UUCP performance, you may want to use the "dispatch-timeout" parameter so that you get reasonably full packets. We use 8 for Trailblazers and 35 for other modems. If you are using telnet, you'll want to configure "telnet-transparent" and probably "escape 0" (which makes BREAK the escape character, rather than ^^ followed by x) for those ports. If you share the ports with normal dialins, you can have people send "term download" as part of the login sequence. This does both telnet transparent and escape 0. It is also the command to allow xmodem to work over telnet connections. That gives an 8-bit transparent connection, if used with a BSD telnetd that doesn't have the CRLF bug that was in early versions of 4.3. (telnet-transparent controls how CR is sent. There are several reasonable interpretations of the specs, so they let you control it. I believe telnet-transparent sends it as CR NUL, whereas the default is CR LF. The problem with the default behavior is not the CR LF, which would be OK, but the fact that they ignore any LF's typed in after a CR.) I assume rlogin would do the right thing as well, though you'd still want to change the escape character I think. You indicate that you're going to run SLIP through this. We use cisco's for SLIP. However there are some limitations, at least in software release 7.1: - SLIP is not designed for use as a router. That is, the system on the other end is assumed to be a single PC, not a gateway to another network. There are several subtle things that this affects. - the MTU is 1500, and can't be changed. - at most 2 packets can be queued for output on any given line at a time. If this is exceeded, packets are dropped, without ICMP source quench. This is reasonable for use in a PC environment, where you will set up a small window size anyway.
dyer@spdcc.COM (Steve Dyer) (06/05/89)
In article <Jun.4.21.28.05.1989.675@geneva.rutgers.edu> hedrick@geneva.rutgers.edu (Charles Hedrick) writes: >You indicate that you're going to run SLIP through this. We use >cisco's for SLIP. However there are some limitations, at least in >software release 7.1: I'm thinking of a new product which is supposed to be a combination terminal server/router. Hopefully their router would be using some private synchronous serial protocol to talk with the Cisco on the other end. The box is going to replace my current setup which uses SLIP. -- Steve Dyer dyer@ursa-major.spdcc.com aka {ima,harvard,rayssd,linus,m2c}!spdcc!dyer dyer@arktouros.mit.edu
henry@utzoo.uucp (Henry Spencer) (06/05/89)
In article <3442@ursa-major.SPDCC.COM> dyer@ursa-major.SPDCC.COM (Steve Dyer) writes: >I understand that the rlogin protocol isn't supposed to be transparent, but >it was literally never a problem in this particular installation. Transparency problems can be very data-specific. Things go along fine with normal traffic until some clever lad decides to use ~~~~~~~~~~~ as a divider line in his mail, at which point the connection dies every time uucico tries to transmit that line. (The troublesome patterns vary, of course, depending on what equipment and software is involved.) Don't assume that you can get away with it in future just because you got away with it in the past. -- You *can* understand sendmail, | Henry Spencer at U of Toronto Zoology but it's not worth it. -Collyer| uunet!attcan!utzoo!henry henry@zoo.toronto.edu
dyer@spdcc.COM (Steve Dyer) (06/06/89)
In article <1989Jun5.162118.10240@utzoo.uucp> henry@utzoo.uucp (Henry Spencer) writes: >Transparency problems can be very data-specific. [...]Don't assume that you >can get away with it in future just because you got away with it in the past. Yeah, thanks for the sermon. -- Steve Dyer dyer@ursa-major.spdcc.com aka {ima,harvard,rayssd,linus,m2c}!spdcc!dyer dyer@arktouros.mit.edu
henry@utzoo.uucp (Henry Spencer) (06/06/89)
In article <3449@ursa-major.SPDCC.COM> dyer@ursa-major.spdcc.COM (Steve Dyer) writes: >>Transparency problems can be very data-specific. [...]Don't assume that you >>can get away with it in future just because you got away with it in the past. > >Yeah, thanks for the sermon. You're welcome. No charge. :-) Seriously, this is a real problem that I and others have encountered in the field: somebody tests his "transparent" channel with one or two simple test files and assumes it works, and it does, until the right data pattern comes along... at which time anything from a crash/reboot to a hung channel occurs. And occurs again. And again. And again. It may sound so dumb that nobody would ever do it; not so. -- You *can* understand sendmail, | Henry Spencer at U of Toronto Zoology but it's not worth it. -Collyer| uunet!attcan!utzoo!henry henry@zoo.toronto.edu
ron@ron.rutgers.edu (Ron Natalie) (06/06/89)
All of our UUCP connections come in over CISCO terminal servers. We've been doing so for over a year with both the trailblazers and the Vadic modems. It works a whole lot better than the Sun ALM card we were using before. The only thing (you've probably noticed this if you are using Annex servers already) is that some UUCP hosts don't hang up the phone after the UUCP protocol ends. Our host hangs up our end and that returns the user to the terminal server prompt. We just set the time outs for people stairing at the prompt without being connected very short on those lines. -Ron