Handling received SMS
aleksander at aleksander.es
Mon Feb 13 09:48:11 UTC 2017
On Mon, Feb 13, 2017 at 9:13 AM, <colin.helliwell at ln-systems.com> wrote:
> All I'm seeing in the logs is "+CIEV: message,1".
> Checking back through the logs for unsolicited event setups, I also see
> [src/mm-broadband-modem.c:5888] set_messaging_unsolicited_events_handlers(): (ttyMux0) Setting messaging unsolicited events handlers
> [src/mm-port-serial.c:1347] _close_internal(): (ttyMux0) device open count is 1 (close)
> [src/mm-iface-modem-messaging.c:867] enable_unsolicited_events_ready(): Couldn't enable unsolicited events: 'SMS settings don't accept [2,1] <mode>'
> That inner error message seems to originate in the Cinterion plugin's messaging_enable_unsolicited_events (). From what I can make out, that function is looking for a supported mode in the response to "AT+CNMI=?".
> Doing this from the command line gives the response " +CNMI: (0-3),(0,1),(0,2,3),(0,2),(1) ". Furthermore a "AT+CNMI=2" also from the command line - which I think the plugin would have otherwise tried to do if it had found the mode - does give an OK response.
The +CNMI=? parser didn't expect the "range" format given for the
<mode> field. I've fixed that in git master now.
> But I think I need to switch back to the Generic plugin, for simplicity, and see how that behaves. I have though already seen some incompatibilities which I'll need to address - and these may be related to this problem. E.g. a parameter used for 'AT+CMER=3,0,0,1 ; and also param value problems with 'AT+CNMI=2,1,2,1,0'. In the case of the latter, the code looks like it is written to have 3 forms of this command to try - cnmi_sequence - but although my modem fails the first " +CMS ERROR: 500 ", the other two aren't then tried instead?
Looks like the retry is only done if "not supported" errors, not in
Dan, should we remove that condition and retry on any kind of error?
The logic was introduced in 1d9164ec90788d1be134482ff88c501e3c5d623c.
More information about the ModemManager-devel