Huge thanks to our Platinum Members Endace and LiveAction,
and our Silver Member Veeam, for supporting the Wireshark Foundation and project.

Wireshark-dev: [Wireshark-dev] Proposal: Multiline display filter input field

From: Jirka Novak <j.novak@xxxxxxxxxxxx>
Date: Fri, 2 Mar 2018 15:45:06 +0100
Hi all,

  I would like to discuss topic I have in my head for long time...

  I'm working with wireshark daily and quite often I'm working with long
display filters. I start with:

(ip.addr == 172.16.31.8) && (ip.addr == 172.16.31.24) && (udp.port==8192)

  which we can understand as (<SERVER>) && (<CLIENT>) && (<DATA_FLOW>).

  As I'm investigating data, I need to add more addresses to SERVER
list, to CLIENT list etc. E.g.:

((ip.addr == 172.16.31.8) || (ip.addr == 172.16.31.9)) && ((ip.addr ==
172.16.31.24) || (ip.addr == 172.16.31.36)) && (udp.port==8192 ||
udp.port==8194)

  When list of addresses is longer, it is longer then display space for
input item. Then it is very difficult task to find correct place in
input field (SERVER, CLIENT, DATA_FLOW) and edit it.
  Apply as Filter and Prepare as Filter do not help much. Macros do not
help too. Save/restore of filter do not help too as the list of
addresses changes with every pcap.

  Therefore I'm thinking about this:
  Allow display input field to be multiline. Then I can write the filter:

(
ip.addr == 172.16.31.8
) && (
ip.addr == 172.16.31.24
) && (
udp.port==8192
)

 updates will be much easier as the filter is well arranged:

(
(ip.addr == 172.16.31.8) || (ip.addr == 172.16.31.9)
) && (
(ip.addr == 172.16.31.24) || (ip.addr == 172.16.31.36)
) && (
udp.port==8192 || udp.port==8194
)

  Consequences:
  I think that only "a few" changes must be done:
a) every display filter editor item must be changed to multiline
b) every display filter show item must be changed to ignore new line
separators (show filter in compact form)
c) save/restore tools should save/restore filters including new line
separators
d) display filter processor must ignore new line characters

  I think it make sense to implement it in Qt only. I can work on it.

  What do you think about it?

						Best regards,

							Jirka Novak