Wireshark-dev: Re: [Wireshark-dev] Defining global filters?
From: Anders Broman <[email protected]>
Date: Tue, 19 Aug 2014 08:27:51 +0000
-----Original Message-----
From: [email protected] [mailto:[email protected]] 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...

>> Suggestion:
>> Create global_filters.[ch] in epan/dissectors or
>> (packet-global_filters?) define functions to parse the data there 
>> and/or export the hf Variable to be used in the protocol dissectors.
>Initially that seems very wrong to me; "global" sounds too wide of a scope to me.
>Why not put the IMSI dissector and filter in the E.212 dissector?  The same could be applied to MSISDNs (E.164).
>How many other identifiers are we talking about?  Could they be lumped into existing "dissectors" like those two?

Well those two were the first ones coming to mind. I'll go with your suggestion here I think. The plan then would be to replace all
IMSI and MSISDN fields with e164.msisdn and e212.imsi, if you want to see it only in one protocol you'd have to do something like
(Gtpv2 && e212.imsi==012345678901234)


Sent via:    Wireshark-dev mailing list <[email protected]>
Archives:    http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
             mailto:[email protected]?subject=unsubscribe