This is a static archive of our old Q&A Site. Please post any new questions and answers at ask.wireshark.org.

Filtering in wireshark is extremely slow compared to tshark

0

I have a capture file with Modbus/RTU traffic. I'm using user DLT to set it as mbrtu protocol. The file contains about 450000 packets. I would like to apply this filter in wireshark

!(mbrtu.unit_id==50 || mbrtu.unit_id==49) || mbrtu.crc16.incorrect

but it tooks about 15 minutes to perform filtering. In tshark using following command, it tooks just 7 seconds with the same result.

tshark -2 -R "!(mbrtu.unit_id==50 || mbrtu.unit_id==49) || mbrtu.crc16.incorrect" -r rs485.pcap -w errors.pcap

When i split input file using editpcap command to chunks with just 50000 packets, it tooks 3 seconds in wireshark to perform filtering for that file. Simple linear approximation told me, that it should took 9*3=27 seconds to process original file and not 900 seconds.

I'm using Wireshark 2.2.5 on Linux. I have Intel [email protected] and 8GB of RAM. Wireshark takes just 300 MB of RAM and utilizes one core at 100%.

Am I doing something wrong? Is there some way to speed up the wireshark gui?

asked 23 Mar '17, 13:21

j123b567's gravatar image

j123b567
6113
accept rate: 0%

edited 23 Mar '17, 13:26


2 Answers:

0

Without having done any investigation note that your tshark command line is just read filtering and then writing to the output whereas Wireshark is filtering and displaying. Not sure if that accounts for all the difference though, you would need to profile the runs to see what's going on.

answered 24 Mar '17, 02:46

grahamb's gravatar image

grahamb ♦
19.8k330206
accept rate: 22%

Loading and displaying the file without filter tooks 0.7 seconds. Loading the file in Wireshark with read filter tooks 7 seconds (same as tshark), but filter can't be undone - I must reload the file with different filter. I will try the same on Windows machine. I don't have time to profile the Wireshark now, but will try it in the future.

(24 Mar '17, 03:00) j123b567

Same on windows, linux wireshark (qt5) and linux wireshark-gtk. Maybe, there are some GUI updates during display filtering that drastically decrease performance.

(24 Mar '17, 04:02) j123b567

mbrtu.crc16.incorrect do you get a lot of incorrect checksums? if so perhaps expert items are produced and cause poor performance? If you are able to share the file you could open a bug report so someone could take a look.

(24 Mar '17, 05:10) Anders ♦

After filtering, there is about 132 incorrect packets in ~450k captured. Ok, I can open bug report for this. Until then, here is the file to play with https://jaybee.cz/files/rs485.pcap.gz

(24 Mar '17, 05:41) j123b567

To what protocol should the DLT be connected?

(27 Mar '17, 03:42) Anders ♦

@Anders mbrtu

(29 Mar '17, 03:33) j123b567
showing 5 of 6 show 1 more comments

0

Hi, I think the problem is with the code in packet-mbtcp.c function dissect_modbus_response() on the second pass when it tries to find the corresponding request it goes through all packets from the end. The code should be changed to separate conversation and per packet data and store the per packet data only on the first pass for retrieval on the second pass.

answered 04 Apr '17, 04:13

Anders's gravatar image

Anders ♦
4.6k952
accept rate: 17%

This sounds good. I just don't understand, why tshark works, because it should also perform two-pass dissection. (I have used parameter -2). It is also completely wrong to search corresponding response in mbrtu, because it will always be the next message or nothing.

(04 Apr '17, 04:26) j123b567

Although possibly not related to the issue, Modbus TCP allows multiple requests to be "in flight" so it's not guaranteed that the response will be in the next "message".

(04 Apr '17, 07:37) grahamb ♦

If you can please test or deskcheck https://code.wireshark.org/review/#/c/20927/1

(05 Apr '17, 04:33) Anders ♦