Wireshark-dev: Re: [Wireshark-dev] [PATCH] Decode Bluetooth HS 4-way handshake over 802.11 medi
From: Guy Harris <guy@xxxxxxxxxxxx>
Date: Tue, 14 Aug 2012 12:25:58 -0700
On Aug 14, 2012, at 12:49 AM, Andrei Emeltchenko wrote:

> Hi Joerg,
> 
> On Mon, Aug 06, 2012 at 05:37:35PM +0200, Joerg Mayer wrote:
>> Hello,
>> 
>> can you please open a bug at bugs.wireshark.org and attach the patch there?
> 
> https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=7633
> 
>> Does your patch distinguish between an 802.3/LLC/SNAP encapsulated frame
>> of length 3 and Ethertype 3?
> 
> Sorry did not get what you mean here.

As per my comment in the bug:

0x0003 is not an Ethernet type, so the EAPOL dissector should *NOT* be registered in the "ethertype" table with a value of 0x0003.

(Nothing less than 0x0600 can be a valid Ethernet type; see section 3.2.6 "Length/Type field" of IEEE Std 802.3-2008, for example.  Values in the type/length field of an Ethernet packet that are less than or equal to 0x05DC - 1500 - are *length* values, not *type* values, so if an Ethernet packet had a value of 0x0003, it'd be a length value, hence the packet would be an 802.3/LLC-encapsulated frame with a length of 3.)

Instead, it's a protocol ID in the space of SNAP protocol IDs for the OUI value 00:19:58, i.e. OUI_BLUETOOTH, so what you want to do is to:

	register a dissector table for the OUI value OUI_BLUETOOTH - for an example of how to do this, see proto_register_cisco_oui() in epan/dissectors/packet-cisco-oui.c;

	in that dissector table, register the EAPOL dissector in *THAT* dissector table with a protocol ID of 0x0003.