From owner-freebsd-current Sat Jun 21 23:52:53 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id XAA13429 for current-outgoing; Sat, 21 Jun 1997 23:52:53 -0700 (PDT) Received: from veda.is (ubiq.veda.is [193.4.230.60]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id XAA13412 for ; Sat, 21 Jun 1997 23:52:46 -0700 (PDT) Received: (from adam@localhost) by veda.is (8.8.5/8.7.3) id HAA21918; Sun, 22 Jun 1997 07:20:42 GMT From: Adam David Message-Id: <199706220720.HAA21918@veda.is> Subject: Re: getty modem control In-Reply-To: <199706220523.PAA00550@labs.usn.blaze.net.au> from David Nugent at "Jun 22, 97 03:23:07 pm" To: davidn@labs.usn.blaze.net.au (David Nugent) Date: Sun, 22 Jun 1997 07:20:41 +0000 (GMT) Cc: freebsd-current@freebsd.org X-Mailer: ELM [version 2.4ME+ PL31 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk [David Nugent] > Actually, CID should be trivial to add. The support functionality > is already there. Instead of flushing the modem input with wait/flush > after the connect, use the functions in chat.c to grab each line > output from the modem and log the data. I have reordered the flow of the chat support in main() and added :nb: to enable non-blocking use. If no-one among the non-blocking crowd objects, I will commit the changes so that blocking use of the answer chat facilities is available by default. Yes, it would definitely be nice to log the report strings. Is there a chance that CID will be available on broken implementations (such as Rockwell) when blocking on open() is used? To generify the question, if the serial input is not flushed on successful open, is that input available for reading if it originally occured after open() was first invoked but before the open() completed? > I *hate* mgetty with a vengence - it is far too bloated and > difficult to configure. ... and still assumes primitive modem technology. It's fine to support older equipment, but too limiting when this is assumed. > getty works for me, and very well, using a wide range of modems. > Its only problem is having to use cua* devices rather than tty* > devices, which I am fairly certain has to do with termios settings, > and in particular CLOCAL handling. It is in my todo list to fix. Ah, this is where I took a wrong turn. I was trying to use it with ttyd? devices. CLOCAL looks a likely culprit under the circumstances. However, when trying cuaa0 I found something had set /dev/cuaa0 to root.wheel 600 and I don't remember any other program than getty getting near it, so I went back to being stuck at getty chat on ttyd0 not working. Since people are using it with some success, I sat back to hear how this was done. -- Adam David