Path: utzoo!mnetor!uunet!coherent!dplatt From: dplatt@coherent.uucp (Dave Platt) Newsgroups: comp.dcom.modems Subject: Re: Connecting a TrailBlazer to a Sun 3/280 Message-ID: <539@coherent.uucp> Date: 3 Feb 88 19:57:29 GMT References: <218@coherent.uucp> <3238@cbmvax.UUCP> Reply-To: dplatt@coherent.UUCP (Dave Platt) Distribution: comp Organization: Coherent Thought Inc., Palo Alto CA Lines: 68 Keywords: TrailBlazer Sun uucp CTS flow control In article <3238@cbmvax.UUCP> grr@cbmvax.UUCP (George Robbins) writes: > > 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. I'm afraid that S50/S92 is, indeed, a Catch 22 situation, especially if you cannot embed an S50=xxx command in your dialing string. Putting S50=255 in your modem-init string, as you appear to have done, will certainly cause you problems when you call "dumb" modems, because the 'Blazer will ignore 212/V.22bis answer tones. Ultrix's habit of translating "=" to a "pause" is a big misfeature, and deserves to be disabled. I'm afraid that your suggestion in 3(b) may be impossible to implement. There are three basic classes of modems that you may wish to call: a) 'Blazers set with S92=0. b) 'Blazers set with S92=1. c) Slower (103/212/V.22bis) modems. If you're calling modems in classes (a) or (c), you can set S50=0 and establish connections with no problem. As you've pointed out, calling a modem in class (b) is the problem... your 'Blazer must be set to ignore the 212/V.22bis answer tone at the beginning of the sequence, and wait until it hears the PEP answer-scream. Unfortunately, it may not be possible for a single 'Blazer setting to call modems in all three of these classes. The real problem comes when you dial a slower (non-PEP) modem. If you wait long enough to see whether the modem you've called is a 'Blazer with S92=1 (i.e. you ignore the first 20-30 seconds of 212/V.22bis/V.22 answer signal), then a real 212/V.22bis modem will probably decide that it has been answering for long enough, and will hang up the phone! As I recall, 212/V.22bis modems tend to send only about 20 seconds of answer signal before timing out... they typically won't remain off-hook long enough for a 'Blazer to wait 30-40 seconds for a PEP answer and then attempt to fall back. With respect to your suggestion in (3a): I'd agree that a "set connection mode based on selected interface speed" mode could be useful, but I'd rather see it assigned to a number other than S50=254; I find S50=254 to be very useful as is. Also, in order to make use of this mode in practice, the TrailBlazer's autobauding capability would need to be made much more reliable... I haven't yet found an autobaud sequence that can works reliably at all necessary speeds (1200, 2400, 19200) when blasted at the modem at full connection speed. Rumor has it that Sun is considering porting HoneyDanBer uucp to their systems... if this is true, then it will become much easier for us to write successful-autobaud modem-init sequences. -- Dave Platt UUCP: ...!{ames,sun,uunet}!coherent!dplatt Internet: coherent!dplatt@ames.arpa, ...@sun.com, ...@uunet.uu.net