[PATCH 1/2] sms: Option HSO modem can't really do CNMA

[PATCH 1/2] sms: Option HSO modem can't really do CNMA

[Neil Jerram]

[-- Attachment #1: Type: text/plain, Size: 657 bytes --]

It appears the Option HSO modem can't really do CNMA, so ignore the
fact that it returns 1 for the 'service' value in its response to
AT+CSMS?
---
 drivers/atmodem/sms.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/atmodem/sms.c b/drivers/atmodem/sms.c
index f93dd23..2eab58e 100644
--- a/drivers/atmodem/sms.c
+++ b/drivers/atmodem/sms.c
@@ -1178,6 +1178,7 @@ static void at_csms_status_cb(gboolean ok, GAtResult *result,
 		switch (data->vendor) {
 		case OFONO_VENDOR_HUAWEI:
 		case OFONO_VENDOR_NOVATEL:
+		case OFONO_VENDOR_OPTION_HSO:
 			g_at_result_iter_skip_next(&iter);
 			service = 0;
 			break;
-- 
2.1.1

[PATCH 2/2] receive-sms: Support printing received SMS with non-ASCII characters

[Neil Jerram]

[-- Attachment #1: Type: text/plain, Size: 982 bytes --]

Without this I get the following Python traceback, for an SMS that
contains the UK pound sign.

ERROR:dbus.connection:Exception in handler for D-Bus signal:
Traceback (most recent call last):
  File "/usr/lib/python2.7/dist-packages/dbus/connection.py", line 230, in maybe_handle_message
    self._handler(*args, **kwargs)
  File "./receive-sms", line 9, in incoming_message
    print("%s" % (message))
UnicodeEncodeError: 'ascii' codec can't encode character u'\xa3' in position 51: ordinal not in range(128)
---
 test/receive-sms | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/test/receive-sms b/test/receive-sms
index a0c6915..f5e247e 100755
--- a/test/receive-sms
+++ b/test/receive-sms
@@ -6,7 +6,7 @@ import dbus
 import dbus.mainloop.glib
 
 def incoming_message(message, details, path, interface):
-	print("%s" % (message))
+	print("%s" % (message.encode('utf-8')))
 
 	for key in details:
 		val = details[key]
-- 
2.1.1

Re: [PATCH 1/2] sms: Option HSO modem can't really do CNMA

[Neil Jerram]

[-- Attachment #1: Type: text/plain, Size: 3275 bytes --]

Neil Jerram <neil@ossau.homelinux.net> writes:

> It appears the Option HSO modem can't really do CNMA, so ignore the
> fact that it returns 1 for the 'service' value in its response to
> AT+CSMS?

To add a bit of context to this patch...

This was triggered by the observation that oFono running on my GTA04
phone - which has an internal GTM601 Option HSO modem - cannot receive
incoming SMSes.

Investigation and comparison against another telephony stack (QtMoko aka
Qtopia) suggested that the key difference was in the CNMI command:

  Nov 20 23:36:06 neo Qtopia: AtChat :  T : "AT+CNMI=2,1,2,0,0" 

  ofonod[571]: App: > AT+CNMI=2,2,2,1,0\r

  +CNMI=[<mode>[,<mt>[,<bm>[,<ds>[,<bfr>]]]]]

  | CNMI | qtmoko | ofono |                                                                                                 |
  |------+--------+-------+-------------------------------------------------------------------------------------------------|
  | mode |      2 |     2 | 2 = buffer new Sms when TE-TA link is reserved and flush them to TE after reservation           |
  |      |        |       |                                                                                                 |
  | mt   |      1 |     2 | 1 = +CMTI: <mem>,<index> routed to TE;                                                          |
  |      |        |       | 2 = for all SMS_DELIVERs except class 2: +CMT: routed to TE; class 2 is indicated as in <mt>=1; |
  |      |        |       |                                                                                                 |
  | bm   |      2 |     2 | <bm>: same as <mt>, but for CBMs;                                                               |
  |      |        |       |                                                                                                 |
  | ds   |      0 |     1 | 0 = No SMS-STATUS-REPORT are routed to TE;                                                      |
  |      |        |       | 1 = SMS-STATUS-REPORTs are routed to TE, using +CDS                                             |
  |      |        |       |                                                                                                 |
  | bfr  |      0 |     0 | 0 = TA buffer is flushed to TE (if <mode>=1..3)                                                 |
  |      |        |       | 1 = TA buffer is cleared (if <mode>=1..3)                                                       |
  |------+--------+-------+-------------------------------------------------------------------------------------------------|

oFono chooses 2 for the "mt" value, rather than 1, if it thinks that the
modem can do "CNMA", which I think means acknowledging each SMS after it
is transferred from the modem to the containing OS.  But:

- in practice the modem never generates the +CMT indications that are
  supposed to go with this mode of operation

- there are other places in the source code nearby where CNMA acking is
  skipped for OFONO_VENDOR_OPTION_HSO.

It seems this adds up to an indication that the modem doesn't really do
CNMA, and the patch that I've submitted does the trick and allows
incoming SMSes to be received successfully.

Thanks,
        Neil

Re: [PATCH 1/2] sms: Option HSO modem can't really do CNMA

[Denis Kenzior]

[-- Attachment #1: Type: text/plain, Size: 1255 bytes --]

Hi Neil,

 >
> oFono chooses 2 for the "mt" value, rather than 1, if it thinks that the
> modem can do "CNMA", which I think means acknowledging each SMS after it
> is transferred from the modem to the containing OS.  But:

Yes, oFono prefers using +CMT indication instead of +CMTI.  That is 
because we actually need 2 extra AT commands to process the incoming 
message instead of just 1 with +CMT.

>
> - in practice the modem never generates the +CMT indications that are
>    supposed to go with this mode of operation
>

Your modem is just weird then.

> - there are other places in the source code nearby where CNMA acking is
>    skipped for OFONO_VENDOR_OPTION_HSO.
>

Not really.  We only skip the generation of the ackpdu.  Acknowledging 
via AT+CNMA still works with the 'safe' AT+CNMA=0 option.  This works on 
every HSO device I have :)  Admittedly I never played with the GTA04.

> It seems this adds up to an indication that the modem doesn't really do
> CNMA, and the patch that I've submitted does the trick and allows
> incoming SMSes to be received successfully.

You might need to rework the hso driver to detect/handle the GTM601 
separately.  Adding another vendor quirk to do so.

Regards,
-Denis

Re: [PATCH 2/2] receive-sms: Support printing received SMS with non-ASCII characters

[Denis Kenzior]

[-- Attachment #1: Type: text/plain, Size: 743 bytes --]

Hi Neil,

On 11/20/2014 07:48 PM, Neil Jerram wrote:
> Without this I get the following Python traceback, for an SMS that
> contains the UK pound sign.
>
> ERROR:dbus.connection:Exception in handler for D-Bus signal:
> Traceback (most recent call last):
>    File "/usr/lib/python2.7/dist-packages/dbus/connection.py", line 230, in maybe_handle_message
>      self._handler(*args, **kwargs)
>    File "./receive-sms", line 9, in incoming_message
>      print("%s" % (message))
> UnicodeEncodeError: 'ascii' codec can't encode character u'\xa3' in position 51: ordinal not in range(128)
> ---
>   test/receive-sms | 2 +-
>   1 file changed, 1 insertion(+), 1 deletion(-)

Patch has been applied, thanks.

Regards,
-Denis

Re: [PATCH 1/2] sms: Option HSO modem can't really do CNMA

[Neil Jerram]

[-- Attachment #1: Type: text/plain, Size: 1602 bytes --]

I've been working on SMS function with oFono.  oFono prefers to get
+CMT indications for received SMSs - which it requests by issuing
AT+CNMI=2,2... - instead of +CMTI indications that would be requested
by AT+CNMI=2,1...  But my observation is that the GTA04 modem doesn't
in fact generate +CMT indications for received SMSs (even when
instructed to do so by AT+CNMI=2,2...).

I can submit an oFono patch to issue AT+CNMI=2,1... when talking to a
GTM601, and so get +CMTI indications (which it handles fine).

Before I do that, however, can anyone confirm or deny that the GTM601
really can't do +CMT indications?

QtMoko for GTA04 issues AT+CNMI=2,1 and handles +CMTI indications.
FSO has a config setting named "sim_buffers_sms", and sends
AT+CNMI=2,1 if that setting is true, or AT+CNMI=2,2 if false; and the
GTA04 config has sim_buffers_sms=true.  Is that because others have
tried using +CMT before and found it not to work?

Many thanks,
      Neil


PS. I haven't forgotten the possibility of using fsogsmd instead of
oFono.  I'm still working with oFono at the moment because I have some
application-level code that speaks to its dbus APIs.

PPS. In case anyone is surprised that I'm still working on GTA04 stuff
after recently saying that I'd finished my experimentation...  It's
because I've been remotivated by NeilBrown's kernel work, and
particularly by having a kernel that reliably plays audio.  So thanks
Neil!

PPPS. My discussion so far about this on the oFono mailing list is at
https://lists.ofono.org/pipermail/ofono/2014-November/015520.html