My suggestion is to do nothing about it right now. The question of how
the Ethernet dissector hands off dissection to the heuristically
registered sub-dissectors has been asked and answered.
As for WOL dissection, although it's true that a MagicPacket could occur
any Ethertype or in any other sub-dissector, I highly doubt that anyone
in their right mind would implement it such that it would conflict with
an existing Ethertype anyway. My feeling too is that WOL will only make
up a tiny fraction of anyone's packets anyway (probably in most cases
0%), so I don't think it's worth spending any extra effort on it at this
point. If things change, we can always revisit these ideas later on.
-----Original Message-----
From: wireshark-dev-bounces@xxxxxxxxxxxxx
[mailto:wireshark-dev-bounces@xxxxxxxxxxxxx] On Behalf Of Guy Harris
Sent: Tuesday, December 18, 2007 5:39 AM
To: Developer support list for Wireshark
Subject: Re: [Wireshark-dev] Register dissector to MAC address
Maynard, Chris wrote:
> 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).
However, if the MagicPacket value appears within, for example, a packet
with an Ethertype of 0x0800, that packet had better be a valid IPv4
packet, or the recipient is likely to get *really* upset.
I.e., such a packet isn't going to be a magic packet, in the sense of a
packet that should be parsed as a magic packet rather than an IPv4
packet.
So the heuristics should, in that case, be done *after* the Ethertype is
checked, and only packets that don't match any of the known Ethertypes
should be checked against the heuristics.
Unfortunately, that might cause problems for the "no Ethertype assigned,
but these are only sent to a particular MAC address" packets, if they
happen to be given a standard Ethertype. We might want to add a new
dissector table type, with the key being a MAC address rather than an
unsigned integer or a string, and use that.
-----------------------------------------
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.
