Brian,
What part of the document is confusing? Did you look at the code examples in the file? It shows you the 2 main functions that you need to change - the main dissector declaration with heuristics plus the handoff function. Besides the README, keep in mind that you also have plenty of other Wireshark dissectors that can serve as excellent heuristic examples. Search for "heur_dissector_add" in epan/dissectors/packet-*.c and you will find them.
If you do change to a heuristic dissector, you should make the heuristics as strong as possible. Checking only that the 1st byte is 0xbe is pretty weak. You should verify as much information as possible before accepting it - things like the port, the entire magic #, the length of the packet as having the minimum # of bytes to possibly be a Helen packet (i.e. 18 for header only or 20 if you require at least a tail extension), etc.
BTW, changing to a heuristic dissector (or not) will not fix the inherent problems with your dissector. Your dissector is not crashing because the 1st byte is not 0xbe. The crash is occurring for some other reason that you should track down and fix regardless of whether you change your dissector into a heuristic one or not.
- Chris
-----Original Message-----
From: wireshark-dev-bounces@xxxxxxxxxxxxx [mailto:wireshark-dev-bounces@xxxxxxxxxxxxx] On Behalf Of Brian Oleksa
Sent: Thursday, March 25, 2010 12:19 PM
To: Developer support list for Wireshark
Subject: Re: [Wireshark-dev] Packet Size limited during capture message
Chris
Thanks for the response.
I looked at the README.heuristic documentation and I am a little
confused on what I would have to change if I went this route.
It would be nice to just do this: As all Helen packets start with 0xbead
if ( tvb_get_guint8(tvb, 0) != 0xbe )
return (FALSE);
else
/* Assume it's your packet and do dissection */
...
return (TRUE);
But since this is the first packet I am not sure where to start at.
Thanks,
Brian
Maynard, Chris wrote:
> If the magic # doesn't match, presumably because there's other traffic destined for your port which is not Helen traffic, and you want to abandon processing of the packet, then you have a couple of choices. You can either change your dissector to a new-style dissector that returns the number of bytes processed (zero in the case of a packet you determine is NOT a Helen packet), or change your dissector to a heuristic one. Read more about these in doc/README.developer and doc/README.heuristic.
>
> BTW, what do you do if the Helen extension code is not 0, 1, 2, or 3? That's one possible reason for the source of your crash in this case. I made some suggestions in a prior thread on how you might improve your dissector in this regard, but it doesn't look like you many any of those changes. I don't know if it would have prevented the crash or not in this case, but it would have at least allowed you to correctly display any new codes that your dissector had not yet supported. Maybe you want to take a look at that too.
>
> - Chris
>
>
> -----Original Message-----
> From: wireshark-dev-bounces@xxxxxxxxxxxxx [mailto:wireshark-dev-bounces@xxxxxxxxxxxxx] On Behalf Of Brian Oleksa
> Sent: Wednesday, March 24, 2010 10:00 AM
> To: Developer support list for Wireshark
> Subject: Re: [Wireshark-dev] Packet Size limited during capture message
>
> Guy / Bill / Chris / Jakub / Mike
>
> So I did some more troubleshooting only to find the following:
> The dissector crashes in WinXP but not on my Fedora Core 9 box. This is weird.
>
> Using editcap... I was able to find the frame on windows to which wireshark crashed on (which was frame 17641).
> I opened the same .pcap file on my FC-9 box (it did not crash)...but I went to frame 17641 only to find out that it is a Malformed Packet.
>
> How I determine if it is a Helen packet or not....is that all helen packets start with 0xbead which is the "magic number". I have never had this problem before as I found thousands of Helen packets this way. But this malformed packet has a magic number of 0x293e .... which then through the rest of the packet info off and crashed wireshark (on Windows).
>
> Any thoughts..??
>
> Do I need to make sure that the hf_helen_magic is equal to 0xBEAD.....and if not I discard this packet..??
>
> Why did it find this packet and assume that it was a Helen Packet..??
> Was it because 0x293e is equal to 0xBEAD in length so it just assumed it was a helen packet..??
>
> Attached is the code.
>
> Thanks for your help,
> Brian
>
> CONFIDENTIALITY NOTICE: The contents of this email are confidential
> and for the exclusive use of the intended recipient. If you receive this
> email in error, please delete it from your system immediately and
> notify us either by email, telephone or fax. You should not copy,
> forward, or otherwise disclose the content of the email.
>
> ___________________________________________________________________________
> Sent via: Wireshark-dev mailing list <wireshark-dev@xxxxxxxxxxxxx>
> Archives: http://www.wireshark.org/lists/wireshark-dev
> Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
> mailto:wireshark-dev-request@xxxxxxxxxxxxx?subject=unsubscribe
>
___________________________________________________________________________
Sent via: Wireshark-dev mailing list <wireshark-dev@xxxxxxxxxxxxx>
Archives: http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
mailto:wireshark-dev-request@xxxxxxxxxxxxx?subject=unsubscribe
CONFIDENTIALITY NOTICE: The contents of this email are confidential
and for the exclusive use of the intended recipient. If you receive this
email in error, please delete it from your system immediately and
notify us either by email, telephone or fax. You should not copy,
forward, or otherwise disclose the content of the email.
