Wireshark mailing list archives

Re: Defining global filters?


From: Anders Broman <anders.broman () ericsson com>
Date: Tue, 19 Aug 2014 08:27:51 +0000



-----Original Message-----
From: wireshark-dev-bounces () wireshark org [mailto:wireshark-dev-bounces () wireshark org] 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)

Regards
Anders

___________________________________________________________________________
Sent via:    Wireshark-dev mailing list <wireshark-dev () wireshark org>
Archives:    http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
             mailto:wireshark-dev-request () wireshark org?subject=unsubscribe
___________________________________________________________________________
Sent via:    Wireshark-dev mailing list <wireshark-dev () wireshark org>
Archives:    http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
             mailto:wireshark-dev-request () wireshark org?subject=unsubscribe


Current thread: