ANNOUNCEMENT: Live Wireshark University & Allegro Packets online APAC Wireshark Training Session
April 17th, 2024 | 14:30-16:00 SGT (UTC+8) | Online

Wireshark-users: Re: [Wireshark-users] Display filters for application protocols

From: Lukáš Oliva <olivalukas@xxxxxxxxx>
Date: Tue, 8 Mar 2011 19:43:34 +0100
   Hello Jeff, Andy and Chris,
actually this is what I somehow expected. Is there a way how to filter
out just the packets I want? Like: filter out all frames containing
LIR message but display only LIR messages? I mean could I somehow
filter this using capture filters (I think this is not possible, but
just for sure) or how to use display filters with some more precise
configuration saying display LIR messages only?

  Best regards
  Lukas


2011/3/8 Jeff Morriss <jeff.morriss.ws@xxxxxxxxx>:
> Lukáš Oliva wrote:
>>
>>  Hello to the community,
>> I am doing some testing for the Diameter protocol and I noticed
>> interesting behaviour of the display filters. I noticed that if I run
>>
>> tshark -r mypcap.pcap -R "diameter.cmd.code==302"
>>
>> then the output contains afterwards also Diameter packets with
>> different diameter.cmd.code. I am not sure if it is actually a bug and
>> how tshark handles this filtering for application protocols.
>> E.g.: If there is a packet on containing more Diameter (or other
>> application protocol) messages on IP (or possibly TCP) level, how is
>> this will the display filter filter all of them?
>>
>> Just for the illustration:
>>
>> 1  TCP packet: Diameter message 1 (LIR), Diameter message 2 (MAR),
>> Diameter message 3 (SAR)
>>
>> Running tshark -r mypcap.pcap -R "diameter.cmd.code==302" ... # so
>> filtering out the LIR messages which have message code 302
>>
>> Should the tshark produce a list of LIR messages only?
>
> This is normal behavior.  The read/display you have above means:
>
> There exists a field named "diameter.cmd.code" with the value 302 in this
> *frame*.
>
> If the frame passes that filter, it is displayed.
>
> In other words, while Wireshark's TCP dissector is capable of handling
> multiple upper-layer messages in a given frame, the underlying architecture
> is still frame-based.
>
> (You'll see this a lot with SCTP chunk bundling too.)
> ___________________________________________________________________________
> Sent via:    Wireshark-users mailing list <wireshark-users@xxxxxxxxxxxxx>
> Archives:    http://www.wireshark.org/lists/wireshark-users
> Unsubscribe: https://wireshark.org/mailman/options/wireshark-users
>            mailto:wireshark-users-request@xxxxxxxxxxxxx?subject=unsubscribe
>