Hi, I have some problems with custom dissectors and coloring rules. I 'm using the latest version of Wireshark (tried on both x86 and x64 machines). I have some dissectors for proprietary protocols (and, until now, they have worked well). In this case I have a transport protocol named XNL which contains (in its payload) another protocol XCMP. The problem is that not all the (same protocol) packets are colored, some are treated as TCP packets. In the image I highlighted one packet who should be marked (and colored green) as XCMP. The "strange" thing is that it seems to be recognized as XNL and colored as TCP.
The image below show an XCMP packet right recognized and colored..
Any idea on what could be the cause? [EDIT] Here two XCMP packets: one correctly recognized (on the left) and one not (on the right):
Thanks in advance. asked 04 Feb '16, 07:16  Barzo edited 04 Feb '16, 08:40 showing 5 of 7 show 2 more comments |
One Answer:
In both of the failing screenshots you'll note that the packet is marked as a TCP Retransmission (in the Info column). By default (IIRC) Wireshark will not call subdissectors (such as, in your case, the Motorola XNL dissector) on "error" packets such as retransmissions (since many upper-layer protocols get confused when they see the same data more than once). When the subdissector is not called the traffic will only be decoded up to the TCP layer so Wireshark won't recognize the traffic as belonging to the subdissector/higher-level protocol. If you want to change that behavior you'd need to turn off the "Do not call subdissectors for error packets" TCP preference. answered 04 Feb '16, 13:46  JeffMorriss ♦ Hi @JeffMorriss, I had already tried to disable that option (I also tried to uncheck "Analyze TCP sequence number" but the behavior does not change. Also these packets are marked as "suspected retransmission" but I don't understand why...they are not retransmissions because one is a "request" (192.168.10.2 -> 192.168.10.1) and one is a "reply" (192.168.10.1 -> 192.168.10.2). (05 Feb '16, 00:20) Barzo
At this point screenshots stop being enough and publishing a pcap file showing the issue is necessary, because debugging weird issues by screenshots is next to impossible. So please make the capture available at google drive, onedrive, dropbox... for everyone (no requirement for password at that particular service) or cloudshark, and then someone may look why Wireshark interprets the packets as retransmissions. (05 Feb '16, 00:58) sindy A the very least a screenshot with those options disabled might be helpful (or it might not). (05 Feb '16, 06:32) JeffMorriss ♦ Hi @sindy and @JeffMorriss you are right, here you can find a capture pcap: https://drive.google.com/file/d/0B7QZixdvKHVOVC16cmdlWkdheXc/view?usp=sharing (11 Feb '16, 01:16) Barzo Hm... first, the capture is a different one than that from which you've taken your screenshots (frames 16 and 22 are totally different), so the two sources of information cannot be put together. Second, as we do not have the private dissectors, we cannot see their behaviour on retransmissions and "overhead" (i.e. carrying no payload) packets. Third, I haven't found any packet analyzed literally as So can you please identify several pairs of frame numbers in the capture posted above, which the Wireshark version you currently use considers to be a "first transmission" and its related "retransmission", and then open that same capture using the Wireshark version you know to be working properly and check whether it handles these pairs of frames the same way (first transmission/retransmission) or as two first transmissions? At the moment I suspect that this is the root difference between the "old" and "new" behaviour, of which the rest is a consequence. (11 Feb '16, 03:16) sindy |
Have you checked the "Frame" section of the decode for the coloring rule information? You can see what rule matched and then check the rule itself (or the order, as rules are applied top-down, match first) - maybe you need to reorder your rules?
Hi @Jasper, thanks for the reply. Yes, I have checked the Frame section and, in fact, for XCMP packet (not right colored) I see: Coloring Rule Name: TCP. In my rules, XCMP and XNL are at the top of the list. Have I a way to "debug" the dissectors/rules?
Okay, that would indicate that the not correcly colored packets are not matched by the rules you created. Do the exact same expressions work correctly as display filters? Or are they not giving correct results either?
If they work -> open a bug at https://bugs.wireshark.org (check first if there is a bug for this already pls)
If they do not work -> try to modify your filter until it does
I updated my question with another screen. Tell me if I wrong...Since the filter simply say: "Color the XCMP pkt in Blue", here seems to be a dissector that does not match, right?
Looks to me like your dissector is not being called in the "Failing" screen shot.
Hi @Anders, I'm not the dissectors creator (they are created by a third party company), I only use them. Just for curiosity, do I have a way to verify this? What could be the cause? (I'm not an expert in dissector development). PS. I try to install an older version (1.9.1) and it seems to work: most of the packets are decoded (except some one).
Sorry I did not look closely enough. I think the reason is that it's tagged as a retransmission and dissection stops at the tcp layer.