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

In a .pcap file opened in Wireshark, how do you know which response (packet) belongs to a particular request (packet)?

0

OK so I had seen a .pcap file which showed a few GSM MAP packets (there were 4 or 5 packets I guess) on the internet, but I can't find it anymore. So for this question I am using another one which shows only packet, but please imagine that there are a few packets showing MAP requests (which have something like invoke processUnstructuredSS in the Info column) and MAP responses (showResultLast processUnstructuredSS).

So imagine that we have the following sequence of MAP messages in Wireshark .pcap file:

GSM MAP REQUEST processUnstructuredSS
GSM MAP REQUEST someOtherMAPMessage_B
GSM MAP REQUEST someOtherMAPMessage_C
GSM MAP REQUEST processUnstructuredSS
GSM MAP REQUEST processUnstructuredSS
GSM MAP RESPONSE someOtherMAPMessage_B
GSM MAP RESPONSE processUnstructuredSS
GSM MAP RESPONSE processUnstructuredSS
GSM MAP RESPONSE someOtherMAPMessage_C

My question is that how do I find out which particular response packet belongs to which request?

For example, how do I know which processUnstructuresSS response packet belongs to the FIRST request packet?

alt text

asked 17 Sep '16, 04:45

Jesss's gravatar image

Jesss
51141720
accept rate: 0%


2 Answers:

2

With GSM MAP the answer actually lies in the TCAP layer. If you:

  1. Enable both TCAP Service Response Time/SRT preferences
  2. Look at the [Stat] section of the TCAP dissection in a response

... then you'll get a link back to the original request. For example, using one of the sample captures I found I got this:

Frame 95: 131 bytes on wire (1048 bits), 131 bytes captured (1048 bits)
Ethernet II, Src: 01:01:01:01:01:01, Dst: 02:02:02:02:02:02
Internet Protocol Version 4, Src: 1.1.1.1, Dst: 2.2.2.2
Stream Control Transmission Protocol, Src Port: 2904 (2904), Dst Port: 2904 (2904)
MTP 2 User Adaptation Layer
Message Transfer Part Level 3
[CHINESE_ITU_STANDARD]
Signalling Connection Control Part
Transaction Capabilities Application Part
    end
    [Stat]
        [Session Id: 4]
        [Begin of session in frame 89]
        [Session duration: 1.099000000 seconds]
GSM Mobile Application

The TCAP dissector figures out the relationship based on the SCCP Called and Calling addresses as well as the (TCAP) dialog ID(s).

answered 20 Sep '16, 18:06

JeffMorriss's gravatar image

JeffMorriss ♦
6.2k572
accept rate: 27%

..which is an excellent point (thank you, @JeffMorriss), but it still requires that you are lucky enough that the SCCP called address of the response can be identified as referring to the same endpoint as the SCCP calling address of the request.

(21 Sep '16, 01:06) sindy

True. There is an SCCP preference ("Set source and destination GT addresses") which can sometimes (depending on the situation) help with that. The commit message that added the preference explains it thus:

Add a preference that allows the user to decide if they want the calling and called GTs (if RI=GT) put in the (pinfo) source and destination (and thus into the source and destination columns).

This may help (if the PCs change but the GT does not) or hurt (if the GT or RI change but the PCs do not) TCAP's ability to identify which messages belong to which TCAP "session."

(21 Sep ‘16, 07:33) JeffMorriss ♦

Assuming that the SCCP calling party of the request, and thus the SCCP called party of the response, is usually a “big piece of equipment” (as compared to the SCCP called party of the request which is usually a subscriber), would it make sense to extend the SCCP configuration with a user-configurable list of “locally” (i.e. at the point of capture) valid translations of the few E.164 (or eventually also E.212) numbers assigned to the locally interesting “big pieces of equipment” to their point codes and SSNs, making it possible to pair the requests with responses also where the address types of the request’s calling and response’s called cannot be compared directly?

Indexing that table by interface id and bundling it somewhere into the pcapng data, like IP to hostname translations can be, would be an extra luxury :-)

(21 Sep ‘16, 09:30) sindy

Funny, I would have initially made the opposite assumption: that the request’s Called address was the big piece of equipment (e.g., an HLR). :-)

As for the idea: honestly I never had much problem with Wireshark as it was–but I was further down the food^Wequipment chain than a majority of people using that stuff (i.e., my exposure was more limited than a person debugging a live SS7 network every day).

(And now I’m out of the Telco environment entirely…)

(21 Sep ‘16, 10:42) JeffMorriss ♦

2

For popular protocols which intrinsically provide fields allowing to unambiguously map the relationship between messages, Wireshark dissectors do that for you as these protocols are interesting for many people so a lot of development effort has been spent on them.

For less popular protocols which intrinsically provide fields allowing to unambiguously map the relationship between messages, this may not be the case but it is relatively easy to use MATE to use the fields provided by existing dissectors and add metafields, allowing you to track the relationships, to protocol dissections.

For protocols using SCCP as transport, like in your example, no fields unambiguously mapping relationship of packets are available in general, so you have to look at your particular capturing environment and see whether you are lucky enough or not.

For these protocols, the sender of a request sends it with calling and called SCCP addresses which may both get translated as the messages are forwarded through the network, so a request's SCCP calling address may look quite different from the resulting response's SCCP called address although in the local context both identify the same equipment. Plus, in particular for MAP, you don't always get a response from the same equipment to which you have sent the request.

What could help a bit here would be to make dissectors of all the SS7 layers provide E.164 numbers in a uniform format (which they currently don't so numbers extracted from different layers cannot be matched against each other without format conversion, which MATE does not support) and differentiate these fields' names from one another (which some of these dissectors don't do as well, they give you several fields named just e164 without a chance to tell a calling from called or any other one).

After such enhancement, it would be possible to use MATE to match numbers from the application layer (e.g. MAP) with numbers from the SCCP layer, so at least in cases where the SCCP address contains the E.164 number as its Global Title portion, you would be able to find relationships between messages automatically.

If you feel like that, you can file a bug with severity "enhancement" for that.

answered 17 Sep '16, 07:01

sindy's gravatar image

sindy
6.0k4851
accept rate: 24%

edited 17 Sep '16, 11:44