This is a static archive of our old Q&A Site. Please post any new questions and answers at ask.wireshark.org.

TCAP Decoding Bug

0

Hi !

I can see that Wireshark has a problem decoding TCAP packet (showing only DATA and hex stream), if tcap packet is longer than 127 bytes. Usually TCAP is set of tag/len/data constructors, where tag and len are 1-byte, but they support extensions as well (len high bit is set to 1 and continuing on a next bytes)

asked 14 Jan '13, 06:05

ahmediukas's gravatar image

ahmediukas
215610
accept rate: 0%

edited 14 Jan '13, 14:12

JeffMorriss's gravatar image

JeffMorriss ♦
6.2k572

What version are you using? Do you mean the packet is more than 127 octets long?

I'm currently looking at a TCAP message that is (after being reassembled) 374 octets long. A sample capture--which you could upload to e.g., http://cloudshark.org --would help.

(14 Jan '13, 06:46) JeffMorriss ♦

I am using the latest version (just downloaded for this case).

Here is the sample: http://public.alesfree.com/sample.pcap

and printscreen of what is decoded http://public.alesfree.com/sample.jpg

(14 Jan '13, 08:15) ahmediukas

I think the problem is in begining 6281a7

Usually 0x81 would mean length (62 is tag), but since it uses high bit (128), other bits (1) tells how many length octets are following defining the length (which is a7 in this case)

(14 Jan '13, 08:16) ahmediukas

One Answer:

2

Thanks for the sample capture. Actually the problem is simpler: the Called and Calling SSNs are both 146 and the Camel dissector does not, for some reason, register for that SSN.

Go to Edit->Preferences->Protocols->Camel and add 146 to the list of SSNs there. With that change my Wireshark shows a Camel initialDP.

(Does anyone know why Camel doesn't register for SSN 146--which is its registered SSN?)

answered 14 Jan '13, 08:32

JeffMorriss's gravatar image

JeffMorriss ♦
6.2k572
accept rate: 27%

Ah, i was only looking for fragmentation in sccp chunks, even didnt check the ssn's :) Thx for hint I also deleted 6-9 in camel as this is for gsm map ssn's

(14 Jan '13, 13:28) ahmediukas
1

(BTW I clicked the check box to indicate that my answer was Accepted so this question no longer shows up in the list of unanswered questions.)

(14 Jan '13, 14:11) JeffMorriss ♦

I fixed the Camel dissector so that it registers for SSN 146 (instead of 6-9) in r47097. That change will show up in the development builds and Wireshark 1.10.0.

(15 Jan '13, 08:45) JeffMorriss ♦

Jeff, maybe is simillar issue, Wireshark does not show what primitive holds data 0a0101 before the last two MTP's filler nulls. When I click on it, it just tells SCCP packet, but i dont see where excactly (neither in TCAP). Here is example: http://cloudshark.org/captures/eab9fe741ab8

(20 Jan '13, 16:09) ahmediukas
1

Hmmm, it would appear to me that the sender has stuck another SCCP parameter on the end of the Unitdata. UDTs have only 3 parameters (they don't support optional parameters) so I'd say the sender has a bug. Well, even if it's not supposed to be a parameter the sender still has a bug.

The parameter (if that's what it's supposed to be) would be a Release Cause (0x0a) of length 1 (the first 0x01) with a value of End User Congestion (the 2nd 0x01).

(I suppose the SCCP dissector could do a better job of warning of such weirdness but...)

(21 Jan '13, 11:50) JeffMorriss ♦

thanks JeffMorriss ♦

(15 Sep '13, 23:14) Sridhar Kumar N
showing 5 of 6 show 1 more comments