Date: Tue, 1 Jun 2004 18:47:00 -0700 (PDT) From: wpaul@FreeBSD.ORG (Bill Paul) To: alex.wilkinson@dsto.defence.gov.au (Wilkinson Alex) Cc: freebsd-current@freebsd.org Subject: Re: Project Evil APs Message-ID: <20040602014700.D3A3216A4CF@hub.freebsd.org> In-Reply-To: <20040602003318.GB13789@squirm.dsto.defence.gov.au> from "Wilkinson, Alex" at "Jun 2, 2004 10:03:18 am"
next in thread | previous in thread | raw e-mail | index | archive | help
> On Sat, May 29, 2004 at 10:37:03PM -0700, Bill Paul wrote:
>
> ...
>
> " But all Windows 802.11 drivers all pretend to be 802.3 link layer drivers,
> because Windows doesn't have any 802.11 protocol support. "
> ...
>
> Could you please elaborate on this comment a bit more ?
>
> - aW
>
It's pretty self-explanatory. All existing 802.11a/b/g wireless drivers
for Windows pretend to be ethernet drivers. When a protocol driver sends
a frame to a wireless NDIS driver, it sends it in the form of an ethernet
frame. Likewise, when a protocol driver receives a frame from a wireless
NDIS driver, it's also in the form of an ethernet frame. Up until the
NDIS 5.1 spec, the only way to set any of the wireless parameters such
as SSID, BSS/IBSS mode, WEP keys, and so forth, was via vendor-specified
registry keys or vendor-specific OIDs (which often required vendor-supplied
utilities to configure). Now that wireless has taken off, Microsoft has
added some extensions to NDIS (in the form of additional OIDs) to configure
these parameters in a more generic fashion, mainly to make Windows Zero
Configuration work with wireless devices. Most drivers that I've seen
have a combination of standard 802.11 OIDs (see /sys/compat/ndis/ndis_var.h
for a list -- grep for OID_802_11) to make WZC happy, vendor-specific OIDs
to provide knobs for special features that Windows just doesn't handle
(enabling/disabling turbo modes, handling LEAP authentication) and
custom registry keys that can be set by navigating your way through
the System control panel. A lot of the custom stuff is necessary because
the vendors keep jumping ahead of the standards: by the time Microsoft
updates NDIS to support a new set of standards, the updates are already
obsolete. (Plus, sometimes Microsoft does stupid things: although many
cards are capable of supporting much more than the 8 rates specified in
the original 802.11 spec, the OID_802_11_SUPPORTED_RATES OID is still
specified to only return an array of 8 values.)
If you want to do special things like sniff raw wireless frames (including
beacon frames and control frames) or pretend to be an AP, then you need
the ability to send and receive 802.11 frames -- but these frames will
have 802.11 headers on them, which none of the existing protocol drivers
in Windows know how to process. When you ask a wireless NDIS driver
what media it supports, it will tell you "NdisMedium802_3." Some vendor
drivers may have custom mechanisms for handling raw 802.11 frames, but
there's no standardization between vendors, and any behind-the-scenes
tricks they use are probably considered proprietary (which means you'll
never get any of them to talk about it).
Is this dumb? Yes. But consumers don't know the difference: as long
as they can wirelessly download their porn, they're happy. And the
vendors are happy. And Microsoft is happy. Microsoft is supposed to
be working on 802.11 protocol support for Windows, but I suspect it's
going to be purely a Longhorn thing, unless they plan on another major
service pack for XP.
-Bill
--
=============================================================================
-Bill Paul (510) 749-2329 | Senior Engineer, Master of Unix-Fu
wpaul@windriver.com | Wind River Systems
=============================================================================
<adamw> you're just BEGGING to face the moose
=============================================================================
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20040602014700.D3A3216A4CF>