Huge thanks to our Platinum Members Endace and LiveAction,
and our Silver Member Veeam, for supporting the Wireshark Foundation and project.

Ethereal-dev: Re: [Ethereal-dev] [PATCH] Ethertype 0x2452 in 802.11g capture ?

Note: This archive is from the project's previous web site, ethereal.com. This list is no longer active.

From: metatech <metatech@xxxxxxxxxxxxx>
Date: Sun, 18 Jul 2004 19:28:02 +0200

On Sun, Jul 11, 2004 at 10:32:42PM +0200, metatech wrote:
> I tried capturing from a Centrino laptop with the Intel 2200BG 802.11g
> chipset.
> I saw a lot of "Ethernet II" frames with 0x2452 as ethertype.

On what OS is this?  (I think Centrino support has recently appeared in
Linux, so it's not necessarily Windows.)

Is this some mechanism to supply 802.11 frames to a network layer
reluctant to accept raw 802.11 frames as opposed to Ethernet frames
(such as the Windows network layer)?  Or is this some
officially-registered Ethernet type for encapsulated 802.11 frames?

Guy,
I investigated a bit more these packets. This behaviour has been observed on Windows XP. In my opinion it is a "proprietary" behaviour of either the Centrino driver or the Centrino hardware. Currently I have no Linux distro installed on the machine to verify whether it is also the case.
These packets are seen only in a promiscuous capture :
- Packets normally received by the Centrino computer have the normal structure (no 802.11/LLC header but directly IP header). - Packets that are supposed to be received by another computer have the 802.11/LLC headers. I adapted the constant name for the ethertype to reflect this. Also I noticed that when WEP is enabled, the 802.11 header has the flag "WEP" set to true, but the packet is already decrypted. I added a test in the code to accomodate this. For TKIP it seems to stay encrypted.
Patch is against latest Subversion.
Please check in.

See you,

metatech

Attachment: centrino_promisc.zip
Description: Zip archive