Commit Graph

44 Commits

Author SHA1 Message Date
Andriy Voskoboinyk
1447d404e0 iwn: add watchdog for scanning.
Restart device if scanning was not done in time.

Tested by:	david@catwhisker.org

PR:		209198
Differential Revision:	https://reviews.freebsd.org/D6176
2016-05-26 11:12:36 +00:00
Andriy Voskoboinyk
a7d1e7a9ec iwn: fix device reset after watchdog timeout.
Simple device reset (stop/start) is not enough here;
post-init state changes must be applied too.
2016-05-04 12:51:27 +00:00
Gleb Smirnoff
b0f99291de Remove the software queue, which is a remnant of ifnet ifqueue.
Reviewed by:	adrian
Sponsored by:	Netflix
Sponsored by:	Nginx, Inc.
2015-09-02 15:23:51 +00:00
Adrian Chadd
4823a7500b Migrate the stats API for iwn(4) into a cdev ioctl, rather than tying
into the vap.

This allows for possible hardware interaction without needing a vap
configured.
2015-08-30 21:54:33 +00:00
Gleb Smirnoff
7a79cebfba Replay r286410. Change KPI of how device drivers that provide wireless
connectivity interact with the net80211 stack.

Historical background: originally wireless devices created an interface,
just like Ethernet devices do. Name of an interface matched the name of
the driver that created. Later, wlan(4) layer was introduced, and the
wlanX interfaces become the actual interface, leaving original ones as
"a parent interface" of wlanX. Kernelwise, the KPI between net80211 layer
and a driver became a mix of methods that pass a pointer to struct ifnet
as identifier and methods that pass pointer to struct ieee80211com. From
user point of view, the parent interface just hangs on in the ifconfig
list, and user can't do anything useful with it.

Now, the struct ifnet goes away. The struct ieee80211com is the only
KPI between a device driver and net80211. Details:

- The struct ieee80211com is embedded into drivers softc.
- Packets are sent via new ic_transmit method, which is very much like
  the previous if_transmit.
- Bringing parent up/down is done via new ic_parent method, which notifies
  driver about any changes: number of wlan(4) interfaces, number of them
  in promisc or allmulti state.
- Device specific ioctls (if any) are received on new ic_ioctl method.
- Packets/errors accounting are done by the stack. In certain cases, when
  driver experiences errors and can not attribute them to any specific
  interface, driver updates ic_oerrors or ic_ierrors counters.

Details on interface configuration with new world order:
- A sequence of commands needed to bring up wireless DOESN"T change.
- /etc/rc.conf parameters DON'T change.
- List of devices that can be used to create wlan(4) interfaces is
  now provided by net.wlan.devices sysctl.

Most drivers in this change were converted by me, except of wpi(4),
that was done by Andriy Voskoboinyk. Big thanks to Kevin Lo for testing
changes to at least 8 drivers. Thanks to pluknet@, Oliver Hartmann,
Olivier Cochard, gjb@, mmoll@, op@ and lev@, who also participated in
testing.

Reviewed by:	adrian
Sponsored by:	Netflix
Sponsored by:	Nginx, Inc.
2015-08-27 08:56:39 +00:00
Adrian Chadd
ba2c1fbc03 Revert the wifi ifnet changes until things are more baked and tested.
* 286410
* 286413
* 286416

The initial commit broke a variety of debug and features that aren't
in the GENERIC kernels but are enabled in other platforms.
2015-08-08 01:10:17 +00:00
Gleb Smirnoff
79d2c5e857 Change KPI of how device drivers that provide wireless connectivity interact
with the net80211 stack.

Historical background: originally wireless devices created an interface,
just like Ethernet devices do. Name of an interface matched the name of
the driver that created. Later, wlan(4) layer was introduced, and the
wlanX interfaces become the actual interface, leaving original ones as
"a parent interface" of wlanX. Kernelwise, the KPI between net80211 layer
and a driver became a mix of methods that pass a pointer to struct ifnet
as identifier and methods that pass pointer to struct ieee80211com. From
user point of view, the parent interface just hangs on in the ifconfig
list, and user can't do anything useful with it.

Now, the struct ifnet goes away. The struct ieee80211com is the only
KPI between a device driver and net80211. Details:

- The struct ieee80211com is embedded into drivers softc.
- Packets are sent via new ic_transmit method, which is very much like
  the previous if_transmit.
- Bringing parent up/down is done via new ic_parent method, which notifies
  driver about any changes: number of wlan(4) interfaces, number of them
  in promisc or allmulti state.
- Device specific ioctls (if any) are received on new ic_ioctl method.
- Packets/errors accounting are done by the stack. In certain cases, when
  driver experiences errors and can not attribute them to any specific
  interface, driver updates ic_oerrors or ic_ierrors counters.

Details on interface configuration with new world order:
- A sequence of commands needed to bring up wireless DOESN"T change.
- /etc/rc.conf parameters DON'T change.
- List of devices that can be used to create wlan(4) interfaces is
  now provided by net.wlan.devices sysctl.

Most drivers in this change were converted by me, except of wpi(4),
that was done by Andriy Voskoboinyk. Big thanks to Kevin Lo for testing
changes to at least 8 drivers. Thanks to Olivier Cochard, gjb@, mmoll@,
op@ and lev@, who also participated in testing. Details here:

https://wiki.freebsd.org/projects/ifnet/net80211

Still, drivers: ndis, wtap, mwl, ipw, bwn, wi, upgt, uath were not
tested. Changes to mwl, ipw, bwn, wi, upgt are trivial and chances
of problems are low. The wtap wasn't compilable even before this change.
But the ndis driver is complex, and it is likely to be broken with this
commit. Help with testing and debugging it is appreciated.

Differential Revision:	D2655, D2740
Sponsored by:	Nginx, Inc.
Sponsored by:	Netflix
2015-08-07 11:43:14 +00:00
Adrian Chadd
3233d0c654 First cut at attempting to buffer frames until we see a beacon.
The iwn(4) firmware forgets most of its channel state after an RXON
command.  This means that any beacons its seen on passive 5GHz channels
are forgotten upon an association/authorisation request.
This unfortuantely means that 5GHz association almost always fails -
the assoc and/or auth frames are dropped with a status of "passive
channel, haven't seen a beacon yet." (0x90.)

So:

* add an xmit queue, global, to buffer frames
* modify the xmit path to use the mbuf tag from net80211
  to specify raw frame details
* buffer xmit frames from both raw and non-raw paths
* if a beacon is seen in the RX path, schedule a taskqueue to
  send said frames and un-buffer things.
* flush frames during state change back to INIT, or NIC
  down/up/detach.

This isn't the final shape I'd like this to be in but it certainly
is better than 5GHz "not working at all".

Tested:

* Intel 5100, STA mode (before spilling coffee)
* Intel 5300, STA mode (after spilling coffee)

Story:

* This has been bugging me at work for months, which I just
  worked around by throwing an ath(4) into my Lenovo T400 cardbus
  slot.

* Our ops director discovered indeed FreeBSD runs well on the
  Lenovo T420p, except for that pesky 5GHz thing.  So now developers
  also can have a T420p running FreeBSD to do work with.
  Their #1 feedback to me - "boy it'd be nice if 5GHz wifi worked."

* .. then, I was at NANOG but stuck with 5GHz only wifi and no ath(4)
  NIC to put in a laptop - and I snapped.

Thus, the reason this is actually work related.

MFC after:	2 weeks
Sponsored by:	Norse Corp, Inc.
2015-06-19 01:44:17 +00:00
Adrian Chadd
bc0203e201 Fix antenna configuration, microcode version checks and rate selection
in preparation for the 5300 3x3 NIC.

During this particular adventure, I did indeed discover that a whole
swath of things made little to no sense.

Those included, and are fixed here:

* A lot of the antenna configuration bits assume the NIC has two receive
  chains.  That's blatantly untrue for NICs that don't.
* There was some disconnect between the antenna configuration when
  forming a PLCP rate DWORD (which includes the transmit antenna
  configuration), separate to the link quality antenna configuration.

  So now there's helper functions to return which antenna configurations
  to use and those are used wherever an antenna config is required.

* The 5300 does up to three stream TX/RX (so MCS0->23), however
  the link quality table has only 16 slots.  This means all of the
  rate entries are .. well, dual-stream rates.  If this is the case,
  the "last MIMO" parameter can't be 16 or it panics the firmware.
  Set it to 15.

* .. and since yes it has 16 slots, it only would try retransmitting
  from MCS8->MCS23, which can be quite .. terrible.  Hard-code the last
  two retry slots to be the lowest configured rate.

* I noticed some transmit configuration command stuff is different
  based on firmware API version, so I lifted that code from Linux.

* Add / augment some more logging to make it easier to capture this
  stuff.

Now, 3x3 is still terrible because the link quality configuration is
plainly not good enough.  I'll have to think about that.
However, the original goal of this - 3x3 operation on the Intel
5300 NIC - actually worked.

There are also rate control bugs in the way this driver handles
notifying the net80211 rate control code when AMPDU is enabled.
It always steps the rate up to the maximum rate possible - and
this eventually ends in much sadness.  I'll fix that later.

As a side note - 2GHz HT40 now works on all the NICs I have tested.

As a second side note - this exposed some bad 3x3 behaviour in
the ath(4) rate control code where it starts off at a 3-stream rate
and doesn't downgrade quickly enough.  This makes the initial
dhcp exchange take a long time.  I'll fix the ath(4) rate code
to start at a low fixed 1x1 MCS rate and step up if everything
works out.

Tested:

* Intel 2200
* Intel 2230
* Intel 5300
* Intel 5100
* Intel 6205
* Intel 100

TODO:

* Test the other NICs more thoroughly!

Thank you to Michael Kosarev <russiane39@gmail.com> for donating the
Intel 5300 NIC and pestering me about it since last year to try and
make it all work.
2014-08-28 03:18:27 +00:00
Edward Tomasz Napierala
8acd0be199 Make iwn(4) able to get itself back into working condition after
"fatal firmware error" happens.  Previously it was neccessary to reset
it manually, using "/etc/rc.d/netif restart".

Approved by:	adrian@
MFC after:	1 month
Sponsored by:	The FreeBSD Foundation
2014-05-22 15:29:25 +00:00
Adrian Chadd
49f79cfd5f Track and expose the latest statistics from the firmware.
Tested:

* Intel Centrino 6205
2014-02-24 02:37:04 +00:00
Marius Strobl
7b23a8b2c0 - There's no need to keep track of resource IDs.
- Simplify MSI allocation and release. For a single one, we don't need to
  fiddle with the MSI count and pci_release_msi(9) is smart enough to just
  do nothing in case of INTx.
- Don't allocate MSI as RF_SHAREABLE.
- Use DEVMETHOD_END.
- Use NULL instead of 0 for pointers.

MFC after:	1 week
2013-12-29 19:32:27 +00:00
Adrian Chadd
92d7ab9562 Begin fleshing out some code to handle tracking PLCP error rates
in preparation for the scan based retune logic.

The linux iwlwifi driver does a rescan (onto a non-active channel)
to force an RF retune when the PLCP error rates exceed a certain threshold.

* Add code to track HT PLCP rate errors;
* Separate out the PLCP error count fetch and update so the delta
  can be used when checking for PLCP error rates;
* Implement the PLCP error logic from iwlwifi;
* For now, just print out whenever the error rate exceeds the
  threshold.

The actual scan based retune will take a bit more effort; the scan
command code right now assumes that a scan state is passed in.
This does need to change to be more flexible (both for this and
in preparation for scanning multiple channels at once.)

Tested:

* 5100 (STA mode)
* 2200 (STA mode)
* 2230 (STA mode)
2013-12-07 08:03:10 +00:00
Adrian Chadd
fee842aa2a Overhaul the iwn(4) scan infrastructure to be slightly more "correct"
for these chipsets.

* Correctly set the active/passive flag in the scan request - this is
  NOT a "is the channel active|passive"; it's to do with whether we
  have an SSID to actively scan for or not.  The firmware takes care
  of the active/passive setup of the channel.

* Calculate the active/passive dwell time based on the beacon interval
  and the channel mode, rather than using a hard coded value.

* For now, hardcode the scan service_time.  It's defined as:

  31:22 - number of beacon intervals to come back onto the home channel
          for;
  0:21  - time (microseconds) to come back onto the home channel for.

  When doing an active scan when the NIC is active (whether we're associated
  or not - it only matters if we've setup the NIC to a destination or not)
  this determines how much time to stay on the home channel for when
  scanning.  We can tune this based on the amount of active traffic.

  For now it's 4 beacon intervals and 100 microseconds.

* Fix the "good crc threshold" setting.  It differs based on the NIC
  firmware.  Some older firmware required a workaround; the later
  firmware instead treats the field as a flag.

* Enforce that we are not sending a scan command if one is already
  pending.  Any time this is done is a bug and it absolutely needs
  to be fixed - so be very loud.

* Add the SCAN flag to a few debug messages that are scan related but
  only occuring under STATE.

Now, this does get noisy when you're scanning in an actively busy 2GHz
network as the firmware (for reason I don't quite yet understand) seems
hell bent on staying on some passive channels longer than it should.
However, it should eventually recover and complete the scan.

This is a work in progress; please let me know if things get stuck or
if things improve!

Tested:

* intel centrino 2200
* intel centrino 2230
* intel 6200
* intel 5100
* intel 4965 (gets upset, but that's a known issue)

Obtained from:	linux iwlwifi
2013-12-02 03:59:45 +00:00
Adrian Chadd
a704cc7f5f Commit over some work to prepare the iwn(4) driver for further chipset
support.

* Extend the hardware base_params structure to include a bunch of hardware
  flags indicating what is and isn't supported.

* Convert a bunch of the initial hardware configuration conditionals to
  consult the base_params structure.

* Add new calibration code for temperature calibration for the Centrino 2xxx
  series NICs.

* Add new bluetooth coexistence code for Centrino 2xxx series NICs.

* For NICs that support PAN (personal area networking), use a different
  transmit queue and command queue setup, in preparation for said
  PAN support.

* Extend the calibration array in iwn_softc to include enough space for
  the new calibration types.

Tested (by myself, if not mentioned):

* Intel 4965
* Intel 5100
* Intel 6150
* Intel 2230
* Intel 2200 (eadler)
* Intel 1030
* Intel 6200
* Intel 6230
* Intel 6250
* Intel 6150
* Intel 100

What doesn't work:

* Intel 6235 - fails in calibration at startup

TODO:

* Testing on Intel 53xx series hardware

Submitted by:	Cedric Gross <cg@cgross.info>
2013-11-12 05:58:23 +00:00
Adrian Chadd
8cf53c1244 Begin fleshing out a knob to enable/disable bluetooth coexistence.
Some firmware versions seem to get very unhappy if they're sent btcoex
commands when they don't actually have bluetooth hardware in them.
So, disable sending them those commands.

Tested:

* 5100 (which has bluetooth, no problems)
* 4965 (which doesn't have bluetooth, but didn't seem to crash)
* 6200 (no bluetooth, seems to get unhappy being sent bluetooth commands.)
2013-10-25 19:46:52 +00:00
Adrian Chadd
da8848ffb4 Prepare for the PAN (personal area network) support for iwn(4).
* Break out the single, static RX context into a pointer, and ..
* .. extend it to two RX contexts - a default and a PAN context.

Whilst here, add a few extra fields in preparation for further iwn(4)
work.

Tested:

* Intel 4965, STA mode - same level of stability
* Intel 5100, STA mode - no change

Submitted by:	Cedric Gross <cg@gross.info>
2013-08-11 01:57:54 +00:00
Adrian Chadd
f8bf74f232 Implement basic 802.11n awareness in the PHY and AMRR rate control code.
* Add 802.11n 2ghz and 5ghz tables, including legacy rates and up to
  MCS23 rates (3x3.)

* Populate the rate code -> rate index lookup table with MCS _and_
  normal rates, but _not_ the basic rate flag.  Since the basic rate flag
  is the same as the MCS flag, we can only use one.

* Introduce some accessor inlines that do PLCP and rate table lookup/access
  and enforce that it doesn't set the basic rate bit.  They're not
  designed for MCS rates, so it will panic.

* Start converting drivers that use the rate table stuff to use the
  accessor inlines and strip the basic flag.

* Teach AMRR about basic 11n - it's still as crap for MCS as it is
  being used by iwn, so it's not a step _backwardS_.

* Convert iwn over to accept 11n MCS rates rather than 'translate' legacy
  to MCS rates.  It doesn't use a lookup table any longer; instead it's a
  function which takes the current node (for HT parameters) and the
  rate code, and returns the hardware PLCP code to use.

Tested:

* ath - it's a no-op, and it works that way
* iwn - both 11n and non-11n
2013-07-04 21:16:49 +00:00
Bernhard Schmidt
97fadf57df Add support for TX packet aggregation. 2011-05-08 12:06:12 +00:00
Bernhard Schmidt
b2ad04c708 Add support for RX packet aggregation. 2011-05-08 11:58:23 +00:00
Bernhard Schmidt
1647639a26 Prepare for transmitting frames at MCS rates:
- instead of calling iwn_plcp_signal() for every frame, map the expected
  value directly within wn->ridx
- concat plcp, rflags and xrflags, there is no clean byte boundary within
  the flags, for example the antenna setting uses bit 6, 7 and 8
- there is still need for a custom rate to plcp mapping, as those expected
  by the hardware are not conform to the std
2011-05-08 11:49:50 +00:00
Bernhard Schmidt
3c2a1fc39d Use the enhanced TX power information availabe on newer EEPROMs. 2011-05-08 10:35:16 +00:00
Bernhard Schmidt
8bb237d949 Add basic support for advanced bluetooth coexistence required
for 6005 gen2b (1030/6030) adapters.
2011-04-20 16:59:27 +00:00
Bernhard Schmidt
9ff2129fbe Pull some features out of the firmware:
- If a ENH_SENS TLV section exit the firmware is capable of doing
  enhanced sensitivity calibration.
- Newer devices/firmwares have more calibration commands therefore
  hardcoding the noise gain/reset commands no longer works. It is
  supposed to use the next index after the newest calibration type
  support. Read the command index of the TLV section if available.
2011-04-19 19:47:41 +00:00
Bernhard Schmidt
9dd0e40b62 Add some new features:
- 6000 series devices need enhanced sensitivity calibration.
- 6000 series devices need a different setting for the shadow reg.
- set the IWN_FLAG_HAS_11N bit if the EEPROM says the device has 11n
  support.

Obtained from:	OpenBSD
2011-04-16 14:56:13 +00:00
Bernhard Schmidt
552e368d27 Bring over the HAL/OPS changes, instead of two const structs it is now
slightly more dynamic.

Obtained from:	OpenBSD
2011-04-16 14:51:46 +00:00
Bernhard Schmidt
a987f807de Just a whitespace sync, some more style(9) conform then others. 2011-04-16 14:40:42 +00:00
Bernhard Schmidt
6cc1bb61fa Sync comments with OpenBSD. 2011-04-16 14:38:57 +00:00
Bernhard Schmidt
786b72c5bc Shuffle code around a bit. Mostly to group functional connected things,
others to get the same order as the OpenBSD code.
2011-04-16 14:36:43 +00:00
Bernhard Schmidt
083e216732 Revert some of local calibration changes in favour of the OpenBSD
implementation. This includes the fix required for the 6050 series
devices.
2011-04-15 20:31:02 +00:00
Bernhard Schmidt
af2e228dc4 Split up watchdog and calibration callout. This allows us to use different
timing on both and to remove some monitor mode specific hacks (which has
no calibration).
2011-04-15 20:17:52 +00:00
Bernhard Schmidt
abd8979b98 Remove IWN_FLAG_HAS_5GHZ and IWN_PCI_BAR0, both unused. 2011-04-14 17:19:33 +00:00
Bernhard Schmidt
2d5c617a52 For 6000 series and newer devices the DC calibration results are no
longer requested of the boot firmware. Instead of sending those results
to the runtime firmware the firmware is told to do the DC calibration
itself.

MFC after:	1 week
2010-12-05 09:00:32 +00:00
Bernhard Schmidt
d8ac0e6633 Rewrite parts of the calibration code which is run while bringing up
the device:
- unobscure some of the code by moving it into its own functions
- get rid of some magic numbers
- create similar structure as the reference driver has, this should
  make further syncs easier
2010-09-19 12:47:41 +00:00
Bernhard Schmidt
7832b1f674 Add support for firmware images in "type-length-value" format.
Obtained from:	OpenBSD
MFC after:	2 weeks
2010-07-15 10:37:49 +00:00
Bernhard Schmidt
f901a391d4 Fix some small whitespace nits.
MFC after:	3 days
2010-07-15 08:05:20 +00:00
Bernhard Schmidt
7373959eb1 * Rename bluetooth coexistence flags, no binary change.
* Enable DC calibration and crystal calibration on Centrino Advanced-N
  6250 parts.
* Workaround for a HW bug (does not affect 4965AGN) that may sporadically
  affect latency under some rare circumstances. From a similar commit to
  iwlwifi.
* Update sensitivity settings for 5000 series to workaround a performance
  bug in the DSP (1000 is not affected so we keep the old values for 5000).
* Update sensitivity settings for 6000 series.
* Set differential gains on 6250 too (but use a 1.0 factor, not 1.5).
* Init OFDM sensitivity with min value (which depends on the chip)
  instead of hardcoding it to 90.
* Read calibration version from ROM and set IWN_GP_DRIVER_CALIB_VER6
  bit on 6x50 if version >= 6.

Approved by:	rpaulo (mentor)
Obtained from:	OpenBSD
MFC after:	2 weeks
2010-04-10 06:58:24 +00:00
Rui Paulo
b6108616ac net80211 rate control framework (net80211 ratectl).
This framework allows drivers to abstract the rate control algorithm and
just feed the framework with the usable parameters. The rate control
framework will now deal with passing the parameters to the selected
algorithm. Right now we have AMRR (the default) and RSSADAPT but there's
no way to select one with ifconfig, yet.
The objective is to have more rate control algorithms in the net80211
stack so all drivers[0] can use it. Ideally, we'll have the well-known
sample rate control algorithm in the net80211 at some point so all
drivers can use it (not just ath).

[0] all drivers that do rate control in software, that is.

Reviewed by:	bschmidt, thompsa, weyongo
MFC after:	1 months
2010-04-07 15:29:13 +00:00
Giorgos Keramidas
578fece5ff Revert iwn channel-argument handling of set_txpower() to r201822
Pass the channel argument as a real argument and not through
RXON.  The RXON version seems to have problem with both the older
228.57.2.23 firmware and the latest 228.61.2.24 version resulting
in device initialization errors like:

  wpa_supplicant[2928]: Failed to initiate AP scan.
  kernel: firmware error log:
  kernel: error type      = "SYSASSERT" (0x00000005)
  kernel: program counter = 0x0000147C
  kernel: source line     = 0x0000058B
  kernel: error data      = 0x0000058B00000000
  kernel: branch link     = 0x0000145A00001492
  kernel: interrupt link  = 0x000006DE00000000
  kernel: time            = 7310
  ...
  kernel: iwn0: iwn_config: could not set TX power
  kernel: iwn0: iwn_init_locked: could not configure device, error 35

By passing the current channel to hal->set_txpower() the firmware
error is fixed, at least for the 4965 chipset of my Thinkpad and
the ones tested by Bernhard.

Submitted by:	Bernhard Schmidt <bschmidt@techwires.net>
Approved by:	rpaulo
2010-01-09 04:00:22 +00:00
Rui Paulo
0f454b93f8 iwn(4) update. Notable changes:
* new firmware
* untested support for 1000 and 6000 series
* bgscan support
* remove unnecessary RXON changes
* allow setting of country/regdomain by enforcing channel flags read
  from the EEPROM
* suspend/resume fixes
* RF kill switch fixes
* LED adjustments
* several bus_dma*() related fixes
* addressed some LORs
* many other bug fixes

Submitted by:	Bernhard Schmidt <bschmidt at techwires.net>
Obtained from:	Brandon Gooch <jamesbrandongooch at gmail dot com> (LED
		related changes), Benjamin Kaduk <kaduk at mit dot edu>
		(LOR fixes), OpenBSD
2009-12-29 19:47:34 +00:00
Rui Paulo
8f30200753 Updated iwn(4) driver supporting the newer series, 5000, 5150 and 5300.
Submitted by:	Bernhard Schmidt <bschmidt at techwires.net>
2009-10-23 22:04:18 +00:00
Sam Leffler
5463c4a485 Overhaul monitor mode handling:
o replace DLT_IEEE802_11 support in net80211 with DLT_IEEE802_11_RADIO
  and remove explicit bpf support from wireless drivers; drivers now
  use ieee80211_radiotap_attach to setup shared data structures that
  hold the radiotap header for each packet tx/rx
o remove rx timestamp from the rx path; it was used only by the tdma support
  for debugging and was mostly useless due to it being 32-bits and mostly
  unavailable
o track DLT_IEEE80211_RADIO bpf attachments and maintain per-vap and
  per-com state when there are active taps
o track the number of monitor mode vaps
o use bpf tap and monitor mode vap state to decide when to collect radiotap
  state and dispatch frames; drivers no longer explicitly directly check
  bpf state or use bpf calls to tap frames
o handle radiotap state updates on channel change in net80211; drivers
  should not do this (unless they bypass net80211 which is almost always
  a mistake)
o update various drivers to be more consistent/correct in handling radiotap
o update ral to include TSF in radiotap'd frames
o add promisc mode callback to wi

Reviewed by:	cbzimmer, rpaulo, thompsa
2009-05-20 20:00:40 +00:00
Andrew Thompson
5efea30f03 Create a taskqueue for each wireless interface which provides a serialised
sleepable context for net80211 driver callbacks. This removes the need for USB
and firmware based drivers to roll their own code to defer the chip programming
for state changes, scan requests, channel changes and mcast/promisc updates.
When a driver callback completes the hardware state is now guaranteed to have
been updated and is in sync with net80211 layer.

This nukes around 1300 lines of code from the wireless device drivers making
them more readable and less race prone.

The net80211 layer has been updated as follows
 - all state/channel changes are serialised on the taskqueue.
 - ieee80211_new_state() always queues and can now be called from any context
 - scanning runs from a single taskq function and executes to completion. driver
   callbacks are synchronous so the channel, phy mode and rx filters are
   guaranteed to be set in hardware before probe request frames are
   transmitted.

Help and contributions from Sam Leffler.

Reviewed by:	sam
2009-05-02 15:14:18 +00:00
Sam Leffler
3971d07be7 Intel 4965 wireless driver (derived from openbsd driver of the same name) 2008-04-29 21:36:17 +00:00