Getty for ISC/Telebit T-2500 w/autobaud via the CONNECT msg?

[Dave McLane]

karln at uunet.uu.net writes:

> In article davidg%aegis.or.jp at kyoto-u.ac.jp (Dave McLane) writes:
>
> >about everything you need to set the speed. I modified the orignal
> >getty 2.0 to only lock the speed on a CONNECT with error checking
> >but otherwise let it run free as locking the speed with non-error
> >checking connects really screws up their ability to stop/start
> >scrolling without hideous amounts of overrun (with all modems, but
> >particularly with those like the Telebit which have huge buffers).
>
>    That point about over-run has only been a problem, in my experience,
> when the serial driver/modem is NOT using CTS/RTS hardware flow
> control. For this I was told to get FAS 2.08 as the stock ISC
> asy drivers did not handle it.

Ummm, I think you're thinking about another kind of overrun.

What I'm talkng about is when somebody connects at, say, 2400 BPS 
non-MNP (which means there is no CTS/RTS involved between their 
machine to their modem to my modem) and asks for some long article 
to be sent without any paging. If the Telebit on my system is 
locked at, say, 19,200, it throws stuff at the Telebit at that 
speed while the Telebit is sending it out over the line at only 
2400 BPS. Since the Telebit has a buffer of something like 10K the 
buffer fills up as the speed between my machine is so much faster 
than the speed between the Telebit and the other modem-machine. So 
then the person on the other end sends ^S to stop the flow and my 
system stops sending to the Telebit ... but the flow doesn't stop
at the other end until the buffer in the Telebit empties.

People with MNP also get this but have been willing to live with it
as they get a much higher speed; people without MNP moaned and
complained so much that I changed the logic of the way my system
handles connects so that it only locks the port on MNP/LAPM/etc.
error correction. Thus under non-error correction there is no
overrun when they send ^S as there is nothing in the buffer.

> >their and dialout. Maybe I'm missing something here because getty
> >2.0 can look for a lock on the port and won't try and init the
> >modem if it's already in use, but if getty 2.0 has the port and is
> >waiting for the CONNECT and you go and run cu or something that
> >dials out, getty starts interpreting things to the confusion of all.
>
>    In ISC and or FAS, I thought the trick about that one was that
> there are two different /dev/tty?? devices to use. In ISC
> there are even three if I remeber right.

Yes, this is so, but it doesn't take into consideration what 
happens when you start sending init strings to the modem (as the 
normal getty/uugetty pretends that the modem is just a terminal 
whose CD signal goes on and off). Once getty 2.0 has sent the init 
string sent and is waiting for a CONNECT string of some kind, 
things go very strangely if another process jumps in there and 
sends yet another init/dialout string!  I would imagine there might 
be some way to kill off the first getty 2.0 that's sitting there 
waiting for a call/CONNECT so a second one could re-init/dial out
but I didn't try it.

> >locked-uugetty line and 3 running getty 2.0 which interpret the
> >CONNECT string. A further feature of is that there is no need for
> >users to hit RETURN so magic number of times; getty 2.0 picks up
> >the CONNECT string and will generate a configureable signon banner.
>
>    I'm a gonna havta look into this getty 2.0 thing.

I found this is a big improvement over "hit RETURN the number of
times between the highest speed on the modem that you happen to
hit on the rotary and the speed at which you want to connect",
which is what users have to do with the regular getty/gettydefs.

Sheesh! I thought computer were supposed to do the work...

Dave

--
Dave McLane <davidg%aegis.or.jp at kyoto-u.ac.jp>