Xref: utzoo comp.unix.sysv386:9070 comp.dcom.modems:10443 Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!mips!ptimtc!rdmei!spgw01!iegva1!kuis!aegis!davidg From: davidg%aegis.or.jp@kyoto-u.ac.jp (Dave McLane) Newsgroups: comp.unix.sysv386,comp.dcom.modems Subject: Re: Getty for ISC/Telebit T-2500 w/autobaud via the CONNECT msg? Keywords: Telebit, getty, autobaud, bi-directional Message-ID: Date: 18 Jun 91 14:33:57 GMT References: <1991Jun17.142748.670@uunet.uu.net> Organization: Aegis Society, Kyoto Japan Lines: 77 karln@uunet.uu.net writes: > In article davidg%aegis.or.jp@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