Huge thanks to our Platinum Members Endace and LiveAction,
and our Silver Member Veeam, for supporting the Wireshark Foundation and project.

Wireshark-dev: Re: [Wireshark-dev] Defining global filters?

From: Jeff Morriss <jeff.morriss.ws@xxxxxxxxx>
Date: Thu, 21 Aug 2014 09:12:08 -0400
On 08/19/14 04:27, Anders Broman wrote:


-----Original Message-----
From: wireshark-dev-bounces@xxxxxxxxxxxxx [mailto:wireshark-dev-bounces@xxxxxxxxxxxxx] On Behalf Of Jeff Morriss
Sent: den 18 augusti 2014 20:53
To: Developer support list for Wireshark
Subject: Re: [Wireshark-dev] Defining global filters?

On 08/18/14 09:46, Anders Broman wrote:
Hi,

How to define filters and display the data of fields that may occur in
multiple protocols? One example is IMSI ( International Mobile
Subscriber identity) that exists in multiple 3GPP and 3GPP2 protocols,
following a call flow through the system it could be interesting to
filter on IMSI across multiple protocols to build a filter covering
all messages in the call flow.

(I suppose I may sound rather repetitive at this point--sorry--but...) this is exactly what MATE's good at (and was created for).

For example I still have a MATE configuration file loaded (though I haven't actually used it in months) which adds an "IMSI" filter to Diameter >Answer messages because I needed to find a answer with
IMSI=1234 and Result-Code=5678.  It could easily be modified to also pick the IMSI out of other protocols (like GTPv2).

I never got around to sit down and understand how to use MATE, I've been thinking of making something similar in C
Custom made to make a"Trace ID" filter for "call chains" I'd be interested in. Like SIP calls changing Call Id when crossing Call servers and associate Diameter, ISUP, H248 etc to the "Call" if possible. Digging out all the related messages from a "Call" in a >500Mb file can be time consuming...

Oh, just to mention: yes, that's *exactly* the use case MATE was created for.

It's really not that hard once you get the hang of it; the biggest problem is that the docs on the wiki are 75% wrong (using the old format). I really, really, really should do something about that. <sigh>