Xref: utzoo comp.unix.sysv386:9183 comp.dcom.modems:10502 Path: utzoo!utgpu!cunews!cognos!attila!fozzi.ocunix.on.ca!latour!mcr From: mcr@Sandelman.OCUnix.on.ca (Michael Richardson) 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: <1991Jun20.171902.23267@Sandelman.OCUnix.on.ca> Date: 20 Jun 91 17:19:02 GMT References: <1991Jun17.142748.670@uunet.uu.net> Organization: Sandelman Software Works, Debugging Department, Ottawa, ON Lines: 94 In article davidg%aegis.or.jp@kyoto-u.ac.jp (Dave McLane) writes: >> 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 ^^^^^^^^^^^^^^^^^^ Hmm. This is a problem in my opinion. Users should be taught to use more or pg. What really annoys me is when I type: % l /etc | more l expands to '/bin/ls -lg !* | more', and the first more sometimes manages to not turn itself into cat when stdout isn't a terminal... >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. I've given some thought as to how to pick up the CONNECT messages. I may eventually do some hacking on fas, but since I still haven't convinced my boss that fas is usefull :-) (various comments about sticking with the vendor's stuff, so we know it works and can solve clients problems...) What I'd like to do is to write a getty that does just one extra ioctl. What I understand about streams, however tells me that this won't work. (Are ttys streams under ISC? I can't remember right now. I think not.) Have getty open(file,O_NDELAY), and then ioctl(fd,I_PUSH,"Telebit"). The "Telebit" streams module knows how to do things with Telebits on the other end of the line. (you could probably get away with a generic 'Hayes' module, I don't know yet) The trick is to convince the underlying driver to return characters to this streams module even when DCD is down, AS LONG AS /dev/acuBLAH isn't open. The streams module hangs around, and waits for 'RING' and sends a friendly 'ATA' back. No more answering the phone when the computer has locked up without dropping DTR. Among important things that this module would do would be to parse the CONNECT xxxx message and remember that number. The interface speed wouldn't actually change (unless, I guess, you really wanted it to in order to support ^S). However, any ioctl(...TCGETS...) calls would have their speed entry patch to reflect the actual connect speed. vi and friends can do their low speed optimizations. Even better, would be to have this nice little module do dial out too. If it receives RING while setting up the modem, it returns "BUSY" and gives the getty a kick. This would require modifying uucico and cu though, and would make the module much bigger. I can't think of a good way to implement this kind of stuff in user mode, and still support the dial in and dial out ports. I saw most of this stuff in Fidonet mailers, and implemented parts of it for Welmat (an Amiga mailer). >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. The /dev/tty0d and /dev/acu0 are the best thing since sliced bread. I have tried repeatedly on many different OSs and many different machines to get uugetty to do its stuff, and I have always failed, or I've never been satified with how it is doing its thing. >> 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 why I like locked interface speeds. Concerning ^S/^Q --- can the Telebit be configured to respond to them from the remote system? Hmm. I want an emacs info document on my Telebit inaddition of that inch thick book. -- :!mcr!: | The postmaster never | So much mail, Michael Richardson | resolves twice. | so little time. HOME: mcr@sandelman.ocunix.on.ca Bell: (613) 237-5629 Small Ottawa nodes contact me about joining ocunix.on.ca!