ANNOUNCEMENT: Live Wireshark University & Allegro Packets online APAC Wireshark Training Session
April 17th, 2024 | 14:30-16:00 SGT (UTC+8) | Online

Wireshark-dev: Re: [Wireshark-dev] Heuristic ethernet payloads

From: Guy Harris <guy@xxxxxxxxxxxx>
Date: Wed, 27 Mar 2013 13:26:28 -0700
On Mar 27, 2013, at 5:15 AM, Evan Huus <eapache@xxxxxxxxx> 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.