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.
