Re: SIP filter issues

["Manolis Katsidoniotis" <manoska () gmail com>]

Ok, many thanks Guy

 

2 more questions in case you or anyone else happens to have any ideas:

 

Question 1

In order to reduce captured traffic we also use capture filters.

However the "highest" layer I can see is TCP/UDP (using ports).

 

I'm not familiar with higher layer examples like the smtp below
but especially for SIP
or even capture filter examples of the type         field[4:18]>200

in which case I could filter out half the clause during capture and the
other half during viewing

 

 



 

 

For example the controller I'm testing uses the same interface for all SIP
subscribers
but is receiving H.248 traffic from various gateways with different IPs.

 

Using IP capture filter I can isolate each gateway's traffic during capture
(so I can test simultaneously & unaffected with other colleagues)
but I am forced to store all SIP traffic for all gateways in the result file

 

This way I could "filter out" all "non-correlating" SIP subscribers based on
the number.

 

Any ideas ?

 

 

Question 2

 

The filter I used as example is not actually used in wireshark.

It is provided as input in tshark which reads files and produces some
statistics for view (like below - it actually runs through a simple script
and reads each file separately).

 

Is this the same case (I mean when I use tshark) or is there another option
to combine the filters more efficiently?

 



 

 

Many thanks folks

Manolis

 

 

-----Original Message-----
From: wireshark-users-bounces () wireshark org
[mailto:wireshark-users-bounces () wireshark org] On Behalf Of Guy Harris
Sent: Monday, January 16, 2012 9:10 PM
To: Community support list for Wireshark
Subject: Re: [Wireshark-users] SIP filter issues

 

 

On Jan 16, 2012, at 8:53 AM, Manolis Katsidoniotis wrote:

 

> I am filtering a wireshark trace with

>

> ((sip.Status-Code==487)&&(sip.to.user contains 46710000))

>

> In other words my intended action is

> "please display all 487 status lines for subscribers 46710000* "

> or something like: "please show the failed calls for subscribers 46710000*
"

>

> however some packets are sent via TCP and are thus multiplexed in TCP 

> stream frames the filter displays a "matching" result which contains 2
packets:

>

> - 1 with 487 response which I am interested in but for subscribers 

> that I'm "not" interested in ... so the packet is useless

>

> - 1 with other response (180 Ringing) which I'm "not" interested in 

> but for subscribers that I am interested in ... so this packet is also 

> useless

>

> According to my opinion this is a bug in wireshark.

> My intention is to display frames in which the filter criteria match 

> in the "same" packet

 

Unfortunately, that's not how the display filter mechanism works.  The
semantics of the display filter language are that

 

                {field name} {relational operator} {value}

 

matches all packets that contain at least one instance of the field named
{field name} where the relational operator {relational operator} applies to
the value of that field and to the value {value}.

 

The Boolean && and || operators just test the two filter expressions
independently and combine them, so they don't force the two operations to
act on the same PDU for some particular protocol.

 

The simplicity of the filter mechanism's semantics can produce some
unexpected results - another example is that

 

                ip.addr != XXX

 

is not the same as

 

                !(ip.addr = XXX)

 

but complicating the semantics might produce other unexpected (and perhaps
undesired) results.

 

There would need to be an additional mechanism in the filter language to
force them to act on the same PDU - and that mechanism would have to
sensibly deal with combinations of filter terms that aren't for the same
protocol, or arrange that they can't be for the same protocol; an example of
the latter might be something such as

 

                sip.{Status-Code == 487 && to.user contains 46710000}

 

where the syntax explicitly limits all the terms to apply to a particular
protocol.

___________________________________________________________________________

Sent via:    Wireshark-users mailing list <
<mailto:wireshark-users () wireshark org> wireshark-users () wireshark org>

Archives:     <http://www.wireshark.org/lists/wireshark-users>
http://www.wireshark.org/lists/wireshark-users

Unsubscribe:  <https://wireshark.org/mailman/options/wireshark-users>
https://wireshark.org/mailman/options/wireshark-users

 
<mailto:wireshark-users-request () wireshark org?subject=unsubscribe>
mailto:wireshark-users-request () wireshark org?subject=unsubscribe

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