Re: Heuristic ethernet payloads

[Guy Harris <guy () alum mit edu>]

On Mar 27, 2013, at 5:15 AM, Evan Huus <eapache () gmail com> 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 <wireshark-dev () wireshark org>
Archives:    http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
             mailto:wireshark-dev-request () wireshark org?subject=unsubscribe