How to filter MAP request by msisdn and its response

thanks for the answer! Would you give me some pointers as to how i would have to configure mate in order to filter the outgoing package by msisdn and the incoming packet to match the oid field of the outgoing package?

There are no pointers other than the manual already pointed to.

Or, if it has discouraged you, you can accept my proposal from the answer:

If you need a pushstart, publish a trace with at least two independent requests and responses.

Because I won't spend time creating a useless MATE configuration; to put together a useful one, I need the pcap file to debug it.

I have shared a link (on the original post) where you can download the pcap file. Please let me know. And thanks for your support !

Here we go:

Pdu map_pdu Proto gsm_map Transport tcap/sccp {
    Extract trans_id From tcap.otid;
    Extract trans_id From tcap.dtid;
    Extract msisdn From gsm_map.msisdn ;
};
Gop tcap_dialog On map_pdu Match (trans_id) {
Start(msisdn);
Extra(msisdn);
};
Done;

It is really minimalistic - I am not 100% sure what else on top of TCAP transaction ID has to be checked so that the PDUs could be safely considered a matching request and answer. If you would capture somewhere closer to the HLR and multiple GMSCs would query the same HLR, I guess nothing prevents them from incidentally using the same transaction ID, so the GT of the GMSC should also be part of the Gop key. But integrating that requires more effort because while tcap.otid is only present in the invoke and tcap.dtid is only present in the returnResultLast, the calling and called GT is present in both but with swapped roles, which has to be sorted out using Transform. And you cannot use both GTs without filtering because the GT of the HLR as called in the invoke differs from the GT of the VLR as calling in the returnResultLast, so the (gt,gt) AVPL of the invoke and returnResultLast would differ, preventing the PDUs from matching the same GoP key. Plus this analysis completely ignores cases where one of the SCCP (calling, called) would e.g. not contain the GT but just the point code.

This MATE configuration (Edit->Preferences->Protocols->Mate->Configuration Filename, followed by OK and starting a new instance of Wireshark), allows you to use a display filter mate.tcap_dialog.msisdn == “91:95:95:17:41:01:10” to filter an invoke/returnResultLast pair by msisdn. Unfortunately, the format is like this and cannot be changed as this is how the gsm_map dissector provides it.

Wow, as it turned out to be impossible to achieve the goal of Extracting both SCCP called and SCCP calling into two AVPs of the same name but, depending on presence of other fields allowing to discriminate between invoke and returnResultLast, keeping as part of the Gop key only that one of the two which represented the GMSC using Transform, I’ve discovered another feature of MATE not explicitly mentioned in the documentation.

Apparently it is possible to define several MATE Pdus of the same type but with different description, and get all of them created in parallel from the very same source PDU. So together with the possibility to Accept a Pdu depending on an AVPL match, it is possible to Extract a (gmsc_gt, trans_id) AVPL from (sccp.calling.digits, tcap.otid) in one case and from (sccp.called.digits, tcap.dtid) in another, and Accept only the one whose AVPL contains the trans_id. So effectively, for the invoke where only the tcap.otid is present, the value of the gmsc_gt AVP is taken from the sccp.calling.digits, while for the returnResultLast, it is taken from the sccp.called.digits because in that message, only the tcap.dtid is present.

So the result is as follows:

Pdu map_msg Proto gsm_map Transport tcap/sccp {
Extract trans_id From tcap.otid;
Extract gmsc_gt From sccp.calling.digits;
Extract msisdn From gsm_map.msisdn;
Criteria Accept Strict (trans_id);
};

Pdu map_msg Proto gsm_map Transport tcap/sccp {
Extract trans_id From tcap.dtid;
Extract gmsc_gt From sccp.called.digits;
Criteria Accept Strict (trans_id);
};
Gop tcap_dialog On map_msg Match (trans_id,gmsc_gt) {
Start(msisdn);
Extra(msisdn);
};
Done;

I guess I’ll have to update the Wiki accordingly soon.