2012/5/21 Balazs Nagy <nagybalazs.nb1@xxxxxxxxx>:
> 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
>
Hi Balazs,
could you try with the latest trunk version (can be found here:
http://www.wireshark.org/download/automated/ )? Some changes were done
in revision 42064 that might help you.
If you can still trigger the issue, could you fill a bug
(https://bugs.wireshark.org/bugzilla/) and attach the pcap file?
Thanks and regards,
Pascal.