Filtering in wireshark is extremely slow compared to tshark

Question

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?

Answer 1

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 ♦
19.8k●3●30●206
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

Answer 2

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.