Date: Sun, 22 Jun 1997 20:24:37 +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: <199706222024.UAA23414@veda.is> In-Reply-To: <199706221834.EAA00522@labs.usn.blaze.net.au> from David Nugent at "Jun 23, 97 04:34:28 am"
next in thread | previous in thread | raw e-mail | index | archive | help
> > > 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. > > Right. But before you can get a carrier, you need to answer the line > by sending ATA. How can you do that without the port being open? ATS0=1 opens the port on an incoming call. > > > 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? > > ? Go into command mode to talk to the modem, then back into data mode. Different data modes can perhaps be selected depending on the nature of the incoming call, even different programs started to take the call. > > 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] > > Yes, that was the intention. However, going into command mode at > this stage is both unnecessary and possibly dangerous. Unnecessary for your purposes, and dangerous --> risky (for modems that cannot handle it). Why else should there be any problem with skipping out to command mode? > > No change to default behaviour, except where :ac=: is used, my change > > requires a :nb: to get the same effect with :ac=: as currently. > > I must not understand exactly what it is you're trying to do. Why go > into command mode *after* you've established the connection? > The whole point of an answer chat is to answer the phone, no? You are operating on the assumption that manual answer is necessary. I am more interested in using auto-answer. The main point of answer chat (from my perspective) is to respond to the stimulus of an answer event. If the phone has not already been answered, it can be done at this stage. > > 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? > > No idea. I don't have the facility. The only time I've seen CID at > work is when the modem (which is CID savvy) sent it as part of the > connect string. So far then I have seen these different methods of handling CID: 1. Provide a command for displaying the last received CID 2. Display CID as it arrives (before connect) 3. Display CID with the connect string Simply not answering blocked numbers is not possible with the third method, for this the only way to block numbers is hanging up the phone after connect. > > 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 assume so yes, but I was only addressing data received after the > open succeeds. As for earlier data, I have no idea, but I suspect > not since there's no tty attached to the device at the time, and > therefore there can be no clists collected. I'm wondering about whether the modem will buffer the data until the port is fully open, relying on hardware handshaking to hold it back. -- Adam David <adam@veda.is>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199706222024.UAA23414>