["Michael A. McCartney" <mccart@xxxxxxxxxxxxxxxxxx>]

Chris,

I used to hack into packet-eth.c until I learned
a better way using heuristic dissector instead
and leave packet-eth.c alone.  Not sure why you
had difficulties but this is what I did and it
works fine.  And using the if(...), one can be
selective on MAC address.

static gboolean
dissect_<name>_heur (tvbuff_t *tvb, packet_info *pinfo, proto_tree *tree)
{
    /*
     * Is a <name or target> ethernet header?
     */
    if( tvb_get_guint8(tvb, 1) == 0x00 &&
        tvb_get_guint8(tvb, 2) == 0x00 &&
        tvb_get_guint8(tvb, 3) == 0x00 &&
          ... etc ...
        tvb_get_guint8(tvb,11) == 0x00 &&
        tvb_get_guint8(tvb,12) == 0x00 )
    {
        /* dissect <name> frame */
        dissect_<name>(tvb, pinfo, tree);
        return TRUE;
    }
    else
    {
        /* not a <name> ethernet packet header */
        return FALSE;
    }
}

And in proto_reg_handoff_<name>
had this line...

  heur_dissector_add("eth", dissect_<name>_heur, proto_<name>);

Of course, doing this way, you need to dissect the
whole ethernet frame yourself including the MACs.

Thanks-Mike


Maynard, Chris wrote:
> At first glance, packet-eth.c seems to have heuristic support, but it doesn't appear to work, at least not how I expected it to.  For example, originally for the WOL dissector, I registered as I do for UDP, namely:
>     heur_dissector_add("eth", dissect_wol, proto_wol);
>  
> But registering it that way didn't work for me, so it's been changed to:
>     dissector_add("ethertype", ETHERTYPE_WOL, wol_handle);
>  
> I didn't dig too deeply into why it failed since I had a reasonable alternative, but I suppose I should have.  It now seems to me to be a bug in packet-eth.c, but I'm not entirely sure, based on the comments in the code.
>  
> First, compare the way a dissector like packet-udp.c tries the heuristic dissectors, using the "next_tvb":
>     next_tvb = tvb_new_subset(tvb, offset, len, reported_len);
>     if (dissector_try_heuristic(heur_subdissector_list, next_tvb, pinfo, tree))
>
> Now look at how packet-eth.c does it:
>     if (dissector_try_heuristic(heur_subdissector_list, tvb, pinfo, parent_tree))
>         goto end_of_eth;
>
> Notice that there's no "next_tvb".  I assumed that this was intentional when I looked at it before, but now I'm not so sure.  A bug?  It now sure looks like it to me.  I couldn't find any other dissectors that try to heuristically register to "eth" as I tried above.  Perhaps because it doesn't work?  If it is a bug, then once that's corrected, then that would be the better way to register both WOL and the original poster's dissector - heuristically.
>  
> - Chris
>
> ________________________________
>
> From: wireshark-dev-bounces@xxxxxxxxxxxxx on behalf of Stephen Fisher
> Sent: Mon 11/12/2007 12:50 PM
> To: Developer support list for Wireshark
> Subject: Re: [Wireshark-dev] Register dissector to MAC address
>
>
>
> On Mon, Nov 12, 2007 at 12:37:10PM -0500, Maynard, Chris wrote:
>
>   
>> Can anyone think of a reason NOT to add heuristic dissection support
>> to packet-eth.c?  Or does anyone have a better/alternate way to solve
>> this?
>>     
>
> My first thought is that the original poster's dissector could be a
> heuristic that checks against the MAC address when deciding whether to
> acccept the packet or not.  Does this need changes to packet-eth.c?  I'm
> not sure, but could find out by researching the code a bit.
>
>
> Steve
>
> _______________________________________________
> Wireshark-dev mailing list
> Wireshark-dev@xxxxxxxxxxxxx
> http://www.wireshark.org/mailman/listinfo/wireshark-dev
>
>
>
>
>
> -----------------------------------------
> This email may contain confidential and privileged material for the
> sole use of the intended recipient(s). Any review, use, retention,
> distribution or disclosure by others is strictly prohibited. If you
> are not the intended recipient (or authorized to receive for the
> recipient), please contact the sender by reply email and delete all
> copies of this message. Also, email is susceptible to data
> corruption, interception, tampering, unauthorized amendment and
> viruses. We only send and receive emails on the basis that we are
> not liable for any such corruption, interception, tampering,
> amendment or viruses or any consequence thereof.
> ------------------------------------------------------------------------
>
> _______________________________________________
> Wireshark-dev mailing list
> Wireshark-dev@xxxxxxxxxxxxx
> http://www.wireshark.org/mailman/listinfo/wireshark-dev
>