help wrt UUCP between 3B1 OBM and TB

Chris Lewis clewis at
Tue May 7 23:23:44 AEST 1991

Dave Snyder wrote:
|>[about Mike Murphy's friend's failure to connect to a locked Telebit from the OBM]
|I asked the same question about six months ago.  Anyway, the bottom line is...
|the OBM on a 3B1 will not connect to a Telebit if the modem is using locked
|interface speeds.  The only way for an OBM to connect to a Telebit is to have the
|Telebit allow auto-bauding.

Bruce Lilly wrote:
|This is a well-known problem with Telebit modems (at least the TB+) when
|operated with the interface speed locked. The Telebit puts out a
|non-standard signal, which causes the 3B1's built-in modem to receive
|garbage (the 3B1's OBM is rather intolerant of non-standard signals).
|Telebit refers to this bug as "bit-shaving".

|Your options are:
|1)	don't operate the Telebit's with interface speed locked
|2)	try to get Telebit to fix the problem (1-800-TEL-EBIT) (good luck)
|3)	trade in the Telebits for another brand of modem
|4)	use an external modem on the 3B1 which will accept the Telebit's
|	non-standard timing

The phfix program I just posted solved Mike's friend's problem - I just
got e-mail from him thanking me for it.  I've been using it to connect to my
feed (a Sun with a locked speed T2500) for about 5 months.  The principle trick
is the PIOCOVSPD ioctl.  About 6 months ago someone posted something about a OBM
utility that he was writing but hadn't finished and mentioned the PIOCOVSPD ioctl
in passing, which is where I got the idea to try it.  Thank you whoever you

Phfix was written without docs (so I had to guess at the invocations) to
solve the TB problem as well as for some reason the builtin software could
no longer set the modem to tone dial.  It could use some cleanup by someone
who knows the right ioctl invocations.  On my system I've installed the
invocation of phfix in the /etc/rc near the end.  It seems to work
"permanently" - ie: it only has to be invoked once on boot.

However, I seem to remember someone telling me that phfix will not work
with HDB UUCP on the 3b1 because HDB clobbers the setting each time it
starts.  However, I've experimented a bit, and have found that you
can invoke phfix *during* the uucico run to clear the problem.  Ie:
you start up uucico, and you notice that it's starting to alarm out -
at this point you can invoke phfix and the uucico will resync and continue
normally.  So, you might be able to kludge in a mechanism by which
phfix is invoked a fixed time after you've fired up uucico.  Alternately,
you could modify phfix into a "daemon" to sit quiescent, stat'ing (or access())
the LCK* file[s] for the TB sites every 30 seconds or so.  Once it notices a
LCK file for the site[s] that has the locked speed TB, then it starts
PIOCOVSPD'ing the OBM every 10-15 seconds for 2 minutes.  That oughta fix it
without putting too much load on the machine.  Alternately, those guys
who seem to like doing binary debugging might want to work out a binary
patch for HDB.

I'll be installing HDB one of these days, so maybe I'll get to
kludge phfix.

Further, it may very well be that phfix will work "normally" even with
HDB for incoming calls - because the uucico on the receiving side is
unlikely to be as "violent" with its ioctls.

If anybody alters phfix.c into a HDB daemon, or simply cleans it up, please
let me know.

BTW: My feed has informed me that he's set his TB to lock at 1200
when it calls my 3b1.  He doesn't remember why he did that.  But it
is certainly locked at 9600 (or is it 19200 I disremember) when I call
his TB.
Chris Lewis, Phone: (613) 832-0541, Domain: clewis at
UUCP: ...!cunews!latour!ecicrl!clewis; Ferret Mailing List:
ferret-request at eci386; Psroff (not Adobe Transcript) enquiries:
psroff-request at eci386 or Canada 416-832-0541.  Psroff 3.0 in c.s.u soon!

More information about the Comp.sys.3b1 mailing list