Greetings! I was asked today to decode a PCAP format capture file that Wireshark (1.12.3) could not decode. From looking at the exported octets, I could tell that the stack is: Ethernet:IPv4:SCTP:(unknown layer header of 9 octets):MTP3:SCCP:TCAP:MAP/IS41/CAMEL The nine octets are always of the form: 01 (1d,3d,6e,6f) 06 01 00 00 00 (33,4a,69,6b,6c,6d,73,81,8e,91,9d,bd) 3f So you can see the 2nd octet has four possible values, and the 8th octet had 12 different values. The rest of the octets were static. I am tempted to think this is a "user-adaptation" layer, with the 1st octet being the version, but usually the 2nd octet would be "spare" and should be zero. The 5th,6th,7th,8th octets appear to be the length starting with the MTP3 SIO. I have no idea what the 3f is for. I went through all possible "Decode As" for SCTP and turned up nothing. Any help would be appreciated. asked 06 May '15, 13:31  tiger762 |
2 Answers:
Looks like M2PA version 2 to me. To decode it edit your M2PA preferences to set the SCTP port appropriately and then select draft version 2 of the RFC. (The 2nd octet is spare and is supposed to be 00 but the rest of the bytes line up.) answered 07 May '15, 06:14  JeffMorriss ♦ |
What is the value of SCTP's payload protocol identifier? That should give you a pretty clear indication: http://www.iana.org/assignments/sctp-parameters/sctp-parameters.xhtml#sctp-parameters-25 If it's using an unassigned value, I don't think it's really possible to say without more context behind where the capture was taken. All things being equal I would normally assume M2xA between SCTP and pure MTP3, but as you note those field values are not consistent with them, particularly as they are storing values in what would be their reserved field. answered 06 May '15, 18:13  Quadratic Sorry, I should have been more clear. The SCTP PPID is zero/unknown. This is in the context of a telecom customer sending data in to our STP. What I ended up doing is looking at the raw octets. The MTP3 SIO octet (0x83, national/SCCP) with a 09 (SCCP UNITDATA) 8 octets downstream, followed by one of: [00,01,80,81] (class / error handling) followed by 03 (pointer to called party address). I wrote a small program to locate MTP3 then copy from that point forward to the end of the packet into a new PCAP file. I set the encapsulation type to MTP3 in the global header, and gave them back a new PCAP which has everything below MTP3 discarded. The unknown PPID as well as the data in what is probably a "spare" octet, is what I found disturbing. (07 May '15, 05:14) tiger762 |
Excellent! Thank you so much!
That worked perfectly. By default, I was trying to decode it as RFC4165 and so Wireshark was looking for BSN/FSN which aren't there.
You're welcome. Please be sure to Accept the answer (by clicking the check mark) so this question disappears from the list of unanswered questions.