Re: SIP filter issues

[Guy Harris <guy () alum mit edu>]

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 <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