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.
