Re: bwi(4): Broadcom AirForce BCM43xx IEEE 802.11b/g wifi driver

[Taylor R Campbell <campbell%mumble.net@localhost>]

I made a small mistake in the patches and kernels I previously pointed
to: I had bwi(4) tell the kernel that the hardware supports WEP and
WPA crypto (which it does, but which the driver can't handle at the
moment), and didn't tell it that the hardware supports hostap and ibss
modes.  This is fixed trivially by adjusting the bit mask of IEEE
802.11 capabilities in bwi_attach, and I've uploaded new patches and
kernels, the 4.0_STABLE version of which I've tested lightly in bss,
ibss, and hostap modes, with and without WEP keys (WPA testing to come
later).  I also removed some superfluous definitions for 4.0 from the
patch to -current.

The new patches and kernels are to be found in
<http://people.csail.mit.edu/riastradh/nbsd/>, with self-explanatory
file names.  Again, please let me know if you try these whether they
work or not, or what issues you have with them.  My testing of the
driver has been very cursory, and consists mainly of associating with
a couple of access points in bss mode with and without WEP or WPA
(using wpa_supplicant), and sending a few pings in ibss and hostap
mode.

I remembered one issue I had with compiling the driver, too, which may
be caused by my build environment, which is a MacBook running OS X:
In bwi_txeof_status, the DragonFlyBSD and OpenBSD drivers use le16toh
(or letoh16), whereas in order to make the driver work for me I had to
change it to be16toh.  Could it be that the byte order of the host is
accidentally leaking into the build environment for the driver?  I
haven't yet tried building the kernel on my PowerBook.