I tested V2 and V2.2 for my pcap file. but both version can not decode one SCCP message (same issue on other pcap file for Attach_rej or Auth_Rej DTAP messages) but V1.10 or V.12 can decode it. I can't share my pcap file. please tell me how to fix it. I have Attached both image: |
One Answer:
Looks like you're running into bug 11130. The workaround is to disable SCCP reassembly (that will cause all the PDUs to be dissected as RANAP). You might want to add yourself to the Cc: list of that bug to track its progress. answered 19 Sep '16, 08:04  JeffMorriss ♦ |
I Think there is a bug in recent versions (after 2.0)
How to verify the bug?
Can you share a capture in a publicly accessible spot, e.g. CloudShark?
In general, if privacy concerns prevent you from publishing the problematic capture, the choices are the following:
save only the problematic frame to a separate file and publish that single-frame file (which may not address all privacy issues and may not illustrate the issue enough if the frame needs some context so that the issue occurs. In your particular case you have the tools to check that the behaviour is the same on a single frame).
[file a bug][1] and mark the attached capture file as a private one, which will make it accessible only to the core developers.
use a tool with anonymization capabilities like Tracewrangler before publishing the file (in your case, this is not a choice as I guess the identifiers you want to keep secret are not only in the IP layer)
export the frame in question as a hex dump, anonymize it manually, re-import it back to check that the addresses have changed while Wireshark's handling has not, and publish the resulting capture file.
Temporal file Link [48 Hours]: Link
4th message has been attached. 2nd and 3rd chunk could not be decoded by ver2+
Please note if you have same issue on Ver2+ [windows]
I do, but given the Answer of @JeffMorris, it's not a surprise.
well... maybe there are actually two issues?
First, there is a workaround of the bug @JeffMorris refers to. With 2.2.0, you can use
File -> Export PDUs to Fileand chooseOSI Layer 3as export type. This will create a new capture file and open it instead of the original one. In the new file, each MTP3 and above part of the original frames gets its own frame (with a special encapsulation but that shouldn't bother you much).The second point is whether the decoding of the first RANAP message is correct or not. In your screenshots, the summary description of the first message in the dissection pane differs, while in packet list it is the same (id-Iu-Release). Do you disagree with how the messages are dissected after exporting them as described above?