Path: utzoo!utgpu!water!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!mailrus!ames!oliveb!pyramid!fmsrl7!mibte!teemc!wayne
From: wayne@teemc.UUCP (//ichael R. //ayne)
Newsgroups: comp.dcom.modems
Subject: Re: Trailblazer Bugs (was Trailblazer, Misc)
Message-ID: <1084@teemc.UUCP>
Date: 22 May 88 05:43:42 GMT
References: <10273@ulysses.homer.nj.att.com> <10277@ulysses.homer.nj.att.com> <9999@tekecs.TEK.COM> <1186@neoucom.UUCP>
Reply-To: wayne@teemc.UUCP (/\/\ichael R. \/\/ayne)
Organization: TMC & Associates, Troy, MI
Lines: 42

In article <1186@neoucom.UUCP> wtm@neoucom.UUCP writes:
>
->At the moment, I am "stuck" using an aged TB, version 3.  I've
->found that uucp is broken when some other machine dials in at 1200
->or 2400 baud.  I can only get one C or D file though per call which
->means that it takes an awful long time to get mail through!!  What
->happens is that the first file gets though, and then uucp returns
->to control state to begin the next file and then fails a checksum
->on the first packet.  It seems like there is some risidual of the
->spoofing alogorithm that is munging up uucp at the lower speeds
->when there should be no spoofing at all.
->
->We sent the TB+, version 4 down to Mark Horton, so I can't currently
->verify if this bug in in the newer firmware.  Sure is aggrivating,
->though!  I've tried just about every combination I can think of,
->with and without MNP, etc, but they always gag on uucp at 1200 or
->2400.  Normal interactive person-typing-at-a-CRT type calls seem to
->be just fine at the lower speeds.  Uucp seemed to work OK when
->regular old Hayes were swapped back in on the connection.
->
->I guess the Trailblazer is kind of like a mother in law; you just
->gotta love it anyway, despite the quirks.

	There is most likely nothing wrong with your TB except for some
bad S register settings (and a lack of documentation).  I had exactly the
same complaint when I set mine up (Mike Ballard at Telebit should remember
this one well).  I suspect that what is happening is that you are using
SOFTWARE (Xon/Xoff) flow control and are not locking interface speeds (ie
you run your getty at 19200 or 9600 baud all the time).  This all SEEMS
reasonable from reading the manual but the poor TB is getting info from
your machine at high speeds and trying to spit it out at 1200 baud.  Since
it can not do hardware flow control, it sends an Xoff which screws uucp "g"
protocol up badly.  Presuming that you can not do H/W flow control, you 
need to make your getty autobaud and have the TB set the RS232 port speed
based on the tone set it uses.  There is also an undocumented S register
setting which I do not have handy (and my TB's are busy NEWSing).  Calling
Telebit (800 TEL-EBIT) tech support should solve this one rapidly.

/\/\ \/\/
-- 
Michael R. Wayne      ---      TMC & Associates      ---      wayne@teemc.uucp
INTERNET: wayne%teemc.uucp@umix.cc.umich.edu            uunet!umix!teemc!wayne