Re: ModemManager: Huawei PDU encoded USSD response truncated to 112 characters
- From: Graham Inggs <graham inggs uct ac za>
- To: networkmanager-list gnome org
- Subject: Re: ModemManager: Huawei PDU encoded USSD response truncated to 112 characters
- Date: Tue, 15 Nov 2011 07:45:40 +0200
I have copied the relevant section from 3GPP TS 23.038 (
http://www.3gpp.org/ftp/Specs/html-info/23038.htm ) below.
The way I understand this, USSD and CBM are padded with 0x0d, not SMS
(possibly because in the case of SMS the length is known?).
Can the patch from my previous post ( truncated_pdu_ussd_fix_v2.diff
), which works with the current gsm_unpack() in src/mm-charsets.c, be
188.8.131.52.1 Packing of 7 bit characters
Packing of 7 bit characters in USSD strings is done in the same way as
for SMS (clause 184.108.40.206). The character stream is bit padded to octet
boundary with binary zeroes as shown above.
If the total number of characters to be sent equals (8n 1) where
n=1,2,3 etc. then there are 7 spare bits at the end of the message. To
avoid the situation where the receiving entity confuses 7 binary zero
pad bits as the @ character, the carriage return or <CR> character
(defined in clause 6.1.1) shall be used for padding in this situation,
just as for Cell Broadcast.
If <CR> is intended to be the last character and the message
(including the wanted <CR>) ends on an octet boundary, then another
<CR> must be added together with a padding bit 0. The receiving entity
will perform the carriage return function twice, but this will not
result in misoperation as the definition of <CR> in clause 6.1.1 is
identical to the definition of <CR><CR>.
The receiving entity shall remove the final <CR> character where the
message ends on an octet boundary with <CR> as the last character.
On Wed, Nov 9, 2011 at 11:05 PM, Graham Inggs <graham inggs uct ac za> wrote:
> Well, here's the thing, USSD does not tell us how long the decoded
> string will be, so at the time we call gsm_unpack() we don't know the
> exact length so we can only assume that it is (bin_len * 8) / 7 as per
> my previous patch.
> I attach a new patch which, after decoding, checks whether the last
> character in a 7-byte block is padding (0x0d) and drops it if it is
> (for the case when our 7-byte block only contained 7 characters).
> This works for Huawei modems that use PDU encoded USSD, if it is found
> that this works for all modems and for SMS as well, perhaps this
> should be moved into gsm_unpack() in src/mm-charsets.c.
>> Right, that's my change. Does the USSD path in the plugin know the
>> length of the text, or does it have to derive the text length from the
>> length of the hex string? If it doesn't know the length, it's going to
>> have the same problem I was seeing with SMS messages prior to this
>> change, where gsm_unpack() couldn't tell if a trailing 7-byte block
>> had 7 or 8 GSM7 characters in it.
>> - Nathan
] [Thread Prev