Re: 3GPP 23.038 encoding and string length

[Pascal Quantin <pascal.quantin () gmail com>]

2013/12/29 Pascal Quantin <pascal.quantin () gmail com>

> Hi
>
> 2013/12/28 Guy Harris <guy () alum mit edu>
>
> > On Dec 24, 2013, at 2:43 AM, Pascal Quantin <pascal.quantin () gmail com>
> > wrote:
> >
> > > r54428 introduced a ENC_3GPP_TS_23_038 encoding type so as to be able
> > to use proto_tree_add_item directly instead of manually decoding the string
> > with gsm_sms_char_7bit_unpack() / gsm_sms_chars_to_utf8() functions.
> > > While it is a very good idea (much more easier to use) it raises an
> > interesting issue. With this 7 bits encoding a payload of 7 bytes will hold
> > either 7 or 8 characters. This is handled by gsm_sms_char_7bit_unpack()
> > function thanks to an extra parameter specifying the number of characters.
> >
> > Presumably that's the out_length parameter (which doesn't appear to be
> > checked before every character is written to the output string); the
> > in_length parameter counts input octets, not output characters.  However,
> > out_length appears primarily to be used when extracting into a fixed-length
> > buffer, with the buffer length passed as the out_length argument.
> As you said the purpose of out_length is to give the maximum number of
> characters to be unpacked. In packet-gsm_sms.c, this parameter is begin set
> with udl value (with a protection in case udl variable would be bigger than
> the output buffer). In packet-ansi_637.c, num_fields represents the number
> of characters to be decoded.
>
> > GSM MAP is encoded using ASN.1 BER, and USSD-String is an OCTET STRING,
> > so BER gives its length in octets, not characters, and it's preceded by
> > lengthInCharacters, giving its length in characters.
>  Yes.
>
> > In that case, we need to make sure we don't process more than the
> > specified number of bytes and don't process more than the specified number
> > of characters.  If ({number of characters}*7 + 7)/8 > {number of bytes},
> > there should probably be an expert info reporting an error; we might want
> > to dissect all the characters we can extract from the specified number of
> > bytes, at least.  If {number of bytes} < {number of characters}*7 + 7)/8,
> > we might also want to warn that there are too many padding bytes, and
> > dissect {number of characters} characters.  In both those cases, a "number
> > of characters" count is all that needs to be passed to the string-extractor
> > or item-adder routine; if ({number of characters}*7 + 7)/8 > {number of
> > bytes}, the "number of characters" count should be ({number of bytes}*8)/7
> > rather than {number of characters}.
> >
> > For the ETSI TS 102 223 v10.0.0/3GPP TS 11.14 v8.17.0/3GPP TS 31.111
> > v9.7.0 smart card stuff, however, the text string appears to just be a TLV,
> > so you only get a length in bytes; presumably padding should be ignored in
> > that case, and we can just use proto_tree_add_item() or
> > tvb_get_string_enc().
> The specification defines a rule where the originator must explicitly add
> a <CR> if needed to avoid the padding bits:
> "If the total number of characters in the text string 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 (i.e. <CR>) character shall be
> used for padding in this situation, as defined in TS 123 038", So
> proto_tree_add_item is fine (probably the only case).
>
> > Are there cases where only the length in characters is given?
> 3GPP/3GPP2 SMS (packet_gsm_sms.c and packet_ansi_637.c).
>
> The Network Name information element in packet-gsm_a_dtap.c gives the
> number of padding bits in the last octet so it can be easily compute the
> number of characters.
> I did not check GMR1 and SMS Cell Broadcast specs yet.
I committed a first version of proto_tree_add_ts_23_038_7bits_item() /
tvb_get_ts_23_038_7bits_string() functions in r54534 and updated the
existing dissectors to use it.
I did not change the GSM MAP dissector yet as I would like to find a sample
pcap file containing a USSD for testing purpose.

Pascal.

___________________________________________________________________________
Sent via:    Wireshark-dev mailing list <wireshark-dev () wireshark org>
Archives:    http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
             mailto:wireshark-dev-request () wireshark org?subject=unsubscribe