Re: [PATCH 1/2] smsutil: sms_decode() allow to pass sms with unknown TPDU size

[Alexander Couzens <lynxis@fe80.eu>]

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

Hi Denis,

> Hi Alexander,
> 
> On 05/16/2017 10:49 AM, Alexander Couzens wrote:
> > Certain modems (QMI based) only return a PDU length, but without
> > the length of the TPDU.  
> 
> It looks like the current QMI_WMS_RESULT_NEW_MSG_NOTIFY assumes that
> the message doesn't have an SMSC preceeding it.  Or is it that we are
> not parsing some other parameters?

The nice thing here is:
When receiving a SMS PDU over the notify callback, it doesn't contain a
SC address, but when reading it from NV it does.

> > Without passing this information over ofono_sms_deliver_notify()
> > down to sms_decode(), sms_decode() will fail, as it try to
> > interpret the SC header as PDU header.  
> 
> How do we know when a PDU contains the SC address and when it doesn't?
I don't know. Sorry, I didn't read (yet) the whole spec. 

Originally I though it would be possible and a good idea to detect SC,
but sms_decode_address_field() can exit early with success and
sms_decode() fail later when decoding. A second pass is then required.
I dropped that idea and use fixed expectation, hopefully QMI behave the
same way on different devices.

> [..]

> > b) export sms_decode_address_field() which is part of smsutil.h
> > would mean using this function only to get the length of TPDU and
> > throw away the result (address), which is later called a second
> > time.  
> 
> In-tree drivers can freely utilize core utilities such as smsutil and 
> stkutil.  So this isn't really a problem.  Since the QMI API is quite 
> dumb, then parsing the SC address field twice is probably the least
> evil way to do this.

Ok. Will do it that way.

-- 
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 --]