Home page logo
/

wireshark logo Wireshark mailing list archives

Re: 3GPP 23.038 encoding and string length
From: mmann78 () netscape net
Date: Tue, 24 Dec 2013 08:30:15 -0500 (EST)


Isn't it simple enough to add a proto_tree_add_gsm_sms_item (or similar) API and enforce the hf_ variables have 
ENC_3GPP_TS_23_038 encoding?  Shouldn't that be able to wrap the gsm_sms_char_7bit_unpack() / gsm_sms_chars_to_utf8()?  
I don't think the meaning of the length field of proto_tree_add_item should be different based on encoding, but the 
length in proto_tree_add_gsm_sms_item could be number of characters.

 

-----Original Message-----
From: Pascal Quantin <pascal.quantin () gmail com>
To: Developer support list for Wireshark <wireshark-dev () wireshark org>
Sent: Tue, Dec 24, 2013 5:46 am
Subject: [Wireshark-dev] 3GPP 23.038 encoding and string length




Hi all,


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.
We had several bugs in this area in GSM SMS and ANSI 637 dissectors (adding an extra '@' character at the end of the 
buffer due to padding 0 bits) that I fixed some time ago (those protocols specify in another field the number of 
characters to decode).
ETSI CAT specification asks to add an explicit <CR> in this situation to avoid the problem.
GSM MAP dissection is wrong (as briefly discussed on -users: 
http://www.wireshark.org/lists/wireshark-users/201311/msg00014.html) and needs to make use of the lengthInCharacter 
variable like what is done in GSM SMS / ANSI 637 dissectors.

If we want to start using ENC_3GPP_TS_23_038 for the remaining dissectors using gsm_sms_char_7bit_unpack() we need to 
find a solution for this.

Should we change the length parameter meaning to represent the number of characters rather than the buffer size? This 
would be a major difference compared to other encoding and it might be difficult to handle correctly number of bytes to 
highlight. Or maybe we should continue handling it manually as it was before...

Thoughts?


Thanks,
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

 
___________________________________________________________________________
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

  By Date           By Thread  

Current thread:
[ Nmap | Sec Tools | Mailing Lists | Site News | About/Contact | Advertising | Privacy ]