[Ajay Garg <ajaygargnsit@xxxxxxxxx>]

On Tue, Nov 19, 2013 at 4:37 PM, Pascal Quantin <pascal.quantin@xxxxxxxxx> wrote:

2013/11/19 Ajay Garg <ajaygargnsit@xxxxxxxxx>

Hi Pascal.

Thanks for the electrifyingly-quick reply :)

On Tue, Nov 19, 2013 at 4:10 PM, Pascal Quantin <pascal.quantin@xxxxxxxxx> wrote:

Hi Ajay,

2013/11/19 Ajay Garg <ajaygargnsit@xxxxxxxxx>

Hi all.

We are capturing some GSM-MAP messages over SCTP, and doing some diagnostic testing.

In some packets, we receive a USSD string, encoded in GSM-7-bit format.

I will take a particular example, to illustrate the issue.

The string (GSM 7-bit encoded) is

#################################################
c2301b249dbb6439d7cc060219e5e53248186687dde332483a77c96aaeda0d640fb3d3e4343d0f82dd5e30d94b068bd15ca0e65b5e0691d3613648158bc554b1914b4195d100
#################################################

Wireshark shows the corresponding string as

#################################################
Bal Rs.29.36  Free Balance Rs.25.57 validity 07/02/2014. More dial *111*1#.
T24@
#################################################

Now, we wrote a 7-to-8-bit-ASCII-converter locally at our end, and we get the decoded message as

#################################################
Bal Rs.29.36  Free Balance Rs.25.57 validity 07/02/2014. More dial *111*1#.
T24
#################################################

As is seen, there is no "@" character at the end.

On some more head-banging, we realised that our local decoding seems to be in fact correct, and there seems to be something wrong with the decoded Wireshark message.

The last byte of the message is "00", and there is no way it can be decoded to a "@".

In fact, if we replace the last "00" with "80", we get the "@" at the end (at our local decoding setup, that is).

We will be really grateful, if we could get some light on the "@" appearing at the end in the Wireshark's decoded USSD-string.

We will be happy to share more information about our local decoding-code, but I guess we are missing something obvious :P

Looking forward to a reply :)

Thanks and Regards,
Ajay

'@' is usually displayed due to the padding bits at the end of the buffer. I already fixed such bugs in the past in SMS decoding.

Ahhh.. ok.

 

Could you indicate us with Wireshark release you tested, whether it happens with 1.10.3?

 

We tested with 1.6.7, on an Ubuntu 12.04-LTS.

I don't remember backporting the fixes in 1.6 branch. Moreover I just looked at the GSM MAP dissector and the bug is probably still present. To be verified.

 

Moreover if you can share a pcap file, I will happily have a look at it.

 

I don't think that is required now; your reply suffices, and is absolutely to-the-point :)

Just one last query, is there a particular reason why someone would send padding-bits ?

I ask this, because we get the "padding bits" in only some USSD-strings, and not all USSD-strings.

Depending on the number of characters you have in the buffer, you will end up with unused bits to finish the current byte.

Hmm.. I am sorry I don't quite get this :-\

Of course, I understand that there might be unused bits in the last byte, but in the present case, we are getting a full byte (8 bits) as a padding-byte/padding-bits.

Anyhow, thanks a ton .... thanks a lot for the quick resolution to the subject-of-this-email :)

 

Pascal.

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

Thanks and Regards,
Ajay