Decoding of TP-UD ignores length of TP-UD (TP-UDL)

[GoogleCodeExporter]

Currently the TP-UDL is ignored decoding 7-bit TP-UD payload - we just carry on 
until we run out of TP-UD data. This creates an issue when the last 7 bits of 
the packed octet are padded with 0 bits to fill up the last octet of TP-UD - 
how do we know if the last septet is GSM 03.38 '@' COMMERCIAL AT or if it is 
just 7 bits of zero padding? The answer is we should check the TP-UDL.

If the DCS indicates 7 bit encoding then the TP-UDL indicates the length in 
septets, else the TP-UDL indicates the length in octets.

Original issue reported on code.google.com by andrew.basterfield@dialogue.net on 3 Sep 2012 at 9:49

Attachments:

• packing.diff

[GoogleCodeExporter]

Fixing this issue

http://code.google.com/p/smslib/issues/detail?id=501

would have unmasked the issue - before 501 the scenario was always covered up.

Original comment by andrew.basterfield@dialogue.net on 3 Sep 2012 at 9:52

[GoogleCodeExporter]

Try again - example PDU for regression

07914400000000004409D0CD3A9B9E060000218013917295043F0500030F02026AB55AAD56ABD96C
369BCD66B3D96CB7DBED76BBDD6EB71B0E87C3E170381C0E97CBE572B95C2E97CB815AA0710E672E
C700

Note TP-UDL is 0x3F (63 septets) but there is 56 octets of TP-UD = 64 septets, 
so the last septet must be padding to the octet boundary.

Original comment by andrew.basterfield@dialogue.net on 3 Sep 2012 at 1:32

Attachments:

• packing.diff

[GoogleCodeExporter]

Original comment by admin@smslib.org on 4 Sep 2012 at 7:52

• Changed state: Open

[GoogleCodeExporter]

r2347

Thanks.

Original comment by admin@smslib.org on 4 Sep 2012 at 8:38

• Changed state: Completed
• Added labels: Priority-Medium, Milestone-v3.5.3, Component-SMSLib

[GoogleCodeExporter]

Original comment by admin@smslib.org on 6 Mar 2013 at 9:27

• Changed state: Fixed