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

Dave McLane davidg%aegis.or.jp at kyoto-u.ac.jp
Sun Jun 16 07:40:49 AEST 1991


karln at uunet.uu.net writes:

> In article <1991Jun15.030807.28565 at pegasus.com> richard at pegasus.com (Richard
> >Does anyone have a getty working with ISC Unix and Telebit modems
> >that will change the line baud rate according to the `CONNECT xxxx'
> >message from the modem?
> >
> >I'm hoping to get something like this working on ports that are
> >used bi-directionally via the kernel/driver based locking scheme,
> >not the uugetty approach.  Is this even possible?
> >
> >(I don't want to lock the port speed on the Telebits because that
> >breaks some nice features on programs like vi, etc., that adapt
> >their display to the speed of the connection.)
> >
>       Despite the last comment, I HIGHLY reccomend locking
> the speed of the modem. I know someone that tried for a week
> or two trying to get the T2500 to work like the manual shows,
> but never really got it off the ground. Furthermore I cannot
> picture were getty is going to get the connect string from,
> but then again I've always gone the locked speed route. The

I have Paul Sutcliff's getty 2.0 running Telebit 2500/1600s and it 
works well for changing the baud rate on dialin but not for dialout.

First off, getty 2.0 allows you to send an init string to the modem
which isn't really needed for Telebits as they are very configureable
but allows you to run older/cheaper modems (that you may already have)
which don't.

Second, if you configure the modem as it would be for a BBS it
returns a CONNECT (speed)/(link)/(compression) which shows just
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).

However, if you think about it (and I didn't, but found out after I 
had the thing running), there isn't any convenient way of hanging 
getty 2.0 on the line and have it (perhaps init the modem and then) 
wait for a CONNECT string and let cu or something else sneak in 
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.

Perhaps there is a way around this but I have 4 lines and decided 
to hang a regular uugetty on one and share it with a fax (the line 
also has a switch on it that let's incoming calls select either the 
fax or the modem) and run getty 2.0 on the rest. So I have UUCP, 
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.
Mine is

  Aegis - 06/16/91 06:19:16 - ttyF04 9600 BPS - 4 user(s) online

  login:

Hope that helps,

Dave

--
Dave McLane <davidg%aegis.or.jp> JUNET
            <davidg%aegis.or.kyoto-u.ac.jp> INTERNET
            <davidg%aegis.or.jp at jpnkyoto.kyoto-u.ac.jp> BITNET
            <davidg%aegis.or.jp%kyoto-u.ac.jp at uunet.uu.net> UUNET

==== The Aegis Society =============================================
Minami Hirao 1-6, Imazato                 The content and process of
Nagaokakyo-shi, Kyoto-fu, 617 Japan           international/cultural
Tel: +81-75-951-1168 Fax: +81-75-957-1087             communication.
====================================================================



More information about the Comp.unix.sysv386 mailing list