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 So imagine that we have the following sequence of MAP messages in Wireshark .pcap file: My question is that how do I find out which particular response packet belongs to which request? For example, how do I know which
asked 17 Sep '16, 04:45  Jesss |
2 Answers:
With GSM MAP the answer actually lies in the TCAP layer. If you:
... then you'll get a link back to the original request. For example, using one of the sample captures I found I got this: 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 ♦ |
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 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 edited 17 Sep '16, 11:44 |
..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.
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:
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 :-)
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…)