I search on Google about this failure. Mostly of them suggested to check whether there were variables that were used without going into the hf array.
But I checked carefully both with checkhf.pl and manually, no variable were used in such way.
Another thing is that my dissector was originally built as a plugin DLL with 0.99.5 wireshark. Now we are using wireshark 1.2.x(for the one I use now is 1.2.11), but in 1.2.x, there was a built-in wireshark dissector for my protocol(FMP) package. The way I tried to solve this problem was I copied the entire plugin source code and modified to build with 1.2.x. The dissector(dll) work with 1.2.x because I changed the protocol register name. I saw my dll recognized most of the packet except two packets, which displyed the error: dissector bug: proto.c:656: failed assertion "(guint)hfindex < gpa_hfinfo.len".
Any body has any suggestion to what happened or where the problem might be? I can't paste code at this moment because of a lot of reason.
Thanks in advance for your input.
asked 01 Nov '10, 23:27
Load the offending capture, try to work out which of the fields cause the error, then go back to your code to verify that that field has indeed been allocated. Use your debugger to make sure.
answered 02 Nov '10, 00:00
I think you know this is a classical error when some hf proto fields are missing in the hf array since you ran the checkhf.pl script.
I got exactly the same error on my custom dissector when upgrading from version 1.2.x to 1.4.x and it took me days to find out out what was wrong...
Indeed the error happened in my dissector during UDP reassembling, more precisely when I was running the process_reassembled_data function.
The cause was that in the fragment_items structure, the hf_xxx_reassembled_length field was missing. It was working fine until version 1.2.x but did not work after version 1.4.x
I think checkhf.pl script did not catch it because the reassembling hf variables are initialised in another sources files (proto.c).
Tell me if it helps !