Validation of display filter

Question

Our current code provides a GUI which will allow users to create filters. These filters are to be used when performing a live capture or an offline capture when reading a pcap file. We also provide the user with a button which will start Wireshark, reading in a file, performing a display filter and going to a specified packet; I.e. "C:\Program Files\Wireshark\Wireshark.exe" -R "tcp or udp" -g10 -r "C:\tmp\test.pcap"

By default, we try to use the same filter when starting Wireshark that was used on this file when we performed an offline capture. We realize that, in some cases, the syntax is different between the "display filter" and the "capture filter". Is there any way we can validate the "display filter" before starting Wireshark? If the validation fails, we'd like to display a popup which would tell the operator, that the filter is invalid and allow them to enter a different filter.

I.e. "port 5001" is a valid capture filter but an illegal display filter. We would like to tell the user that this filter is illegal and give them an opportunity to enter a valid filter.

Accepted Answer

0

You could run tshark in quiet mode to test the filter and then parse the output of tshark and the value of %errorlevel% (Windows)

Sample of a good filter:

tshark -nr input.pcap -q -R "tcp"
echo %errorlevel%
0

Sample of a wrong filter:

tshark -nr input.pcap -q -R "test"
tshark: "test" is neither a field nor a protocol name.
echo %errorlevel%
2

UPDATE:

If you add the option '-c 1' and a 'custom' display filter (frame.number), you are able to test the validity of the user defined display filter pretty fast with tshark.

tshark -nr input.pcap -R "frame.number" -R "filter to test" -c 1 -q

If the user specified a wrong filter, the whole command will fail (see above).

If the user specified filter is correct, your own 'custom' filter will abort the command after the first matching packet, which is always the first read packet with the filter 'frame.number'.

Regards
Kurt

answered 24 Jun '13, 05:07

Kurt Knochner ♦
24.8k●10●39●237
accept rate: 15%

edited 24 Jun '13, 19:05

Kurt,

Thanks for the suggestion. I was hoping there was an easier way to validate the filter (i.e. using the jnetpcap api).

Your suggestion works. Unfortunately, I'm processing some pcap files that have over a million packets. If the filter is "bad", the process returns immediately, but if the filter is good, it could take minutes to return. I got around this by doing the following:

Process proc = Runtime.getRuntime().exec("tshark -nr input.pcap -q -R "tcp"");
int exitVal = 0;
try {
   exitVal = proc.exitValue();
} catch (IllegalThreadStateException e) {
   proc.destroy();
}

At this point, I'll just act on the value of exitVal. If exitVal is 0, either it completed successfully or it was running and I destroyed the process. If exitVal is something other than 0, the filter was bad and I'll dispaly a message to the user.

Do you know of any jnetpcap api that will validate without having to go through this process.

Thanks, Scott

(24 Jun '13, 07:22) sabordn

(I converted your "answer" to a "comment" as that's how this site works best, please see the FAQ for details.)

Why not use a synthetic capture file (without any packets, just the pcap file header) to check the filter with tshark?

(24 Jun '13, 07:38) SYN-bit ♦♦

Do you know of any jnetpcap api that will validate without having to go through this process.

As Wireshark display filters are a feature of Wireshark, there is no other library to check the validity of a display filter than Wiresharks code itself.

Please try to add the following option to tshark to speed up this check (see man page):

-c 2

Regards
Kurt

(24 Jun '13, 07:40) Kurt Knochner ♦

@Kurt, that was my initial idea too, however, if the filter does not match any packets in the file, tshark will still read the whole file.

(-c X means to stop after X displayed packets, not after reading X packets, this was a "bug" I fixed years ago :-) )

(24 Jun '13, 07:43) SYN-bit ♦♦

1

How about modifying Kurt's test slightly:

A valid filter:

echo "" | wireshark-gtk2\tshark.exe -2R "tcp" -i - Capturing on 'Standard input'

echo %errorlevel% 0

An invalid filter:

echo "" | wireshark-gtk2\tshark.exe -2R "test" -i - tshark: "test" is neither a field nor a protocol name.

echo %errorlevel% 2

This should avoid any long delays with reading large capture files.

(24 Jun ‘13, 08:32) cmaynard ♦♦

however, if the filter does not match any packets in the file, tshark will still read the whole file.

ah, good to know. I did not check. I just relied on the text of the man page ;-)

(24 Jun ‘13, 09:21) Kurt Knochner ♦

I’d like to thank everyone for their help… Adding the packet count solved my problem. The process returns immediately even with a very large file.

(24 Jun ‘13, 11:24) sabordn

1

Good to hear.

As of the comment of @SYN-bit:

if the filter does not match any packets in the file, tshark will still read the whole file.

You can circumvent this problem, by adding a second filter that always matches within the first few packets, like this:

tshark -nr input.pcap -R “frame.number” -R “filter to test” -c 1 -q

If the user specified filter is wrong, the whole command will fail.

If the user specified filter is correct, your own filter will abort the command after the first matching packet, which is always the first read packet with the filter ‘frame.number’

Hint: If a supplied answer resolves your question can you please “accept” it by clicking the checkmark icon next to it. This highlights good answers for the benefit of subsequent users with the same or similar questions.

(24 Jun ‘13, 18:18) Kurt Knochner ♦

showing 5 of 8 show 3 more comments