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

Packets using certain plugins are displayed using a lower level plugin in the packet list after sorting

0

I am trying to fix a strange bug with some dissector plugins, but am not sure where to begin. The bug affects certain packets which use these plugins and causes them to be displayed in the packet list using a lower-level plugin. The packet details for these packets are normal. The bug happens when you sort by source, destination, protocol, or info in the packet list pane, and affects only those packets which have not been visible in the packet list pane since the last time the pcap file was loaded. This means that if you were to scroll down the packet list until packet No. 15 is at the bottom of the visible packet list, then packet 16 onward will display incorrectly.

broken packets

This is a screenshot of a bugged packet list. Before sorting, all of the packets displayed as GSM SMS, but now after sorting by Destination and sorting back to No., all of the packets after number 6 are displaying incorrectly. The detailed information is still there in the details pane, but it is not displayed in the packet list pane.

These plugins were written by a former employee and they are quite complicated, so it will take me a while to look through them all looking for anything out of place. Has anyone ever seen a bug like this, and if so, what did you do about it? If not, have you any suggestions where in the plugin I might look to find the problem?

asked 21 May '14, 10:52

Thomas%20G's gravatar image

Thomas G
26459
accept rate: 100%

edited 22 May '14, 01:51

grahamb's gravatar image

grahamb ♦
19.8k330206


One Answer:

1

Probably the call to the nex dissector (MTP3) is don under if(tree) which is incorrect. The subdissector should allways be called.

answered 21 May '14, 13:35

Anders's gravatar image

Anders ♦
4.6k952
accept rate: 17%

In which method would I look for if(tree) in the IMF plugin?

(22 May '14, 05:49) Thomas G

From the screenshot above it looks like the IMF plugin calls the MTP3 dissector, check if that's done under if(tree) or some other condition.

Typically a dissector has a main function dissect_foo() and after a few lines of code writing to columns and the main tree it has

if(tree){ "dissect the rest of the frame, perhaps calling other routines..." }

if the call to the MTP3 dissector is done inside this if statement that's probably the problem.

(22 May '14, 06:34) Anders ♦

Removing if(tree) from the plugins seems to fix the problem, but I'm afraid to remove something like that when I'm not entirely sure what it's for. Is there any danger in just removing if(tree)?

(22 May '14, 09:01) Thomas G

If(tree) is used to optimize the code to not perform what's inside the statement if the tree isn't present/vissible e.g packet details required.

(22 May '14, 09:17) Anders ♦