From owner-freebsd-questions Thu Feb 24 18:12:12 2000 Delivered-To: freebsd-questions@freebsd.org Received: from boris.netgate.net (boris.netgate.net [204.145.147.154]) by hub.freebsd.org (Postfix) with ESMTP id 3D96A37BD5B; Thu, 24 Feb 2000 18:12:00 -0800 (PST) (envelope-from wellsian@caffeine.com) Received: from localhost (wellsian@localhost) by boris.netgate.net (8.9.3/8.9.3) with ESMTP id SAA18396; Thu, 24 Feb 2000 18:11:13 -0800 (PST) (envelope-from wellsian@caffeine.com) Date: Thu, 24 Feb 2000 18:11:13 -0800 (PST) From: wellsian X-Sender: wellsian@boris.netgate.net To: "Daniel O'Connor" Cc: Ptacek , freebsd-hackers@FreeBSD.ORG, freebsd-questions@FreeBSD.ORG Subject: RE: modem program... Help In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-questions@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG You have to control and respond to state changes yourself. There is no "backchannel" available to tell you what's going on. More directly, there is no way to know if the modem is in command or data mode without keeping an eye on the data stream and handshake lines, sometimes injecting your own data to test the situation. In the case you brought up, you could only reliably know about the disconnect if you watch the CD line. You can certainly make your code smart, to look for delicate combinations like "NO CARRIER" but it gets annoying if you don't have to do it. If you have reasonable control over of the installation, the modem, and use of the software, say for a limited project, then you can write your code to rely on DTR/DSR/CD (and maybe RI) for most needs. This will give you the most reliable control, assuming you configure the modems properly and that they handle the lines correctly (not all do). Most commercial software uses both a configurable set of hardware lines and modem definition files describing modems' responses to commands and state changes. This is because the author rarely has any control over the type of modem. And often, the cable or other elements of the install aren't trustworthy. Writing a program for this environment - one that works reliably across a wide range of modems - can be quite difficult and usually results in "Yet Another Modem Control Language". :) If you have the choice, go for hardware control. It's the closest thing you have to a backchannel, and it removes a large portion of the guessing involved in automating modem connections. What remains is sending dial commands and recognizing a few "OK, BUSY, etc." messages. Much simpler. Been there...good luck. Dave On Fri, 25 Feb 2000, Daniel O'Connor wrote: > > On 25-Feb-00 Ptacek wrote: > > I just can't seem to get the modem to hangup. I probably have > > to bring the DTR low (+++ATH doesn't work). How > > do I do this? Also how can I detect if the modem is in > > command mode, for example if the line gets unplugged and I > > get a NO CARRIER back how do I know to read that as a > > command instead of data? > > Your '+++ATH0' won't work because there is no delay between the +++ and the > ATH0. ie do '+++' wait 2 seconds then send 'ATH0' > > Or you could set the modem to go into command mode on DTR drop.. > > --- > Daniel O'Connor software and network engineer > for Genesis Software - http://www.gsoft.com.au > "The nice thing about standards is that there > are so many of them to choose from." > -- Andrew Tanenbaum > > > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-questions" in the body of the message