Wireshark mailing list archives

wrongly decoded mt-forwardSM


From: Balazs Nagy <nagybalazs.nb1 () gmail com>
Date: Mon, 21 May 2012 09:59:17 +0200

Hello everybody!

I've faced a problem during decoding an SMS sending process.

The situation is the following:

I sent 2 SMs to a mobile which was turn to offline. So in first round these
SMs were stored in the SMSC. When the mobile was turn ON again the SMSC got
an alert and try to sent the two SMs.
The delivery was completely successful but in the wireshark capture I saw
that the second mt-forwardSM is missing. I found only an *invoke forwardSM (
**message type:** SMS-DELIVER REPORT**) *after the first *mt-forwardSM*.
This invoke forwardSM was weird for me so I copied the GSM SMS TPDU
(SMS-DELIVER REPORT) part into another decoder tool and I found that this
forwardSM is my last mt-forwardSM what I was looking for.
Then I start to search for some known bugs about this issue on the
wireshark website and I found the following old mail:

http://www.wireshark.org/lists/wireshark-users/200612/msg00124.html

Based on this mail I checked the 3GPP TS 03.40 SMS standard. Here I found
that TP-MTI contains the type of the message and SMS-DELIVER and
SMS-DELIVER REPORT has the same value:
bit no. 0: 0
bit no. 1: 0

I think the problem is that in this case wireshark decode this message
wrongly because it also checks the TP-MMS part(bit no. 3) too to decide the
TP-MTI correctly.

On MAP level this message was identified as an SMS-DELIVER REPORT message
instead of SMS-DELIVER.

Could you check me whether it is really a decoding problem in the wireshark?

Br,
Balazs Nagy
___________________________________________________________________________
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

Current thread: