Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 24 Feb 2000 18:11:13 -0800 (PST)
From:      wellsian <wellsian@caffeine.com>
To:        "Daniel O'Connor" <doconnor@gsoft.com.au>
Cc:        Ptacek <ptacek@dashmail.net>, freebsd-hackers@FreeBSD.ORG, freebsd-questions@FreeBSD.ORG
Subject:   RE: modem program... Help
Message-ID:  <Pine.BSF.4.21.0002241741310.17368-100000@boris.netgate.net>
In-Reply-To: <XFMail.000225112905.doconnor@gsoft.com.au>

next in thread | previous in thread | raw e-mail | index | archive | help
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<CR><delay...>" 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<CR> 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-hackers" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.21.0002241741310.17368-100000>