["Maynard, Chris" <Christopher.Maynard@xxxxxxxxx>]

Mike,

First, thanks for the response.  Like I said below though, I don't think
any of the other dissectors work that way.  UDP, for example, makes a
call to tvb_new_subset() to pass the payload of the UDP packet to the
registered heuristic dissectors, so those dissectors only get the
payload without the UDP header.  I would have expected the same for
Ethernet heuristic dissection as well, but instead, the entire packet -
Ethernet header and all - is passed to the registered heuristic
dissectors.

For WOL at least, the actual Ethernet MAC is unimportant as far as
determining if it's a WOL packet or not.  Instead, only the MagicPacket
matters, which theoretically could occur anywhere within the payload.
However, if the MagicPacket is found and the heuristic dissector
determines it's a WOL packet, then unfortunately I don't think the
protocols will be stacked properly.  For example, what we'd like to see
is this:

Frame <n> 
Ethernet II
Wake On LAN

.... but unfortunately what we'll see is this instead:
Frame <n>
Wake On LAN

That's why I abandoned the heuristic registration and simply registered
for Ethertype 0x0842 instead.  Of course the downside to that is 0x0842
is not really THE Ethertype for WOL packets.  As far as I can tell,
0x0842 is simply the Ethertype chosen by the author of ether-wake.  But
who's to say that someone else won't implement the MagicPacket using a
different Ethertype one day.  If that happens, WOL packets won't be
dissected as such.

Then there's the downside of changing the existing behavior - meaning
pretty much every packet will have to be scanned to determine if it
contains the MagicPacket or not since theoretically, the MagicPacket can
occur within ANY packet (i.e., ANY Ethertype).  I suspect that by
scanning every packet, things could slow down quite a bit.  So, after
all is said and done, perhaps the WOL dissector is best left the way it
is?  But that doesn't mean that the Ethernet dissector's heuristic
registration shouldn't be fixed nonetheless ... if indeed it's improper
behavior.  I think it is but I have left the question open for the
author of that dissector or the core Wireshark developers to answer.

- Chris

-----Original Message-----
From: wireshark-dev-bounces@xxxxxxxxxxxxx
[mailto:wireshark-dev-bounces@xxxxxxxxxxxxx] On Behalf Of Michael A.
McCartney
Sent: Monday, December 17, 2007 9:14 PM
To: Developer support list for Wireshark
Subject: Re: [Wireshark-dev] Register dissector to MAC address

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

[snip]

-----------------------------------------
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.