| Age | Commit message (Collapse) | Author |
|---|
|
The exact details are unknown (possibly hw errata?) but the Windows
and Linux drivers have never supported Jumbos on this chipset and since
it is so old and rare it is not that big of a deal.
From FreeBSD
ok dlg@ awhile ago.
|
|
PHY. This helps with systems dual booting Windows XP/Vista where the
Windows drivers will put the PHY in power down mode when rebooting.
From FreeBSD
|
|
edmonton, but I forgot.
ok and extra testing phessler@.
|
|
This was never noticed since it's always used with a larger size.
Noticed by Stephane Marchesin.
|
|
to the Attic. nothing uses it in the tree and it is very unlikely
that something will use it one day.
the only driver supporting FHSS PHYs in the tree is ray(4) and it
does not use net80211.
|
|
for now because it needs more testing, but basic WPA/WPA2 and WEP
seems to work. to enable it, set the compiled-in ath_softcrypto
variable to 1.
this is based on a previous diff from damien@ with some changes to
disable the hardware crypto engine if softcrypto is enabled and to
keeps the hardware crypto code in place to allow later work on
hardware WPA/WPA2.
|
|
|
|
"The driver lets you change to Host AP mode, but it does not work
and it probably never will."
so just remove the HOSTAP capability bit in the code and remove this
sentence.
|
|
apply; ok jsg@
|
|
add two capabilities flags: IEEE80211_C_HT for HT STAs (802.11n)
and IEEE80211_C_APPMGT which indicates the capability for an AP
to buffer unicast and multicast traffic for STAs in PS mode.
all drivers claiming HostAP support should support that but the
truth is that none of them do.
most of them are still at the 802.11b-only era and do not update
dynamic parts of beacons or process frames from ic_pwrsaveq.
|
|
ok thib
|
|
|
|
|
|
|
|
one function. Also fix reception of multicast packets when in promisuous
mode. The Realtek chips are a little different than most others in that
they will not receive multicast packets by enabling promiscuous mode
alone.
Tested by naddy@ and sthen@
ok naddy@
|
|
no binary changes.
|
|
fix a comment while i'm here.
pointed out by brad@
|
|
no binary changes.
|
|
some initial WMM bits too.
use license.template while i'm here.
|
|
require v4 firmware and the driver currently uses v3 firmware.
ok mglocker@
|
|
use license.template while i'm here.
|
|
Did a lot of cleanup while I was there.
|
|
|
|
ok canacar@
|
|
ok brad@
|
|
Suggestions and corrections by kettenis, ratchov, jakemsr. Thanks a lot!
Recording doesn't work at the moment.
ok kettenis ratchov
|
|
ok mglocker@
|
|
it ourselves.
From drm git.
|
|
From Robert Noland via drm git.
|
|
definitively gone for GEM so this will not be needed.
No binary change.
|
|
From FreeBSD
|
|
and unused.
|
|
should shrink the kernel somewhat. For some strange reason I was unaware
of this api when I pulled in these changes.
tested by myself and Paul de Weerd, thanks!
|
|
|
|
|
|
|
|
struct and pack all other hardware structs which have been forgotten.
|
|
that ieee80211.h contains only definitions that are part of the
802.11 standard and not constants used internally by net80211.
because channels attributes are exported to userland through the
radiotap BPF interface, add the definitions to ieee80211_radiotap.h
too (which must be kept in sync with what is used in net80211).
also, do not export combinations of channel attributes to userland
so that noone get stupid ideas.
|
|
|
|
|
|
|
|
use it in drivers that leave the 802.11 FCS in frames
passed to radiotap BPF. otherwise, userland has no way
to know if FCS is included or not as it depends on drivers.
this is required by some ports (aircrack).
requested by dhill@
|
|
IEEE80211_ACK_LEN instead of IEEE80211_MIN_LEN for ZYD_MIN_RXBUFSZ
and ZYD_MIN_FRAGSZ.
silence some warnings while i'm there.
change ZYD_FILTER_BSS to use the same value as the vendor's driver
that contains some magic (undocumented) bits.
|
|
since we pass received management frames to net80211, net80211
may send replies (like deauth/disassoc), so we just call
IF_PURGE(&ic->ic_mgtq) in {ipw,iwi}_start just to be on the
safe side of things (so we don't leak mbufs).
|
|
bwi_node structure (containing the rate control state).
because bwi(4) does not support HostAP or IBSS modes there is
no need to maintain a per-node rate control state, so we could
as well store it in bwi_softc but that will allow for future
improvements.
pointed out by Taylor R Campbell (campbell AT mumble DOT net)
on tech@
|
|
remove IBSS and HostAP support from net80211 and 802.11 drivers.
it can be used to shrink RAMDISK kernels for instance (like what
was done for wi(4)).
it also has the benefit of highlighting what is specific to IBSS
and HostAP modes in the code.
the cost is that we now have two code paths to maintain.
|
|
Malicious PPPoE discovery packets could cause the kernel to
crash.
From canacar@ and inspired by the original fix from NetBSD.
ok canacar@
|
|
|
|
|
|
|
