Re: ModemManager: Huawei PDU encoded USSD response truncated to 112 characters

[Dan Williams <dcbw redhat com>]

On Tue, 2011-11-15 at 07:45 +0200, Graham Inggs wrote:
> 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
> pushed please?

Pushed, thanks.  We probably do need this in the generic USSD code but
that'll require some testing.

Dan

> 6.1.2.3.1 Packing of 7 bit characters
> 
> Packing of 7 bit characters in USSD strings is done in the same way as
> for SMS (clause 6.1.2.1). 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
> >
> _______________________________________________
> networkmanager-list mailing list
> networkmanager-list gnome org
> http://mail.gnome.org/mailman/listinfo/networkmanager-list