Path: utzoo!utgpu!water!watmath!clyde!rutgers!sri-spam!ames!amdcad!sun!coherent!dplatt From: dplatt@coherent.uucp (Dave Platt) Newsgroups: comp.dcom.modems Subject: Connecting a TrailBlazer to a Sun 3/280 Keywords: Sun TrailBlazer BSD uucp flow control 19200 Message-ID: <272@coherent.uucp> Date: 1 Feb 88 19:16:09 GMT Distribution: comp Organization: Coherent Thought Inc., Palo Alto CA Lines: 141 After some a couple of days of fiddling around, trying options, and muttering arcane curses directed at both hardware and software, I've managed to establish a successful and reliable marriage between our new TrailBlazer Plus modem and our Sun 3/280 file-server. We're now using the 'Blazer for uucp dialout into other 'Blazer modems as well as into V.22bis (2400-baud) and 212 (1200-baud) modems, and are also answering calls from another 'Blazer at Ames. I'm posting a short summary of our configuration for the benefit of others who may be establishing similar hookups. First issue: we wanted to lock the modem-to-host communication link to 19200 baud in order to achieve maximum throughput. Unfortunately, Sun's obsolete uucp software does not recognize 19200 as a valid speed. telebit!mike forwarded to me the instructions for patching uucico to establish a 19200-baud speed (the 4800-baud speed is sacrificed to make this possible); here's what must be done: ------------------------------------------ Date: Thu, 6 Aug 87 17:24:46 PDT From: gnu (John Gilmore) Message-Id: <8708070024.AA28084@hoptoad.uucp> To: sun!mclinger Subject: SunOS 3.3 uucp patch to support 19200 baud This patch to /usr/lib/uucp/uucico allows it to parse '19200' as a valid speed for dialing out (in L.sys and L-devices). There is a table which consists of pairs of ints, e.g. 9600 and B9600 (13). This patch replaces the entry for 4800, B4800 (12) with 19200, B19200 (14). Be sure to check the permissions and ownerships of uucico and restore them after patching. To locate the 4800 baud entry, you can do: adb -w /usr/lib/uucp/uucico 20000?L 0t4800 This should display an address. On hoptoad (68020 version) this address is 20A0C. To display that table entry, you can do: ?DD it should say: xxxxxx: 4800 12 to patch it, ?W 0t19200 0t14 Don't forget the 0t's, which say these numbers are in decimal. You're done, type ^D and try it. ------------------------------------------ The SunOS 3.3 patch that John suggests works fine on SunOS 3.4 as well. With this patch in place, the 'Blazer's DTE can be locked to 19200 baud for both incoming and outgoing calls (S51=254, S66=1). In order to accept incoming calls at 19200 baud, it's necessary to add a new entry to /etc/gettytab (I called it "T") and to modify the ttyd0 (or whichever) entry in /etc/ttys to read "1T". It's also necessary to set the Sun kernel's configuration flags for the port to the "require hardware carrier detect" position, and to configure the modem with S53=1 so that the hardware carrier-detect signal is sent to the Sun only when carrier is actually received from the remote modem. For security reasons, we decided to prevent the 'Blazer from answering calls in other than PEP mode, so that "crackers" with 300/1200/2400-baud modems could not attempt to log into our system. This was done by setting S50=255. In order to ensure that the modem reset itself to a stable configuration between calls, we set S52=2; when the Sun drops DTR at the end of each call, the modem hangs up (if it hasn't done so already) and resets itself to the configuration stored in nonvolatile memory. Because we've set the modem's default configuration to "PEP mode only", we must arrange to re-enable automatic speed detection when we dial a V.22bis or 212 modem. We do this by burying the appropriate S50 command in the dialing sequence in the L.sys file; it's an ugly hack, but it does work. For example, one such sequence looks like: ibuki Any,9 ACUHAYES 19200 5551212;S50=0;d "" \d\r\c in:-""-ogin: foobar We've stored X0 in the modem's default configuration, so that the modem does not send a "52" response (RRING) to the host when it dials a number and hears the phone ring; code 52 completely confuses uucp and causes calls to be terminated with an UNKNOWN DIALER ERROR message. Unfortunately, setting X0 also causes "no dial tone" and "busy" to be reported to the host as a "no carrier" situation, thus making it a bit more difficult to determine why a call wasn't completed; this is an annoyance rather than a real problem. The biggest difficulty I had in getting this configuration to work properly was getting flow control to work properly. Quite simply, Sun hardware and software currently does not support hardware (CTS) flow control; software flow control (XON/XOFF or ENQ/ACK) is useless during uucp connections. This wasn't a problem when our 'Blazer called another 'Blazer in PEP mode, because the modems' use of g-protocol spoofing implements all of the necessary flow control at the uucp-packet level. We did have severe problems when our 'Blazer phoned a 1200- or 2400-baud modem; our uucp would try to send 3 packets at 19200 baud, the 'Blazer would drop CTS partway through the first packet, the Sun wouldn't stop sending the packet, and the 'Blazer dropped the unwanted bytes on the floor. At a result, we never managed to send a single intact packet, and the connection would time out. After many hours of frustration, and a very helpful suggestion by rick@seismo, I achieved a working interface by a very simple trick: I turned flow control OFF at the modem (S58=0, S67=0, S68=0). It turns out that the TrailBlazer is quite capable of buffering up 3 uucp packets' worth of data when operating in emulation mode... but it will only do so if flow control is disabled. If flow control is enabled, the 'Blazer refuses to buffer up more than about 30 bytes of data before it drops CTS, and once it has dropped CTS it apparently refuses to accept more data. This is one detail that isn't documented in the TrailBlazer manual; it should be, I think. For the last few days, our 'Blazer has been talking quite happily with at least three other 'Blazers, a V.22bis, and several 212s. It's very impressive to watch news articles come flowing across the country from uunet at >9600 baud; we can now receive a standard compressed batch of news in about one minute. With today's uunet rates, I believe that the TrailBlazer will pay for itself within six months; it's cutting our per-day newsfeed cost from uunet by almost 50%. This is one amazing piece of hardware/firmware; the folks at Telebit are to be commended for their design and implementation. There are still a couple of rough spots in the interface (easier autobauding, and an X mode that would enable extended result codes but suppress RRING would be useful), but all in all it's really a fantastic piece of work. Thanks, y'all at Telebit! -- Dave Platt UUCP: ...!{ames,sun,uunet}!coherent!dplatt Internet: coherent!dplatt@ames.arpa, ...@sun.com, ...@uunet.uu.net