Bug#559774: ITP: modem-cmd -- send arbitrary AT commands to your modem
On Mon, Dec 07, 2009 at 03:28:26PM +0100, Hendrik Sattler wrote:
>> This doesn't work. The modem expects you to flush its output buffer
>> before it will accept new commands.
> Note: a modem may be in the wrong mode (e.g., GSM modems may have more
> than one, some not even for AT commands).
> There are numerous errors why a modem may not do what you want ;)
Well, needless to say, I took my own modem as reference so although my
code in principle should support all modems I give no warranty (as if I
were going to give it anyway). In any case, patches welcome.
>> That aside, terminal capabilities need to be set via termios.
> which can be done once with stty?
> I don't see baud rate or any other options in that example line.
Baud rate is hardcoded to 115200. In general, my intent is to hide the
complexity. In fact this program would be completely useless if it wasn't
for this (i.e. one can just do things low-level, either through C/termios
or similar shell/stty interfaces), but this is true for most programs
ain't it? :-)
>> And it's not obvious that you want '\r' instead of '\n'. In fact, I figured
>> that out by stracing "cu".
> Usually, AT commands are sent with "\r\n" at the end (like in Windows
> text files), and the responses also do have those at the end of each
Yeah, I know that now (and back when I didn't know, I knew how to figure this
out), but most users don't. This is why I think this program is useful
for people who just want to make their modem dial a number. Hey, it
would have been pretty useful *for me*! I not just wasted my time
writing a new program to do what I wanted, that was only after I figured
out that "cu" or "minicom" wouldn't behave the way I needed (even after
messing with cu source code).
The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and
how) you may access your data; but nobody's threatening your freedom: we
still allow you to remove your data and not access it at all."