[PATCH 1/1] qmi: support SMS receive on Quectel EC21

[PATCH 1/1] qmi: support SMS receive on Quectel EC21

[Jonas Bonn]

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

The Quectel EC21 does not provide the SMS PDU on the message event
notification.

This patch adds a call to 'raw read' on the message ID from the event
notification if the event notification does not already contain the
message data.

The message data begins with the SMSC length, type, and address so
the TPDU length is adjusted accordingly in the raw_read callback.  This
differs from the way the raw message data is handled in the case
that it is included in the event notification itself.  As I don't have
access to any other QMI modem at this time, I'm can not confirm that
this difference is reasonable.
---
 drivers/qmimodem/sms.c | 57 ++++++++++++++++++++++++++++++++++++++++++++++++++
 drivers/qmimodem/wms.h |  9 ++++++++
 2 files changed, 66 insertions(+)

diff --git a/drivers/qmimodem/sms.c b/drivers/qmimodem/sms.c
index 3f4bdeb..7e6baec 100644
--- a/drivers/qmimodem/sms.c
+++ b/drivers/qmimodem/sms.c
@@ -334,9 +334,38 @@ error:
 	g_free(cbd);
 }
 
+static void raw_read_cb(struct qmi_result *result, void *user_data)
+{
+	struct ofono_sms *sms = user_data;
+	const struct qmi_wms_raw_message* msg;
+	uint16_t len;
+	uint16_t error;
+
+	if (qmi_result_set_error(result, &error)) {
+		DBG("Raw read error: %d (%s)", error,
+			qmi_result_get_error(result));
+		return;
+	}
+
+	/* Raw message data */
+	msg = qmi_result_get(result, 0x01, &len);
+	if (msg) {
+		uint16_t plen;
+		uint16_t tpdu_len;
+
+		plen = GUINT16_FROM_LE(msg->msg_length);
+		tpdu_len = plen - msg->msg_data[0] - 1;
+
+		ofono_sms_deliver_notify(sms, msg->msg_data, plen, tpdu_len);
+	} else {
+		DBG("No message data available at requested position");
+	}
+}
+
 static void event_notify(struct qmi_result *result, void *user_data)
 {
 	struct ofono_sms *sms = user_data;
+	struct sms_data *data = ofono_sms_get_data(sms);
 	const struct qmi_wms_result_new_msg_notify *notify;
 	const struct qmi_wms_result_message *message;
 	uint16_t len;
@@ -360,6 +389,34 @@ static void event_notify(struct qmi_result *result, void *user_data)
 		DBG("msg format %d PDU length %d", message->msg_format, plen);
 
 		ofono_sms_deliver_notify(sms, message->msg_data, plen, plen);
+	} else {
+		/* The Quectel EC21, at least, does not provide the
+		 * message data in the event notification, so a 'raw read'
+		 * needs to be issued in order to query the message itself
+		 */
+		struct qmi_param *param;
+
+		param = qmi_param_new();
+		if (!param)
+			return;
+
+		/* Message memory storage ID */
+		qmi_param_append(param, 0x01, sizeof(*notify), notify);
+		/* The 'message mode' parameter is documented as optional,
+		 * but the Quectel EC21 errors out with error 17 (missing
+		 * argument) if it is not provided... we default to 3GPP
+		 * here because that's what works for me and it's not clear
+		 * how to actually query what this should be otherwise...
+		 */
+		/* Message mode */
+		qmi_param_append_uint8(param, 0x10,
+				QMI_WMS_MESSAGE_MODE_GSMWCDMA);
+
+		if (qmi_service_send(data->wms, QMI_WMS_RAW_READ, param,
+					raw_read_cb, sms, NULL) > 0)
+			return;
+
+		qmi_param_free(param);
 	}
 }
 
diff --git a/drivers/qmimodem/wms.h b/drivers/qmimodem/wms.h
index 21fe4d9..7e18ec9 100644
--- a/drivers/qmimodem/wms.h
+++ b/drivers/qmimodem/wms.h
@@ -25,6 +25,8 @@
 
 #define QMI_WMS_RAW_SEND		32	/* Send a raw message */
 
+#define QMI_WMS_RAW_READ		34	/* Read raw message from storage*/
+
 #define QMI_WMS_GET_MSG_LIST		49	/* Get list of messages from the device */
 #define QMI_WMS_SET_ROUTES		50	/* Set routes for message memory storage */
 #define QMI_WMS_GET_ROUTES		51	/* Get routes for message memory storage */
@@ -66,6 +68,13 @@ struct qmi_wms_param_message {
 
 #define QMI_WMS_MESSAGE_MODE_GSMWCDMA		1
 
+struct qmi_wms_raw_message {
+	uint8_t msg_tag;
+	uint8_t msg_format;
+	uint16_t msg_length;
+	uint8_t msg_data[0];
+} __attribute__((__packed__));
+
 /* Get routes for message memory storage */
 #define QMI_WMS_RESULT_ROUTE_LIST		0x01
 #define QMI_WMS_PARAM_ROUTE_LIST		0x01
-- 
2.9.3

Re: [PATCH 1/1] qmi: support SMS receive on Quectel EC21

[Alexander Couzens]

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

Hi Jonas,

I'm working on Gobi2000 sms support atm and having the same problem.

> +	} else {
> +		/* The Quectel EC21, at least, does not provide the
> +		 * message data in the event notification, so a 'raw
> read'
> +		 * needs to be issued in order to query the message
> itself
> +		 */
> +		struct qmi_param *param;
> +
> +		param = qmi_param_new();
> +		if (!param)
> +			return;
> +
> +		/* Message memory storage ID */
> +		qmi_param_append(param, 0x01, sizeof(*notify),
> notify);
> +		/* The 'message mode' parameter is documented as
> optional,
> +		 * but the Quectel EC21 errors out with error 17
> (missing
> +		 * argument) if it is not provided... we default to
> 3GPP
> +		 * here because that's what works for me and it's
> not clear
> +		 * how to actually query what this should be
> otherwise...
> +		 */
> +		/* Message mode */
> +		qmi_param_append_uint8(param, 0x10,
> +				QMI_WMS_MESSAGE_MODE_GSMWCDMA);
> +
> +		if (qmi_service_send(data->wms, QMI_WMS_RAW_READ,
> param,
> +					raw_read_cb, sms, NULL) > 0)
> +			return;
> +
> +		qmi_param_free(param);
>  	}

Could you create a raw read request function? For the Gobi2000 I'll
need the same function on powering to clean up the whole storage.

Best,
Alexander
-- 
Alexander Couzens

mail: lynxis(a)fe80.eu
jabber: lynxis(a)fe80.eu
mobile: +4915123277221
gpg: 390D CF78 8BF9 AA50 4F8F  F1E2 C29E 9DA6 A0DF 8604

[-- Attachment #2: attachment.sig --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [PATCH 1/1] qmi: support SMS receive on Quectel EC21

[Jonas Bonn]

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

On 10/16/2017 04:07 PM, Alexander Couzens wrote:
> Hi Jonas,
>
> I'm working on Gobi2000 sms support atm and having the same problem.
>
>> +	} else {
>> +		/* The Quectel EC21, at least, does not provide the
>> +		 * message data in the event notification, so a 'raw
>> read'
>> +		 * needs to be issued in order to query the message
>> itself
>> +		 */
>> +		struct qmi_param *param;
>> +
>> +		param = qmi_param_new();
>> +		if (!param)
>> +			return;
>> +
>> +		/* Message memory storage ID */
>> +		qmi_param_append(param, 0x01, sizeof(*notify),
>> notify);
>> +		/* The 'message mode' parameter is documented as
>> optional,
>> +		 * but the Quectel EC21 errors out with error 17
>> (missing
>> +		 * argument) if it is not provided... we default to
>> 3GPP
>> +		 * here because that's what works for me and it's
>> not clear
>> +		 * how to actually query what this should be
>> otherwise...
>> +		 */
>> +		/* Message mode */
>> +		qmi_param_append_uint8(param, 0x10,
>> +				QMI_WMS_MESSAGE_MODE_GSMWCDMA);
>> +
>> +		if (qmi_service_send(data->wms, QMI_WMS_RAW_READ,
>> param,
>> +					raw_read_cb, sms, NULL) > 0)
>> +			return;
>> +
>> +		qmi_param_free(param);
>>   	}
> Could you create a raw read request function? For the Gobi2000 I'll
> need the same function on powering to clean up the whole storage.

I'm not sure that the invocation of 'raw read' looks the same when 
iterating over the storage (from 'list messages'???) as when querying 
the data from an event...

/Jonas


>
> Best,
> Alexander

Re: [PATCH 1/1] qmi: support SMS receive on Quectel EC21

[Jonas Bonn]

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

Hi Alexander,

On 10/16/2017 04:07 PM, Alexander Couzens wrote:
> Hi Jonas,
>
> I'm working on Gobi2000 sms support atm and having the same problem.
> Could you create a raw read request function? For the Gobi2000 I'll
> need the same function on powering to clean up the whole storage.

Could you explain what you are trying to do here?  Why would you clear 
the SMS storage every time the modem powers up?

I also don't see that ofono actually supports deleting messages from the 
modem's storage... if you know how this is supposed to work, please 
enlighten me.

/Jonas

>
> Best,
> Alexander

Re: [PATCH 1/1] qmi: support SMS receive on Quectel EC21

[Alexander Couzens]

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

Hi Jonas,

> Could you explain what you are trying to do here?  Why would you
> clear the SMS storage every time the modem powers up?
> 
> I also don't see that ofono actually supports deleting messages from
> the modem's storage... if you know how this is supposed to work,
> please enlighten me.

the Gobi2000 doesn't accept the routes with TRANSFER_AND_ACK nor
STORAGE_TYPE_NONE.

Reading out the store is also useful if the modem is receiving any
SMS while ofono isn't runing. E.g. while booting, the sms would never
made it to ofono.

I don't know (yet) how the different routes are working in detail. This
is on my list. But I've faced edge cases when the NV was full, the
modem rejects receiving any messages, regardless if the modem should
save it to it.

Best,
lynxis
-- 
Alexander Couzens

mail: lynxis(a)fe80.eu
jabber: lynxis(a)fe80.eu
mobile: +4915123277221
gpg: 390D CF78 8BF9 AA50 4F8F  F1E2 C29E 9DA6 A0DF 8604

[-- Attachment #2: attachment.sig --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [PATCH 1/1] qmi: support SMS receive on Quectel EC21

[Denis Kenzior]

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

Hi Jonas,

On 10/16/2017 07:20 AM, Jonas Bonn wrote:
> The Quectel EC21 does not provide the SMS PDU on the message event
> notification.
> 
> This patch adds a call to 'raw read' on the message ID from the event
> notification if the event notification does not already contain the
> message data.
> 
> The message data begins with the SMSC length, type, and address so
> the TPDU length is adjusted accordingly in the raw_read callback.  This
> differs from the way the raw message data is handled in the case
> that it is included in the event notification itself.  As I don't have
> access to any other QMI modem at this time, I'm can not confirm that
> this difference is reasonable.
> ---
>   drivers/qmimodem/sms.c | 57 ++++++++++++++++++++++++++++++++++++++++++++++++++
>   drivers/qmimodem/wms.h |  9 ++++++++
>   2 files changed, 66 insertions(+)
> 

Applied, thanks.

Regards,
-Denis

Re: [PATCH 1/1] qmi: support SMS receive on Quectel EC21

[Denis Kenzior]

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

On 10/17/2017 06:41 AM, Alexander Couzens wrote:
> Hi Jonas,
> 
>> Could you explain what you are trying to do here?  Why would you
>> clear the SMS storage every time the modem powers up?
>>
>> I also don't see that ofono actually supports deleting messages from
>> the modem's storage... if you know how this is supposed to work,
>> please enlighten me.

oFono does not manage the message store.  The implicit assumption is 
that all SMS messages are delivered immediately without hitting ME/SMS 
storage.  oFono takes care of notifying the history plugin and sending 
the ACK.

For those devices that don't support immediate delivery it is assumed 
that the sms atom driver takes care of the details.  So on startup the 
driver is supposed to grab all messages from the store, notify the core 
and then delete all of them.  Any subsequent messages that are delivered 
to the store, should be notified up to the core and the storage space freed.

See how the atmodem sms driver does this.  E.g. +CMTI delivery vs +CMT

> 
> the Gobi2000 doesn't accept the routes with TRANSFER_AND_ACK nor
> STORAGE_TYPE_NONE.
> 
> Reading out the store is also useful if the modem is receiving any
> SMS while ofono isn't runing. E.g. while booting, the sms would never
> made it to ofono.

This is a weird case as the modem should not be in radio on mode anyway. 
  But yes this is possible...

> 
> I don't know (yet) how the different routes are working in detail. This
> is on my list. But I've faced edge cases when the NV was full, the
> modem rejects receiving any messages, regardless if the modem should
> save it to it.
> 

On an unrelated note, can you guys look at the WIP mbimmodem plugin and 
see if the parsing/building approach taken there is applicable (in some 
modified form) to QMI?  E.g. to simplify the drudgery of building / 
parsing QMI messages.

Regards,
-Denis