Path: utzoo!mnetor!uunet!seismo!sundc!pitstop!sun!decwrl!labrea!rutgers!psuvax1!vu-vlsi!cbmvax!grr From: grr@cbmvax.UUCP (George Robbins) Newsgroups: comp.dcom.modems Subject: Re: Connecting a TrailBlazer to a Sun 3/280 Message-ID: <3238@cbmvax.UUCP> Date: 30 Jan 88 21:18:28 GMT References: <218@coherent.uucp> Reply-To: grr@cbmvax.UUCP (George Robbins) Distribution: comp Organization: Commodore Technology, West Chester, PA Lines: 124 Keywords: TrailBlazer Sun uucp CTS flow control In article <218@coherent.uucp> dplatt@coherent.uucp (Dave Platt) writes: > > 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. I've been doing pretty much the same work with trying to get the telebit modems to work nicely with ultrix. Here are a few of my observations / comments on your message. 1) The Telebit autobauding has got to be improved! At high speeds, it seems like it needs to "think" about the "A" in the AT sequence and just blasting an "ATxxx" at it at 9600/19200 baud doesn't do any good. Ultrix uucico sends a a series of pre-dial stuff with sleeps in between - +++ ATH ATZ +++ ATDT... - so I was able to patch the second, generally redundant, +++ to send a single "A", which worked pretty well. 2) The S50/S92 mode arbitration seems to be a catch 22. If the remote site (like uunet) has S92 set to 1 to minimize problems with incoming calls from slow modems, the only way to establish a PEP session is for me to put an "ATS50=255" in the dialing sequence somewhere. Unforturnatly, Ultrix likes to translate = to some other character! So, I kludged the +++ stuff above to send +++ ATZ A ATS50=255 ATDT (the ATS50 has to be separate so that our USR modems don't toss the entire dial string), but now if I use the Telebit to call a dumb modem, it tries to get a PEP connection and reports no carrier! 3) Telebit could/should fix this in two ways - a) let S50=254 mean "set transmission mode appropriate to selected or auto-bauded interface data rate" b) let S50=255 mean "try to establish PEP call, but fall back if dumb modem on the far end". I don't see why both of these couldn't be done. In fact it's kind of hard to believe S50=255 doesn't work as in (b), so I'll have to try it again. 4) It's fairly easy to fix the "uucp doesn't support 19200 baud" problem. If your uucp isn't stripped, it's a table of ints (longs) called spds set up as pairs of baud/stty codes, so pick on you don't like and change it to 19200/14 (decimal please). If your uucp is stripped, the table is right near the beginng of the data section, so you can use $m to find where the data section begins, then just page thru with ?d until you see a sequnece of 50...75...110...200...300 numbers. 5) Make sure your inteface a) supports 19200 baud hardware wise, and b) doesn't loose skillions of incoming character at high baud rates. For example, DEC DZ11's don't support 19200 baud. There are lots of systems that will choke on 19200 incoming, especially under heavily loaded conditions or when some other bottleneck is invoked, perhaps during disk dma or some poorly implemented kernal sequence with interrupts disabled. 6) I was kind of suprised by the relative lack of user friendly/flex dialing stuff in the command set as compared to my 2-year old USR Courier 2400 modems. Still, given a choice, I guess I'd rather have the ROM's full of high-speed / performance code than friendlies. 7) The setups that Rick Adams posted a while ago are hopelessy optimistic. Many versions of uucp available to the non-source licensed crowd dont't support any hayes auto-dial or if they do, don't include the provisions for putting dialer commands in the L-devices file. In thise case, the only recourse is to set up the line as a direct connection "DIR" and put the dialing commands in the send/expect script. Many uucp's even lack the \r and \d escapes for sending return and delays, making life even more difficult. If your uucp doesn't support \c, it's adb time. 9) Here is some info on how to setup uucp connections with a Trailblazer or other "Hayes" type modem when you are blessed with a "stupid uucp": It assumes that you have "modem control" on the port your modem is connected to and that the modem is set up to "Hangup" and hopefully "Reset Parameters" when DTR is dropped. If you don't have this degree of modem control you're playing a dangerous (phone bill) game without built-in Hayes support to send the +++ ATH commands to terminate calls. The resulting L.sys file is going to look remakably ugly, but as long as it works, who cares. You can embelish on the script, but it's best to stick to the simplest script that works reliably. Trying to be fancy will just make it harder to get working and more fragile when it comes to different modems or funny connection behaviour on the far end. Here is a typical L-devices entry: (check your uucp documentation) DIR ttyd0 0 19200 Here is a typical "stupid uucp" L.sys sequence: fishvax Any,15 ttyd0 19200 ttyd0 the autobaud/break stuff and login stuff are no different from the usual brain pain, so I'll just list a typical dialing sequence vertically: "" A\c expect nothing/anything, send "A" with no carriage return. "" \c "" \c expect nothing/anything, send nothing - a kludgy way to get a delay if your uucp doesn't support \d. If it does, just put a \d in the above sequence. Repeat as needed to generate enough delay. If this doesn't work try 'foo-\c-""' which should mean expect foo, timeout many seconds, send nothing, expect nothing/anything. "" ATS50=255DT19995551212^M\c Expect nothing/anything, send dial command / carriage return. Note that the ^M represents a control/M literally inserted in the file via ^v^m in via or thru clever use of "tr" if you can't get an editor to handle the task - use \r it if works!!! CONNECT Expect CONNECT, otherwise timeout and abort the call. At this point, your fall into your "normal" send/expect sequences needed for any auto-bauding on the remote system, followed by the send/expect sequences for the login/password. Use the hints for ^M and delay generation as needed to meet any perverse autobauding requirements. -- George Robbins - now working for, uucp: {uunet|ihnp4|rutgers}!cbmvax!grr but no way officially representing arpa: cbmvax!grr@uunet.uu.net Commodore, Engineering Department fone: 215-431-9255 (only by moonlite)