Date: Sun, 22 Jun 1997 18:11:00 +0000 (GMT) From: Adam David <adam@veda.is> To: davidn@labs.usn.blaze.net.au (David Nugent) Cc: freebsd-current@freebsd.org Subject: Re: getty modem control Message-ID: <199706221811.SAA23147@veda.is> In-Reply-To: <199706221146.VAA00338@labs.usn.blaze.net.au> from David Nugent at "Jun 22, 97 09:46:03 pm"
next in thread | previous in thread | raw e-mail | index | archive | help
[David Nugent]
> [Adam David]
> > I have reordered the flow of the chat support in main() and added :nb:
> > to enable non-blocking use.
>
> I'm not sure what you mean. Non-blocking open, or non-blocking i/o?
> chat.c does fiddle with non-blocking i/o, but only for preventing an
> indefinite wait within the kernel should a signal occur.
non-blocking open. Currently your code forces non-blocking open when
answer chat is used.
> > 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.
>
> Again, I'm not sure what this means. How can you use answer chat
> on a blocked open, assuming this is what you're referring to.
Start with "" "\d\d\d+++\d\d\d" and end with "ATO" or am I missing something
here? After the modem autoanswers the incoming call, the chat script can
talk to the local modem and/or the remote equipment/person. It's purpose
is not to pick up the phone but to interact with the incoming call on the
answer event. In the case of non-blocking open, this requires the use of
"ATA" to pick up the phone. [assume Hayes command set]
> I'd also vote AGAINST any change to 'default' beahviour at all.
> This is likely to upset people, and you can see from Joergs'
> reaction as to how seriously people take it.
No change to default behaviour, except where :ac=: is used, my change
requires a :nb: to get the same effect with :ac=: as currently.
> > 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?
>
> Sure. It may be dependant on the modem, but when CD goes high,
> the open succeeds. If the modem sends the connect strings after
> that point (and I've never come across one that sends them before
> then), they can be read - in fact, their presence in the first
> place is what cause me to fix :de: so it flushed after the
> delay. This was confusing getty's login prompt. There's
> a secondary problem of possibly eating valid input (but the i/o
> flush after the delay if you're using does that anyway), but this
> is a configuration issue, not a software one.
The connect strings are sent at that point, but CID is sent after the
first ring so if ATS0=2 (or greater), CID is presented to the serial port
before DCD is asserted. What happens when ATS0=1, is the CID sent by the
telco (and usable) even when the call is answered on the first ring?
> > 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?
>
> Yes. The open would have completed anyway, but the timing issue
> is more related to the modem than anything else.
Do I understand correctly that data output from the modem during the period
of open() being blocked, is available for reading once the open() completes?
(assuming we don't flush the input)
> > > 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.
>
> Absolutely. Like autoboard speed switching. We could probably rip
> that out of FreeBSD's getty and noone would notice. Still, it is
> a large part of the *noticable* interface to allow baud rate
> switching, and it is "historical". Personally, I'd have more
> objections to having that "bloat" in getty than something far
> more useful like handling a modem. :-)
>
> Not to mention that this bloat causes a memory leak under 2.2
> (I fixed this in -current, but haven't yet merged it back into
> the 2.2 branch; still waiting on feedback from Bruce on that).
>
> > > 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.
>
> No, they definitely won't work right now. There's a hang on read in
> spite of the non-blocking open().
>
>
> > 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
>
> I don't have this problem at all. getty does reset the modes correctly,
> and since it is running as root anyway, how are the tty modes relevant?
It interferes with other programs that might want to talk to the port.
The following snippet is from main.c, I don't see where the permissions
are restored.
if (strcmp(argv[0], "+") != 0) {
chown(ttyn, 0, 0);
chmod(ttyn, 0600);
revoke(ttyn);
/dev/ttyd? is already root.wheel 600 so this is simply reinforcing it.
/dev/cuaa? is normally uucp.dialer 660 and changing it prevents other
programs relying on uucp.dialer from using the port, even afterwards.
> > 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.
>
> Use the cua devices.
>
> I can send my gettytab and ttys if you like. They are fully working
> examples used in a production environment.
This would be helpful if you would. Relevant excerpts are sufficient.
--
Adam David <adam@veda.is>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199706221811.SAA23147>