On Mar 27, 2013, at 5:15 AM, Evan Huus <[email protected]> wrote:
> The ethernet dissector currently has a heuristic table called "eth"
> that passes off the entire packet (including the ethernet header, if
> any) which is a bit confusing.
>
> As per bug #8522 we seem to have need of a heuristic table for the
> general ethernet payload (without the ethernet header bytes),
Heuristic dissector tables, by and large, should be used for protocols that
don't have a specified mechanism for indicating the protocol being transported
in a packet. Ethernet is not such a protocol, and if somebody's sending
Ethernet frames, with a destination MAC address, source MAC address, and
type/length field wherein either
the type/length field contains a value in the "type" range that's not a
registered Ethernet type
or
the type/length field contains a value in the "length" range that's not
actually the packet length
or
the type/length field contains a value in the "length" range that is
the packet length, but isn't following it with a valid 802.2 header (or with
something such as the Netware hack - 0xFF is a "group" service access point,
and that's not usable as an SSAP, so having 0xFF as both the DSAP and the SSAP
isn't valid, and a length-field frame beginning with 0xFFFF can be determined
not to be using an 802.2 header)
they are, as far as I know, not following the 802.3 spec.
If they're using an unregistered Ethernet type, or 802.2 headers and
unregistered DSAP/SSAP values, or 802.2+SNAP headers and either an unregistered
OUI or somebody else's OUI and their own PID value, they really shouldn't, but
we could add a preference for their protocol to let it register itself.
I've asked in the bug what he's doing - something such as that, or something
such as Cisco's "DOCSIS inside very low-level Ethernet framing" hack, for which
the best answer is assigning a LINKTYPE_/DLT_ value and adding a hack to
libpcap so that, when capturing on an "Ethernet" that's actually carrying
non-Ethernet traffic, you can set the capture's link-layer header type to match
what it really is, with a preference added to let purportedly-Ethernet frames
be interpreted as what they really are.
___________________________________________________________________________
Sent via: Wireshark-dev mailing list <[email protected]>
Archives: http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
mailto:[email protected]?subject=unsubscribe
