experchange > shell

Computer Nerd Kev (11-26-18, 01:10 AM)
I want to send (mobile phone) text messages with variable contents
using a mobile broadband modem connected to a router running
OpenWRT (BusyBox ash shell), within a script. Limited by the
software available for OpenWRT, I've settled on using "stty" to
set bitrate, then "chat" to do the command Rx and Tx.

The script for chat can be specified either from file (with
-f [file]), or on the command line. Ideally I'd like to use the
latter option so that I don't need to use temporary files if I
can avoid it, however I can't get the quoting right.

For a test, I've been using this chat script that checks the
standard "AT" response "OK", then sets the modem in SMS mode with
"AT+CMGF=1", which also gets "OK" back:

'' AT OK\r AT+CMGF=1 OK\r

Written to testchat.txt, I can execute:

chat -V -f testchat.txt < "/dev/ttyUSB1" > "/dev/ttyUSB1"

And on stderr I correctly get (all commands in/out echoed there due
to the "-V" parameter):

AT
OK
AT+CMGF=1
OK

But I want to avoid using the script file, and if I try this:

chat -V "'' AT OK\r AT+CMGF=1 OK\r" < "/dev/ttyUSB1" > "/dev/ttyUSB1"

The command simply times out with nothing echoed to stderr except
unrelated automatic status info from the modem. Presumably it's
waiting on some expect string before sending a command.

I suspect that the issue is the double quotes at the start of the
chat script which are required because they have the format of:
[expected string] [space] [response string] [space]
[expected string] [space] ...

The modem needs a command sent at the start, before it will send
a response, so '' is a null expect string so that chat goes
straight to the response. This is the only way to do it that I
can make out from the man page (though I don't exactly find said
page crystal clear).

I've tried:

chat -V "\'\' AT OK\r AT+CMGF=1 OK\r" < "/dev/ttyUSB1" > "/dev/ttyUSB1"

Same thing, chat times out looking for an "expect" string.

The full chat script includes further quoted strings, some with
variables enclosed within them (so I'll have to quote with "", which
has the same result in the above test). Is this possible without
using a temporary file?

P. S. I just noticed that the man page says that the script is
included as "parameters", plural, to the chat program. So
I had the idea to try:

chat -V '' AT OK\r AT+CMGF=1 OK\r <"/dev/ttyUSB1" >
"/dev/ttyUSB1"

Same result, timed out.
Eric Pozharski (11-27-18, 10:24 AM)
with <ptfa5p$1rpo$1> Computer Nerd Kev wrote:

> I want to send (mobile phone) text messages with variable contents
> using a mobile broadband modem connected to a router running OpenWRT
> (BusyBox ash shell), within a script. Limited by the software
> available for OpenWRT, I've settled on using "stty" to set bitrate,
> then "chat" to do the command Rx and Tx.


Question. I understand OpenWRT is inside all busybox. Have you
considered 'microcom' applet of busybox? If positive then why it was
avoided/rejected? (Just courious, I've tried this applet myself and it
failed to open or timeouted (IIRC) anything that could be modem. But it
was a phone, so I blame Android being POSIX abomination.)

*SKIP*
> chat -V '' AT OK\r AT+CMGF=1 OK\r <"/dev/ttyUSB1" >"/dev/ttyUSB1"
> Same result, timed out.


Question. What "\r" is doing here?

# chat -V '' AT\r OK </dev/dip-port >/dev/dip-port
ATr

ERROR

^C#

"^C" is here because of timeout, because 'OK' never show up. Also, it's
a regular zsh. Whatever shell is in use over there on OpenWRT might
have it's own quirks. If I use "\\r" then chat timeouts indeed. And
doesn't without it. So, why "\r"?
Ivan Shmakov (11-27-18, 04:47 PM)
>>>>> Computer Nerd Kev <not> writes:

[...]

> '' AT OK\r AT+CMGF=1 OK\r


> Written to testchat.txt, I can execute:


> chat -V -f testchat.txt < "/dev/ttyUSB1" > "/dev/ttyUSB1"


> And on stderr I correctly get (all commands in/out echoed there due
> to the "-V" parameter):


> AT OK AT+CMGF=1 OK


[...]

> P. S. I just noticed that the man page says that the script is
> included as "parameters", plural, to the chat program. So I had the
> idea to try:


> chat -V '' AT OK\r AT+CMGF=1 OK\r <"/dev/ttyUSB1" > "/dev/ttyUSB1"


> Same result, timed out.


The last chat command gets a script different to that you've
put into a file:

$ printf %s\\n '' AT OK\r AT+CMGF=1 OK\r

AT
OKr
AT+CMGF=1
OKr
$

While I suppose that an empty string as a command line argument
would work no worse than a couple of quotes ('') in the file,
I'm pretty sure you should use \\r in place of \r so that the
chat command would get actual backslashes (instead of them being
stripped by the shell.)

[...]
Computer Nerd Kev (11-27-18, 11:11 PM)
Ivan Shmakov <ivan> wrote:
[..]
> I'm pretty sure you should use \r in place of \r so that the
> chat command would get actual backslashes (instead of them being
> stripped by the shell.)


Ah, just tried:
chat -V '' AT OK\\r AT+CMGF=1 OK\\r < "/dev/ttyUSB1" > "/dev/ttyUSB1"

and sure enough:
AT
OK
AT+CMGF=1
OK

I forgot that the shell would be getting to those backshashes first.
I guess having real Carriage Return characters in the input messed up
something internally in chat which confused it before it even got to
that part of the script.

Shame that I went ahead and rewrote the script to use the temporary
file method yesterday, but that's how it goes. Thanks for the help.
Computer Nerd Kev (11-27-18, 11:58 PM)
Eric Pozharski <whynot> wrote:
> with <ptfa5prpo> Computer Nerd Kev wrote:
> Question. I understand OpenWRT is inside all busybox. Have you
> considered 'microcom' applet of busybox? If positive then why it was
> avoided/rejected? (Just courious, I've tried this applet myself and it
> failed to open or timeouted (IIRC) anything that could be modem. But it
> was a phone, so I blame Android being POSIX abomination.)


OpenWRT comes with "picocom" by default. That's what I've used for
connecting manually to the modem, and I've made a note that I can't
automate it. I just checked and microcom is available, and the
package description says "... terminal emulator with scripting
support".

First impressions are that it may be less well documented than
chat, and seems only to read scripts from file. Chat seems to
be working for me now, but I'll keep that in mind as another
option.

The files for this project hadn't been modified since Jan. until
I got back to it last weekend, so I can't really remember what
software I considered besides the note I left about picocom.
I know I checked that there wasn't an openWRT package (I don't
want to get into cross-compiling software for the router) of this:


> *SKIP*
> Question. What "\r" is doing here?
> # chat -V '' AT\r OK </dev/dip-port >/dev/dip-port
> ATr
> ERROR
> ^C#
> "^C" is here because of timeout, because 'OK' never show up. Also, it's
> a regular zsh. Whatever shell is in use over there on OpenWRT might
> have it's own quirks. If I use "\r" then chat timeouts indeed. And
> doesn't without it. So, why "\r"?


As noted in my other reply, I got this working using "\\r". I just
tried:
chat -V '' AT OK AT+CMGF=1 OK <"/dev/ttyUSB1" > "/dev/ttyUSB1"

And it works as well. However the reason I wanted to send it the
"\r"s was because the man page says that chat does not automatically
look for carriage returns after "expect" strings, although it adds
them automatically to the "reply" strings. It looks like it might
not matter if it starts the reply before the Carriage Return is
recieved from the modem, but given that there are other status
messages coming out of the modem automatically while this is going
on, looking for any response containing "OK\r" is at least slightly
less risky than just "OK".

That's if I'm reading the man page correctly. Which, as this thread
already proves, is far from certain. As I say, either seems to work.

Thanks for the help.
Eric Pozharski (11-28-18, 10:12 AM)
with <ptkem8$h25$1> Computer Nerd Kev wrote:
> Eric Pozharski <whynot> wrote:
>> with <ptfa5p$1rpo$1> Computer Nerd Kev wrote:


> OpenWRT comes with "picocom" by default. That's what I've used for
> connecting manually to the modem, and I've made a note that I can't
> automate it. I just checked and microcom is available, and the package
> description says "... terminal emulator with scripting support".


My description says: "Copy bytes for stdin to TTY and from TTY to
stdout". That's what I believed it could be used for. Turns out...

> First impressions are that it may be less well documented than
> chat, and seems only to read scripts from file. Chat seems to
> be working for me now, but I'll keep that in mind as another
> option.


I've just checked. Total silence -- I figure it does something to
controlling terminal so even echoing on my side is off. And nothing
comes out. And I'm not motivated to waste any time on it. Probably
doesn't work with USB-modems. Sorry for wasting your time.

*CUT*
Computer Nerd Kev (11-29-18, 12:06 AM)
Eric Pozharski <whynot> wrote:
> with <ptkem8$h25> Computer Nerd Kev wrote:
> I've just checked. Total silence -- I figure it does something to
> controlling terminal so even echoing on my side is off. And nothing
> comes out. And I'm not motivated to waste any time on it. Probably
> doesn't work with USB-modems. Sorry for wasting your time.


No problem, I'm sure it could work the same way as I've been manually
connecting using picocom ( picocom -b 9600 -f s -r /dev/ttyUSB1 ),
and it suggests that there is some way to script it, unlike Picocom.
But I can't find any decent documentation, and ideally I'd want
better docs for it than I already have for Chat.
Similar Threads