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 <[email protected]> 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 > [email protected] > http://mail.gnome.org/mailman/listinfo/networkmanager-list _______________________________________________ networkmanager-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/networkmanager-list
