Path: utzoo!mnetor!uunet!coherent!dplatt From: dplatt@coherent.uucp (Dave Platt) Newsgroups: comp.dcom.modems Subject: Connecting a TrailBlazer to a Sun 3/280 Message-ID: <218@coherent.uucp> Date: 29 Jan 88 21:05:53 GMT Distribution: comp Organization: Coherent Thought Inc., Palo Alto CA Lines: 199 Keywords: TrailBlazer Sun uucp CTS flow control The following is a message I mailed to telebit!mike last week concerning my experiences in connecting a TrailBlazer Plus to our Sun file/news server. My experiences may prove useful to other people who are attempting to establish similar connections. Updates at the end... --- begin letter -- 1/22/88 I spent all of yesterday attempting to establish a viable Sun/Trailblazer marriage. At this point, I can report partial success (PEP connections to uunet are stunningly effective), great frustration, and some specific recommendations for simple enhancements to the TrailBlazer that would greatly ease this sort of task. Background: we have a Sun 3/280 system, which (like almost all Sun systems) does not support CTS flow-control on its serial ports. [May legions of stinging ants infest the jockey shorts of the engineers and managers who promulgate this revolting design philosophy!]. Our neighbors (sun, ames, ibuki, and uunet) run a mixed bag of modems: - ibuki is 1200-baud only - sun has a TrailBlazer configured with S92=0 [normal answering sequence] and a V.22bis-baud modem. - ames has a TrailBlazer configured with S92=1 [reverse answering sequence, with PEP tones after V.22/212 tones], a V.22bis (U.S. Rotobics) and a rotor full of 212s. - uunet has a rotor of TrailBlazers configured with S92=1. The faster modems at sun and ames are frequently busy, and so we'd like to fall back and use the slower ones when necessary. Naturally, we want the 'Blazer-to-'Blazer connections to use PEP even if the receiving modem has S92=1. I was able to achieve the latter by burying an S50=255 in the 'Blazer dialing sequences; the modem resets to S50=0 when DTR is dropped at the end of a connection. Specific problems encountered so far: 1) We'd really prefer to leave our DTE-to-'Blazer connection set to 9600 baud (can't use 19200 'cause Sun UUCP doesn't recognize it... grrr.) Unfortunately, we run into flow-control problems when the 'Blazer connects to a V.22bis or 212. The Sun doesn't honor CTS flow control, and we cannot use XON/XOFF or ENQ/ACK flow control under UUCP (which is an 8-bit, transparent-link protocol). The net result is that locking the DTE speed to 9600 baud causes UUCP conversations to fail. This is rather embarrassing... I had assumed that the 'Blazer would be capable of buffering up three full uucp packets, and wouldn't have to drop CTS. The U.S. Robotics 2400e is quite capable of doing this, and we had successfully run uucp at 1200 and 2400 baud with the DTE link locked at 4800 baud. I spoke with Bob Boynton (Telebit tech. support) yesterday afternoon, and he informed me that the 'Blazer deliberately limits its buffering to 30 bytes when in emulation mode. ** Recommendation #1: increase the amount of buffering done in emulation mode to at least 256 bytes. Perhaps the amount of buffering done should depend on the S111 (async protocol support) setting: 256 bytes for uucp, and at least 1024 for xmodem/ymodem and Kermit. This would greatly improve the 'Blazer's ability to arbitrate between a dumb, high-speed DTE link and a lower-speed remote modem. 2) Next, I tried unlocking the DTE link, and running it at the speed of the remote modem. This leads to difficulties also, because the 'Blazer requires more autobauding than the standard Hayes "AT" sequence. Our uucp is rather dumb, and doesn't support chat scripts or other intelligent/programmable sequences during modem initialization (e.g. HoneyDanBer uucp's modemcap file). I was able to patch uucico, changing the standard uucico modem-initialization string ("ATQ1E0V0...") into a magic cookie that I thought would autobaud the 'Blazer [and believe me, patching a stripped uucico binary with adb is no fun!]. I tried a magic cookie of "AAAAAAAAAAAAAAT", which works at 9600 baud and at 1200 baud but doesn't seem to work at 2400 baud. I then tried a cookie consisting of a mix of "A" and 0xFF bytes, in the hope that the 0xFF bytes would look like "mark" signals (pauses between characters). This was partially successful; the modified cookie works at 9600 and 2400 baud, but not at 1200 baud. Sigh. ** Recommendation #2: publish the content of an autobaud string that can be sent to the modem ->at any line speed, and with no pauses between characters<-, and will successfully autobaud the modem at any of the speeds that the 'Blazer supports. If no such string exists, then either modify the autobauder to implement one, or publish the requirement for inter-character pauses in the documentation. 3) The next difficulty involves result codes. When our uucp dials out at 2400 baud, it looks at the result code returned from the modem to determine whether it should "roll back" the DTE connection to 1200 baud; this occurs if the remote modem is a 212, rather than a V22.bis. There's a problem, though. If we configure the 'Blazer with ATX1 (return extended result codes) so that it will return a speed-specific result code, then the 'Blazer also insists on sending a non-standard code 52 (RRING), which our uucp doesn't understand and declares to be an "UNKNOWN DIALER ERROR" that terminates the connection attempt. If we configure with ATX0 (basic result codes only), then the 'Blazer returns a result code of 1 for both 1200- and 2400-baud connections, and our uucp incorrectly attempts to roll back to 1200 baud even if the remote modem is a V.22bis. This is another area in which the U.S. Robotics 2400 modem is distinctly friendlier than the 'Blazer. It provides several ATX modes in which extended call-completion result codes are returned, while the "RINGING" code (11) is suppressed. At this point, we're running with ATX1, and accepting the fact that about 50% of our 2400-baud connection attempts are being aborted due to an "UNKNOWN DIALER ERROR" when the 'Blazer reports the RRING code 52. ** Recomendation #3: implement an ATX4 (or some other number) mode in which codes 0-50 are enabled, and 52 is suppressed. Or, implement additional partial-quiet modes that selectively suppress code 52. Our current status is that 9600-baud PEP connections seem to work perfectly; V.22bis connections work erratically, depending on whether the modem sends a code-52 response or not; 212 connections work properly, although we actually issue the dialing sequence at 2400 baud and then roll back to 1200 when the modem connects, because I haven't been able to find a magic cookie that will autobaud the 'Blazer at both 1200 and 2400 baud. At this point, any one of three enhancements would enable us to run reliably at all three speeds: - If we could use CTS flow-control, we could lock the DTE speed to 9600 baud and not lose data. We could use ATX0 (basic result codes) without problems, because our uucp doesn't attempt rollback when connections are dialed at 9600 baud. - If the 'Blazer was capable of buffering 3 uucp packets in V.22bis/212 emulation modes without dropping CTS, then we could lock DTE to 9600 and not lose data. - If the 'Blazer was capable of returning an extended result code when a connection was established, but could be prevented from politely sending code 52 (RRING) during a call, then we could dial both V.22bis and 212 calls at 2400 baud, and fall back to 1200 baud in the latter case. Mike... is there any chance that either a larger emulation-mode buffer, or an improved extended-result-code mode could be implemented, kluged, or patched into our modem? If necessary I'd be glad to drive our modem down to your shop for a PROM replacement. At this point, I'm considering reinstalling our U.S. Robotics 2400e modem on a second serial port, and using it for all of our V.22bis and 212 calls... it seems to be somewhat better suited to medium-speed use at this time. Doing so would require that I move a hardwired 9600-baud link to our neighbor "aimt" to another machine; this would be a major pain in the butt. Summary: the 'Blazer is a very impressive product, with a price that's hard to beat (at the USENET discount rate, at least). It still has a few rough edges that make it a trifle difficult to adapt to dumb hardware and software (e.g. Sun serial ports and obsolete uucp code). [Late flash... Chuq just called to inform me that hardware flow control will be implemented in SunOS 4.0. This would resolve most of our problems, if it actually works... there's some reason to believe that Sun's new ALM (an 8-port serial expander) was designed without CTS support in hardware... in which case the operating-system change will do no good whatsoever for ALM ports.] Thanks for reading and considering this. --- end of letter --- Mike responded to my letter by sending me a small patch to Sun's uucico that eliminates the 4800-baud speed table entry and replaces it with a 19200-baud entry. I haven't tried this yet, but will probably do so next week; this should pep up our netnews connections to uunet and ames by 10-20%. Mike has not yet responded to my questions about changes to the emulation-mode buffering scheme or the result-code selections. I haven't reinstalled our U.S. Robotics 2400e for use at 1200 and 2400 baud; I'll probably do so once Sun deigns to ship us SunOS 3.5 so that we can install our ALM, which will have plenty of spare ports. All in all, I'm very glad that we decided to spring for a 'Blazer. The frustrations s I've experienced in the Sun/'Blazer marriage aren't enough to detract significantly from the wonder of seeing a cross-country uucp connection delivering news at 9600 baud with no pauses! Our uunet connection time has been cut down from over two hours per night (via Tymnet) to an average of about 20 minutes; even given the higher $/hour rate for the uunet 800 number, the switchover will probably save us almost 50% in our uunet hourly charges. The modem should thus pay for itself within six months. Nice work, Telebit! And, with a a little bit of additional polishing, you'll have an incredible gem indeed. -- Dave Platt UUCP: ...!{ames,sun,uunet}!coherent!dplatt Internet: coherent!dplatt@ames.arpa, ...@sun.com, ...@uunet.uu.net