[comp.sys.3b1] OBM <--> Telebit incompatibility: SUMMARY

gst@gnosys.svle.ma.us (Gary S. Trujillo) (02/04/91)

In <1991Jan10.095356.17752@yenta.alb.nm.us> dt@yenta.alb.nm.us
	(David B. Thomas) writes:

> gil@limbic.ssdl.com (Gil Kloepfer Jr.) writes:

...

> > you're locking the interface speed at 19.2Kb, and you call the Telebit
> > with any 1200 baud modem I've conjured-up to use as a test, it fails
> > miserably.  Could this be due to the modems I'm using?  Could be...

> I think so.  I have my telebit locked at 19.2, and I've managed to connect
> to it just fine (at 1200) with my hayes and my apple...

(Sorry to be so late in responding to this thread.  I'm just now clearing
away over a month's backlog of news.)

When I configured my Telebit T2500 for dialin a number of months ago, I
recalled an earlier discussion about problems with calls from OBMs to
Telebit modems - and had experienced the problem myself, using the OBM,
to call a site with a 'blazer, before I got mine.  I recall that the dis-
cussion last time seemed to strongly implicate the stop-bit shaving that
has been talked about here (I think it's the just the stop-bit that gets
shortened, but I could be wrong).

Anyway, though it took a lot of work and fiddling, I did find a way to
configure my T2500 for dialin that permits it to do *true* autobauding
[no BREAKS, CRs, or other characters need to be sent upon initial login]
(thanks to a replacement getty I got from a fellow UNIX-pc'er, who plans
to release the code after some further cleanup), and have been running
it quite successfully ever since - WITHOUT THE INTERFACE SPEED LOCKED
(since it's only when the interface speed is locked that the bit-shaving
occurs - I think the previous discussion concluded).  Just a few minutes
ago, I did a test for the first time that I probably should have tried
long ago - could I dial in from the OBM (which I hardly ever use any more)
and get a clean connection to the T2500?

The answer is YES - on the first try, with no lost or garbaged characters!

My initial reason for not locking the interface speed was as much to permit
dialin callers to be able to abort output with a kill character as much as
it was to accomodate the sensitivity of the OBM to bit timings, but it's
nice to know that it solves both problems.

Just thought you'd like to know.

-- 
    Gary S. Trujillo                            gst@gnosys.svle.ma.us
Somerville, Massachusetts              {wjh12,bu.edu,spdcc,ima,cdp}!gnosys!gst

dave@das13.snide.com (Dave Snyder) (02/05/91)

In article <972@gnosys.svle.ma.us>, gst@gnosys.svle.ma.us (Gary S. Trujillo) writes:
> Anyway, though it took a lot of work and fiddling, I did find a way to
> configure my T2500 for dialin that permits it to do *true* autobauding
> [no BREAKS, CRs, or other characters need to be sent upon initial login]

Sounds good... could you please post or mail the "S" register settings for this
configuration.  Come to think of it, after all the talk of getting an OBM to
talk to a Telebit, NO ONE has post his/her "S" register settings for their
working configuration.  Could some of you others that have a Telebit
successfully interacting with an OBM post your settings.  Thanks!!!

DAS
-- 
David A. Snyder @ Snide Inc. - Folcroft, PA

UUCP:  ..!uunet!das13!dave     INTERNET:  dave@das13.snide.com

gst@gnosys.svle.ma.us (Gary S. Trujillo) (02/07/91)

In article <1479@das13.snide.com>, dave@das13.snide.com (Dave Snyder) writes:

> In article <972@gnosys.svle.ma.us>, gst@gnosys.svle.ma.us
> 	(Gary S. Trujillo) writes:
> 
> > Anyway, though it took a lot of work and fiddling, I did find a way to
> > configure my T2500 for dialin that permits it to do *true* autobauding
> > [no BREAKS, CRs, or other characters need to be sent upon initial login]
> 
> Sounds good... could you please post or mail the "S" register settings for
> this configuration...

Right you are, sir.  Enjoy!

E1 F1 M1 Q6 T V1 W0 X3 Y0 &P0 &T4     Version GA2.00
S00:000 S01=000 S02=043 S03=013 S04=010 S05=008 S06=002 S07=040 S08=002 S09=006
S10=007 S11:050 S12=050 S18=000 S25=005 S26=000 S38=000
S41=000 S45=000 S47=004 S48=000 S49=000
S50=000 S51=255 S52:002         S54:003 S55=000 S56=017 S57=019 S58:002 S59=000
S60=000 S61=150 S62=003 S63=001 S64=000 S65=000 S66=000 S67:001 S68=255 S69=000
S90=000 S91=000 S92:001 S93:004 S94=001 S95=000 S96=001
S100=000 S101=000 S102=000 S104:003 S105=001
S110:000 S111:030 S112=001
S121=000 S130=002 S131:001
S150=000 S151=004 S152=001 S153=001 S154=000 S155=000
S160=010 S161=020 S162=002 S163=003 S164=007 S255=000

-- 
    Gary S. Trujillo                            gst@gnosys.svle.ma.us
Somerville, Massachusetts              {wjh12,bu.edu,spdcc,ima,cdp}!gnosys!gst

tomb@marque.mu.edu (Tom Baas) (02/07/91)

In article <1479@das13.snide.com> dave@das13.snide.com (Dave Snyder) writes:
>In article <972@gnosys.svle.ma.us>, gst@gnosys.svle.ma.us (Gary S. Trujillo) writes:

>> [no BREAKS, CRs, or other characters need to be sent upon initial login]

........
>talk to a Telebit, NO ONE has post his/her "S" register settings for their
>working configuration.  Could some of you others that have a Telebit
>successfully interacting with an OBM post your settings.  Thanks!!!
I second that request.  If you 3b1`rs could post your S-register settings
so that they could be compared, I would certainly take advantage of it
for the Telebit on my 3b1.

Following is some of my setting... any comments? and suggestions?  any other
samples?

E0 F1 M0 Q6 T V1 W0 X3 Y0 &P0 &T5  
S00=001 S01=000 S02:255 S03=013 S04=010 S05=008 S06=002 S07:060 S08=002 09=006
S10=007 S11:050 S12=050 S18=000 S25=005 S38=000 
S41=000 S45:255 S47=004 S48=000 S49=000
S50=000 S51:252 S52:002         S54:003 S55=000 S56=017 S57=019 S58:002 S59=000
S60=000 S61=150 S62=003 S63=001 S64:001 S65=000 S66=000 S67=000 S68=255 S69:001
S90=000 S91=000 S92:001 S94=001 S95=000 S96:000 
S100=000 S101=000 S102=000 S104=000 S105:000 
S110:001 S111:030 S112=001 
S121=000 S130:003 S131:001 S255=000 

tkacik@kyzyl.mi.org (Tom Tkacik) (02/07/91)

In article <1479@das13.snide.com>, dave@das13.snide.com (Dave Snyder) writes:
> Sounds good... could you please post or mail the "S" register settings for this
> configuration.  Come to think of it, after all the talk of getting an OBM to
> talk to a Telebit, NO ONE has post his/her "S" register settings for their
> working configuration.  Could some of you others that have a Telebit
> successfully interacting with an OBM post your settings.  Thanks!!!
> 

For your amusement and edification.

# This is the current configuration for the Telebit T1000 on kyzyl
# It is set up to talk at 19200 baud, for outgoing calls.
# On receiving a call, the interface speed will change to match the connection
#	speed.   (S66=0)
# /etc/inittab has getty answer at 1200 baud, but will cycle up 2400, 19200.
#
# S111=255,  talk whatever protocol the other modem knows.
#	When dialing out the other modem will probably also have S111=255,
#	and no UUCP spoofing will be done.  This is for manual dial out.
#	When UUCP dials out, it will first set S111=30.
#	 (See /usr/lib/uucp/modemcap entry for telebit.)

E1 F1 M1 Q0 P V1 W0 X1 Y0 &P0 &T4     Version FA2.01
S00=001 S01=000 S02=043 S03=013 S04=010 S05=008 S06=002 S07:060 S08=002 S09=006
S10=007 S11=070 S12=050 S18=000 S25=005 S38=000
S41:002 S45=000 S47=004 S48=000 S49=000
S50=000 S51:254 S52:002         S54:002 S55=000 S56=017 S57=019 S58:002 S59=000
S60=000 S61=150 S62=003 S63=001 S64:001 S65=000 S66=000 S67=000 S68=255 S69=000
S90=000 S91=000 S92=000 S94=001 S95=000 S96=001 
S100=000 S101=000 S104=000 
S111=255 S112=001 
S121=000 S130=002 S131:001 S255=001 

-- 
Tom Tkacik                |
tkacik@kyzyl.mi.org       |     To rent this space, call 1-800-555-QUIP.
...!rphroy!kyzyl!tkacik   |

gandrews@netcom.COM (Greg Andrews) (02/08/91)

In article <980@gnosys.svle.ma.us> gst@gnosys.svle.ma.us (Gary S. Trujillo) writes:
> [Gary's modem config that doesn't require sending breaks]
>
>E1 F1 M1 Q6 T V1 W0 X3 Y0 &P0 &T4     Version GA2.00
>S00:000 S01=000 S02=043 S03=013 S04=010 S05=008 S06=002 S07=040 S08=002 S09=006
>S10=007 S11:050 S12=050 S18=000 S25=005 S26=000 S38=000
>S41=000 S45=000 S47=004 S48=000 S49=000
>S50=000 S51=255 S52:002         S54:003 S55=000 S56=017 S57=019 S58:002 S59=000
>S60=000 S61=150 S62=003 S63=001 S64=000 S65=000 S66=000 S67:001 S68=255 S69=000
>S90=000 S91=000 S92:001 S93:004 S94=001 S95=000 S96=001
>S100=000 S101=000 S102=000 S104:003 S105=001
>S110:000 S111:030 S112=001
>S121=000 S130=002 S131:001
>S150=000 S151=004 S152=001 S153=001 S154=000 S155=000
>S160=010 S161=020 S162=002 S163=003 S164=007 S255=000
>

Pretty normal Unix settings...  What did you change to eliminate the
need for breaks?

--
Greg Andrews
gandrews@netcom.COM

rick@kimbal.lynn.ma.us (Rick Kimball) (02/09/91)

From article <23207@netcom.COM>, by gandrews@netcom.COM (Greg Andrews):
> In article <980@gnosys.svle.ma.us> gst@gnosys.svle.ma.us (Gary S. Trujillo) writes:
>> [Gary's modem config that doesn't require sending breaks]
... modem configuration deleted
>>
> 
> Pretty normal Unix settings...  What did you change to eliminate the
> need for breaks?

I don't know for sure but I think Gary is running a different getty
than the one supplied with HDB.  He mailed me a copy a few months ago
but I had problems getting it up and running with the stock UUCP.
I'm sure I could have got it running; I just didn't have any spare
time back then.

Since then I managed to delete the source, but all is not lost.  Karl
Denninger posted a program called autouu.c in the 386 group that
does the same thing.  Instead of running a getty on your modem you
use autouu.

I've included the comments from the begining of the program
below.  The only real change I had to make was with the locking
scheme.  I'm using this with great success with a TB2500.

Give it a try if you like 617 596 0052 ... any baud 8^)

Rick Kimball  |  INTERNET: rick@kimbal.lynn.ma.us
              |      UUCP: ...!spdcc!kimbal!rick, ...!spt!kimbal!rick
              |      POTS: (617) 599-8864
----
/*
 *	Copyright 1990 MCS & Karl Denninger.  All rights reserved.
 *
 *	Public use is permitted under the following conditions:
 *
 *	1) You do not remove my name from the package, or claim you wrote it.
 *	2) You distribute ORIGINAL source code with all distributions made,
 *	   modified or not, binary or source.
 *	3) You do not attempt to sell the package, or use it to enhance the
 *	   commercial value of any product or service.  
 *	4) This package is distributed with ABSOLUTELY NO WARRANTY OF ANY
 *	   KIND.  If it melts your system to slag YOU are responsible, not
 *	   MCS or myself.  The burden rests with you to perform adaquate
 *	   testing before turning this loose on unsuspecting users.
 *
 *	Commercial distribution rights reserved; contact MCS at (708) 808-7200
 *	for details on commercial distribution licensing.
 *
 *	Compile with:  cc -s -o autouu autouu.c -lc_s -lx
 *
 */
/*	Autobaud program 

	Run in place of 'getty', this will prompt for a name
	and call login just like the old one used to do... Only
	difference is that it is rather interesting in it's interpretation
	of what a 'gettydefs' file is; that is, there isn't one.
	
	We use modem return messages to determine the baud rate.  Locks are
	respected as well, allowing the uucp system to share the ports.

	You invoke this with:
		/etc/autonew ttyA2 [code] [file]
	
	from /etc/inittab.  "[code]" is the numeric code for the baud rate
	to send the initialization string at -- most of the time  you want
	this to be the highest baud rate your modem will support.

	Notes:
		1) The device name does not have a prefix.  It is prepended
		   automatically (/dev/ is added).
		2) For ISC, use the MODEM CONTROL PORTS.  This program can
		   interlock with UUCP; see their DEVICES file for the
		   proper flags to set in the DEVICES and DIALERS files.
		   Use the "new" definitions which have ",M" added (see your
		   documentation for details).
		3) While a port is being used for dialout, it will show
		   up in a "who" command as "_Dialout" once data
		   transmission begins.
		4) Modes and owners will be changed on ports to prevent 
		   random users from using the ports for "cu"s and other 
		   communications uses.  This can be easily changed if 
		   desired (look for the "chmod" call in the source).
		5) The file /etc/autobaud.parm must be present if the "file"
		   argument is missing.  If the "file" argument is present,
		   it points to the control file to be used.  The format
		   is as follows:
			First line -- initialization string for ports
			Second line -- response to initialization string
			Third line -- Generic "connected" message
			Up to first "#" alone -- baud codes, rates (text), and
					 response strings expected.
			Next line -- Login prompt
			Remainder of file -- Issue file

			Baud codes are the speed codes from termio.h; 
			11, for example, is 2400 baud.

			An example /etc/autobaud.parm file:
				
			AAATE0Q0V1
			OK
			CONNECTED
			7 300 CONNECT
			9 1200 CONNECT 1200
			11 2400 CONNECT 2400
			13 9600 CONNECT 9600
			14 19200 CONNECT FAST
			#
			Login:

			Welcome to the system
			<EOF>
		
			This is a typical file for a system containing both
			Telebit and low-speed modems (300-2400 baud).  Note
			that the "AAA" is doubled to allow the Telebit to
			autosync.  If you have hardware flow control then
			enable it -- otherwise, set the modem up for
			Xon/Xoff flow control, BREAK is sent and flushes,
			Telebit S66=0 and S58=254 (Autobaud and prefer 
			19200).  This permits full functionality with the 
			exception of low-speed UUCP inbound calls through 
			Telebits; if you have hardware flow control then no
			restrictions apply.
			
		6) Your I/O board and/or drivers MUST correctly support the
		   notion of O_NDELAY.  In addition, you have to be able to
		   turn on and off the NDELAY flag with fcntl.  LOTS of
		   intelligent boards broke this; if it's broken this
		   program will NOT work.  ONE HACK:  If your NDELAY
		   interpretation returns non-blocking if CD is down (with
		   CLOCAL set and NDELAY cleared) this program will function
		   correctly, although it will eat a small portion of CPU
		   time to do so.
		
		7) Autobaud will wait for a carriage return and use it 
		   to determine the parity of the caller's terminal (either
		   8/N/1 or 7/E/1 only).  If the user doesn't press anything
		   within a reasonable time frame, 8/N/1 is assumed.  The
		   message "CONNECTED" is output to the user terminal
		   immediately after autobaud senses the user's baud rate.

		8) All modems served by a configuration must use the same 
	 	   response sequences, although subsets are permitted (ie: the
		   example file above would work for a USR Courier 2400 and
		   a Telebit Trailblazer Plus equally well).

	CHECK THE FUNCTIONS "checklock()" and "makelock()" -- they may need 
	to be modified for your system!  In particular, some systems use 
	binary PIDs and/or store the lock file in a different place.  We 
	currently are set up for HDB UUCP on ISC 2.0.2/2.2.

	Note that this program can share a port with a modem dialing out on
	the same line!  It will perform with uucp on the same port without
	trouble, so long as the locking is done correctly by uucp and other
	programs which expect lock files.

	Autobaud removes any stale lock files it finds automatically.

*/
---

gst@gnosys.svle.ma.us (Gary S. Trujillo) (02/11/91)

In <23207@netcom.COM> gandrews@netcom.COM (Greg Andrews) writes:

>In article <980@gnosys.svle.ma.us> gst@gnosys.svle.ma.us (Gary S. Trujillo) writes:
>> [Gary's modem config that doesn't require sending breaks]

>Pretty normal Unix settings...

Right.  Some of the registers get changed in my HDB initialization file
anyway.  From my "Dialers.TB" file:

tb1200    =W-,    "" \MA\pA\pA\pTZ OK ATS111=30S50=2DTW\T CONNECT\s1200 \m\c
tb2400    =W-,    "" \MA\pA\pA\pTZ OK ATS111=30S50=3DTW\T CONNECT\s2400 \m\c
tb9600    =W-,    "" \MA\pA\pA\pTZ OK ATS111=30S50=255DTW\T CONNECT\sFAST \m\c
tbfast    =W-,    "" \MA\pA\pA\pTZ OK ATS111=30S7=58S50=255DTW\T CONNECT\sFAST-\d\d\c-CONNECT\sFAST \m\c
tb9600v32 =W-,    "" \MA\pA\pA\pTZ OK ATS111=30S50=6S93=20S95=2DTW\T CONNECT\s9600 \m\c

> What did you change to eliminate the need for breaks?

I changed the getty. :-)  That's what does it.  Sorry to be so elusive about
it all, but the author wants me to keep track of who it gets sent to, and I
really don't have time to do so.  If someone else wants to take on the project,
I suspect arrangements can be made.  I'm just too busy to write it all up, but
I'd be willing to supply the necessary information to an interested party to
make it possible.

Any takers?

(The basic notion is that when a connection is established, the getty - which
 is not a real getty, but just a front end - reads the speed code from the
 modem, and then invokes the real getty after having done an ioctl, or it calls
 the getty with the speed as an argument - I forget which.  The modem does hang
 once in a great while (~ once a week, maybe), but that might be caused by
 something else entirely.  It's pretty robust, in all.  I spend a lot of time
 poring over descriptions the various schemes that people are using with HDB
 and/or Telebit modems, and then integrated what I learned with the new getty,
 and after some experimentation, and a little hair-pulling, I got it all
 working pretty nicely - and that was months ago.)

-- 
    Gary S. Trujillo                            gst@gnosys.svle.ma.us
Somerville, Massachusetts              {wjh12,bu.edu,spdcc,ima,cdp}!gnosys!gst

david@twg.com (David S. Herron) (02/18/91)

In article <984@gnosys.svle.ma.us> gst@gnosys.svle.ma.us (Gary S. Trujillo) writes:
>(The basic notion is that when a connection is established, the getty - which
> is not a real getty, but just a front end - reads the speed code from the
> modem, and then invokes the real getty after having done an ioctl, or it calls
> the getty with the speed as an argument - I forget which.

Yes.. that's a fairly simple thing to do ..

but *WHY* do this?  I run mine (3b1 with TB+) with the interface
speed locked at 19200 and have no problem.  The modem simply takes
care of translating any speed difference internally without need
for hacks like BREAK.  I also run with hardware flow control enabled

(yeah, sure, lots of systems use BREAK for switching baud rate .. that
doesn't make it any less of a hack)

-- 
<- David Herron, an MMDF & WIN/MHS guy, <david@twg.com>
<- Formerly: David Herron -- NonResident E-Mail Hack <david@ms.uky.edu>
<-
<-	MS-DOS ... The ultimate computer virus.

dave@das13.snide.com (Dave Snyder) (02/19/91)

In article <8653@gollum.twg.com>, david@twg.com (David S. Herron) writes:
> but *WHY* do this?  I run mine (3b1 with TB+) with the interface
> speed locked at 19200 and have no problem.  The modem simply takes
> care of translating any speed difference internally without need
> for hacks like BREAK.  I also run with hardware flow control enabled
> 
Do you have people calling into your 3B1 with a 3B1 - OBM?  I going to guess
and say you don't.  If you did, they would be complaining about bit shaving
because you have the interface speed locked.  I'd love to lock my interface
speed at 19200 but then people with 3B1's can't call into my telebit with
their OBM.

DAS
-- 
David A. Snyder @ Snide Inc. - Folcroft, PA

UUCP:  ..!uunet!das13!dave     INTERNET:  dave@das13.snide.com

gst@gnosys.svle.ma.us (Gary S. Trujillo) (02/21/91)

In <8653@gollum.twg.com> david@twg.com (David S. Herron) writes:

>In article <984@gnosys.svle.ma.us> gst@gnosys.svle.ma.us
	(Gary S. Trujillo [me] ) writes:

> > [ stuff about autobauding ]

> Yes.. that's a fairly simple thing to do ..

> but *WHY* do this?  I run mine (3b1 with TB+) with the interface
> speed locked at 19200 and have no problem...

Since you ask, I cite two reasons:

  1. With the interface speed locked, UNIXpc OBMs have trouble
     talking to Telebit modems.

  2. It takes forever for an interrupt signal to be acted on with
     interface speed locked, since there's a whole bunch of char-
     acters buffered up in the modem.

-- 
    Gary S. Trujillo                            gst@gnosys.svle.ma.us
Somerville, Massachusetts              {wjh12,bu.edu,spdcc,ima,cdp}!gnosys!gst