summaryrefslogtreecommitdiffstats
path: root/sys/net80211/ieee80211_var.h
Commit message (Collapse)AuthorAgeFilesLines
* Allow net80211 to compile on stable/9 and stable/8.adrian2013-08-071-0/+5
|
* Fix typo (dbM -> dBm)eadler2013-06-141-1/+1
| | | | | Submitted by: Daan@vitsch.nl Reviewed by: adrian
* Add const qualifier to the dst parameter of the ifnet if_output method.glebius2013-04-261-1/+1
|
* Implement a utility function to return the current TX power cap foradrian2013-04-161-0/+22
| | | | | | | | | | | | the given node. This takes into account the per-node cap, the ic cap and the per-channel regulatory caps. This is designed to replace references to ni_txpower in various net80211 drivers - ni_txpower doesn't necessarily reflect the actual cap for the given node (eg if the node has the default value of 50dBm (100) and the administrator has manually configured a lower TX power.)
* Bring over my initial work from the net80211 TX locking branch.adrian2013-03-081-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patchset implements a new TX lock, covering both the per-VAP (and thus per-node) TX locking and the serialisation through to the underlying physical device. This implements the hard requirement that frames to the underlying physical device are scheduled to the underlying device in the same order that they are processed at the VAP layer. This includes adding extra encapsulation state (such as sequence numbers and CCMP IV numbers.) Any order mismatch here will result in dropped packets at the receiver. There are multiple transmit contexts from the upper protocol layers as well as the "raw" interface via the management and BPF transmit paths. All of these need to be correctly serialised or bad behaviour will result under load. The specifics: * add a new TX IC lock - it will eventually just be used for serialisation to the underlying physical device but for now it's used for both the VAP encapsulation/serialisation and the physical device dispatch. This lock is specifically non-recursive. * Methodize the parent transmit, vap transmit and ic_raw_xmit function pointers; use lock assertions in the parent/vap transmit routines. * Add a lock assertion in ieee80211_encap() - the TX lock must be held here to guarantee sensible behaviour. * Refactor out the packet sending code from ieee80211_start() - now ieee80211_start() is just a loop over the ifnet queue and it dispatches each VAP packet send through ieee80211_start_pkt(). Yes, I will likely rename ieee80211_start_pkt() to something that better reflects its status as a VAP packet transmit path. More on that later. * Add locking around the management and BAR TX sending - to ensure that encapsulation and TX are done hand-in-hand. * Add locking in the mesh code - again, to ensure that encapsulation and mesh transmit are done hand-in-hand. * Add locking around the power save queue and ageq handling, when dispatching to the parent interface. * Add locking around the WDS handoff. * Add a note in the mesh dispatch code that the TX path needs to be re-thought-out - right now it's doing a direct parent device transmit rather than going via the vap layer. It may "work", but it's likely incorrect (as it bypasses any possible per-node power save and aggregation handling.) Why not a per-VAP or per-node lock? Because in order to ensure per-VAP ordering, we'd have to hold the VAP lock across parent->if_transmit(). There are a few problems with this: * There's some state being setup during each driver transmit - specifically, the encryption encap / CCMP IV setup. That should eventually be dragged back into the encapsulation phase but for now it lives in the driver TX path. This should be locked. * Two drivers (ath, iwn) re-use the node->ni_txseqs array in order to allocate sequence numbers when doing transmit aggregation. This should also be locked. * Drivers may have multiple frames queued already - so when one calls if_transmit(), it may end up dispatching multiple frames for different VAPs/nodes, each needing a different lock when handling that particular end destination. So to be "correct" locking-wise, we'd end up needing to grab a VAP or node lock inside the driver TX path when setting up crypto / AMPDU sequence numbers, and we may already _have_ a TX lock held - mostly for the same destination vap/node, but sometimes it'll be for others. That could lead to LORs and thus deadlocks. So for now, I'm sticking with an IC TX lock. It has the advantage of papering over the above and it also has the added advantage that I can assert that it's being held when doing a parent device transmit. I'll look at splitting the locks out a bit more later on. General outstanding net80211 TX path issues / TODO: * Look into separating out the VAP serialisation and the IC handoff. It's going to be tricky as parent->if_transmit() doesn't give me the opportunity to split queuing from driver dispatch. See above. * Work with monthadar to fix up the mesh transmit path so it doesn't go via the parent interface when retransmitting frames. * Push the encryption handling back into the driver, if it's at all architectually sane to do so. I know it's possible - it's what mac80211 in Linux does. * Make ieee80211_raw_xmit() queue a frame into VAP or parent queue rather than doing a short-cut direct into the driver. There are QoS issues here - you do want your management frames to be encapsulated and pushed onto the stack sooner than the (large, bursty) amount of data frames that are queued. But there has to be a saner way to do this. * Fragments are still broken - drivers need to be upgraded to an if_transmit() implementation and then fragmentation handling needs to be properly fixed. Tested: * STA - AR5416, AR9280, Intel 5300 abgn wifi * Hostap - AR5416, AR9160, AR9280 * Mesh - some testing by monthadar@, more to come.
* Migrate the power-save functions to be overridable VAP methods.adrian2012-10-021-0/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | This turns ieee80211_node_pwrsave(), ieee80211_sta_pwrsave() and ieee80211_recv_pspoll() into methods. The intent is to let drivers override these and tie into the power save management pathway. For ath(4), this is the beginning of forcing a node software queue to stop and start as needed, as well as supporting "leaking" single frames from the software queue to the hardware. Right now, ieee80211_recv_pspoll() will attempt to transmit a single frame to the hardware (whether it be a data frame on the power-save queue or a NULL data frame) but the driver may have hardware/software queued frames queued up. This initial work is an attempt at providing the hooks required to implement correct behaviour. Allowing ieee80211_node_pwrsave() to be overridden allows the ath(4) driver to pause and unpause the entire software queue for a given node. It doesn't make sense to transmit anything whilst the node is asleep. Please note that there are other corner cases to correctly handle - specifically, setting the MORE data bit correctly on frames to a station, as well as keeping the TIM updated. Those particular issues can be addressed later.
* Extend the radiotap code to be aware of the size of any extra vendoradrian2012-06-181-0/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | bitmaps that may occur. The way this works is: * the beginning of the radiotap frame has a 32 bit "radiotap" namespace bitmap; * if the vendor bitmap bit is set, then the next bitmap will be interpreted as a vendor bitmap; * this can keep going on and on (ie, more vendor and radiotap namespace bitmaps can be added) until the last bitmap with no "more bitmaps" set. Now, the radiotap code gets its grubby fingers into the supplied radiotap rx/tx buffer and replaces the channel configuration for each frame. I don't know why it's not up to the drivers themselves to do this, but I digress. So, if a vendor bitmap (or two, etc) exists, the offset calculations will be all completely wrong. This particular patch introduces ieee80211_radiotap_attachv(), which includes the number of vendor bitmaps (well, any other bitmaps, vendor or otherwise) between the end of the bitmap/header and the start of the actual radiotap field entries. This makes the radiotap calculations "right", so it correctly calculates where to overwrite the channel configuration. The long term fix is to go through and make each driver update the channel configuration, as some of the fields are already being updated. That, however, is a longer term fix that will need each driver fixed. I leave that as an exercise to someone in the future.
* Create a new task to handle 802.11n channel width changes.adrian2012-03-251-0/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Currently, a channel width change updates the 802.11n HT info data in net80211 but it doesn't trigger any device changes. So the device driver may decide that HT40 frames can be transmitted but the last device channel set only had HT20 set. Now, a task is scheduled so a hardware reset or change isn't done during any active ongoing RX. It also means that it's serialised with the other task operations (eg channel change.) This isn't the final incantation of this work, see below. For now, any unmodified drivers will simply receive a channel change log entry. A subsequent patch to ath(4) will introduce some basic channel change handling (by resetting the NIC.) Other NICs may need to update their rate control information. TODO: * There's still a small window at the present moment where the channel width has been updated but the task hasn't been fired. The final version of this should likely pass in a channel width field to the driver and let the driver atomically do whatever it needs to before changing the channel. PR: kern/166286
* Fix some net80211 enum nits:bschmidt2011-12-171-5/+6
| | | | | | | | | | - ic_vap_create() uses an ieee80211_opmode argument - ieee80211_rate2media() takes an ieee80211_phymode argument - ieee80211_plcp2rate() takes an ieee80211_phytype argument - cast to enum ieee80211_protmode and ieee80211_roamingmode to silence compiler warnings Submitted by: arundel@
* Add 802.11h quiet time element support into net80211.adrian2011-11-081-0/+10
| | | | | | | | | | | | This supports both station and hostap modes: * Station mode quiet time element support listens to quiet time IE's and modifies the local quiet time configuration as appropriate; * Hostap mode both obeys the locally configured quiet time period and includes it in beacon frames so stations also can obey as needed. Submitted by: Himali Patel <himali.patel@sibridgetech.com> Sponsored by: Sibridge Technologies
* Add a callback for ADDBA response timeouts.adrian2011-06-201-0/+2
| | | | | | | | | | | | TX for the given TID needs to be paused during ADDBA requests (and unpaused once the session is established.) Since net80211 currently doesn't implement software aggregation, if this pause/unpause is done in the driver (as it is in my development branch) then it will need to be unpaused both on ADDBA response and on ADDBA timeout. This callback allows the driver to unpause TX for the relevant TID. Reviewed by: bschmidt
* Fix typo, it is MPDU not MDPU.bschmidt2011-05-211-1/+1
|
* First step on removing the harcoded RX/TX stream and MCS0-15 assumptions.bschmidt2011-03-131-0/+4
| | | | | | | | | Initialize ic_rxstream/ic_txstream with 2, for compatibility reasons. Introduce 4 new HTC flags, which are used in addition to ic_rxstream and ic_txstream to compute the hc_mcsset content and also for initializing ni_htrates. The number of spatial streams is enough to determine support for MCS0-31 but not for MCS32-76 as well as some TX parameters in the hc_mcsset field.
* Instead of using the AMRR ratectl algo as default for drivers which havebschmidt2010-11-061-2/+1
| | | | | | | | | | | | | | | the IEEE80211_C_RATECTL flag set, default to NONE for all drivers. Only if a driver calls ieee80211_ratectl_init() check if the NONE algo is still selected and try to use AMRR in that case. Drivers are still free to use any other algo by calling ieee80211_ratectl_set() prior to the ieee80211_ratectl_init() call. After this change it is now safe to assume that a ratectl algo is always available and selected, which renders the IEEE80211_C_RATECTL flag pretty much useless. Therefore revert r211314 and 211546. Reviewed by: rpaulo MFC after: 2 weeks
* Introduce IEEE80211_C_RATECTL, drivers which use the ratectl frameworkbschmidt2010-08-141-1/+2
| | | | | | should set this capability. MFC after: 2 weeks
* Add ic_rxstream and ic_txstream. These variables hold the number of RXrpaulo2010-04-281-1/+2
| | | | | | | streams and the number of TX streams respectively. Obtained from: //depot/user/rpaulo/80211n/... Sponsored by: iXsystems, inc.
* net80211 rate control framework (net80211 ratectl).rpaulo2010-04-071-1/+4
| | | | | | | | | | | | | | | | | 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
* Constify vap argument of ieee80211_{note,discard}* functions.rpaulo2010-03-311-6/+6
| | | | MFC after: 1 week
* Add a new field for extended HT capabilities.rpaulo2010-03-231-1/+4
| | | | | | Submitted by: Alexander Egorenkov <egorenar at gmail.com> MFC after: 2 weeks Sponsored by: iXsystems, inc.
* Use the iflladdr_event event to keep the mac address on the vap in sync withthompsa2010-01-191-1/+2
| | | | | | | the parent wirless interface. If the user passed in a mac address or it was autogenerated then flag this to avoid trashing it on update. This will fix wlan+lagg in a post vap world.
* Fix #ifdefs so that GCC 4.4 doesn't complain about it.trasz2010-01-081-3/+3
| | | | Reviewed by: rpaulo
* Implementation of the upcoming Wireless Mesh standard, 802.11s, on therpaulo2009-07-111-5/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | net80211 wireless stack. This work is based on the March 2009 D3.0 draft standard. This standard is expected to become final next year. This includes two main net80211 modules, ieee80211_mesh.c which deals with peer link management, link metric calculation, routing table control and mesh configuration and ieee80211_hwmp.c which deals with the actually routing process on the mesh network. HWMP is the mandatory routing protocol on by the mesh standard, but others, such as RA-OLSR, can be implemented. Authentication and encryption are not implemented. There are several scripts under tools/tools/net80211/scripts that can be used to test different mesh network topologies and they also teach you how to setup a mesh vap (for the impatient: ifconfig wlan0 create wlandev ... wlanmode mesh). A new build option is available: IEEE80211_SUPPORT_MESH and it's enabled by default on GENERIC kernels for i386, amd64, sparc64 and pc98. Drivers that support mesh networks right now are: ath, ral and mwl. More information at: http://wiki.freebsd.org/WifiMesh Please note that this work is experimental. Also, please note that bridging a mesh vap with another network interface is not yet supported. Many thanks to the FreeBSD Foundation for sponsoring this project and to Sam Leffler for his support. Also, I would like to thank Gateworks Corporation for sending me a Cambria board which was used during the development of this project. Reviewed by: sam Approved by: re (kensmith) Obtained from: projects/mesh11s
* Add ieee80211_ageq; a facility for staging packets that requiresam2009-07-051-0/+5
| | | | | | | | | | | | | | | | | | | long-term work before they can be serviced. Packets are tagged and assigned an age (in seconds) at the point they are added to the queue. If a packet is not retrieved before it's age expires it is reclaimed. Tagging can take two forms: a reference to an ieee80211_node (as happens in the tx path) or an opaque token in cases where there is no reference or the node structure is not stable (i.e. it's going to be destroyed). o add ic_stageq to replace the per-node wds staging queue used for dynamic wds o add ieee80211_mac_hash for building ageq tokens; this computes a 32-bit hash from an 802.11 mac address (copied from the bridge) o while here fix a stray ';' noticed in IEEE80211_PSQ_INIT Reviewed by: rpaulo Approved by: re (kensmith)
* Revamp 802.11 action frame handling:sam2009-07-051-3/+4
| | | | | | | | | | | | | | o add a new facility for components to register send+recv handlers o ieee80211_send_action and ieee80211_recv_action now use the registered handlers to dispatch operations o rev ieee80211_send_action api to enable passing arbitrary data o rev ieee80211_recv_action api to pass the 802.11 frame header as it may be difficult to locate o update existing IEEE80211_ACTION_CAT_BA and IEEE80211_ACTION_CAT_HT handling o update mwl for api rev Reviewed by: rpaulo Approved by: re (kensmith)
* iv_flags_ext is full, make room by moving HT-related flags to a newsam2009-06-071-20/+28
| | | | iv_flags_ht word
* o add bits for STBC and Greenfieldsam2009-06-061-5/+8
| | | | o fix some comments
* o station mode channel switch supportsam2009-06-041-1/+2
| | | | | | | | | | o IEEE80211_IOC_CHANSWITCH fixups: - restrict to hostap vaps - return EOPNOTSUPP instead of EINVAL when applied to !hostap vap or to a vap w/o 11h enabled - interpret count of 0 to mean cancel the current CSA Reviewed by: rpaulo, avatar
* Fix monitor mode vaps to work as intended:sam2009-06-021-2/+3
| | | | | | | o track # bpf taps on monitor mode vaps instead of # monitor mode vaps o spam monitor mode taps on tx/rx o fix ieee80211_radiotap_rx_all to dispatch frames only if the vap is up o while here print radiotap (and superg) state in show com
* pad data structures to enable integration of future features w/o abi breakagesam2009-06-011-0/+2
|
* Overhaul monitor mode handling:sam2009-05-201-4/+37
| | | | | | | | | | | | | | | | | | | | | | | | 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
* make superg/fast-frames state dynamically-allocated (and indirect offsam2009-05-021-9/+3
| | | | | the com structure instead of embedded); this reduces the overhead when not configured and reduces visibility of the contents
* Create a taskqueue for each wireless interface which provides a serialisedthompsa2009-05-021-5/+33
| | | | | | | | | | | | | | | | | | | | | | | 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
* add IEEE80211_FEXT_4ADDR to indicate ieee80211_encap should do 4-addresssam2009-04-261-2/+3
| | | | | encapsulation when relaying frames; this reduces the cost of the test and enables use for situations other than "sta vap + dwds"
* don't depend on includes to get definitions of struct ieee80211_tx_ampdusam2009-04-261-0/+2
| | | | and ieee80211_rx_ampdu; these should've been part of r191552
* allow drivers to hook ampdu rx start/stopsam2009-04-261-0/+6
|
* add iv_recv_ctl method to allow hooking rx ctl frame handlingsam2009-04-261-0/+2
|
* Change if_output to take a struct route as its fourth argument in orderkmacy2009-04-161-1/+1
| | | | | | to allow passing a cached struct llentry * down to L2 Reviewed by: rwatson
* o add a capability for drivers that require 802.3 encapsulation ofsam2009-04-081-2/+3
| | | | | | | frames passed down through the transmit path o mark ndis requiring 802.3 encap'd frames Reviewed by: "Paul B. Mahol" <onemda@gmail.com>, thompsa
* Hoist 802.11 encapsulation up into net80211:sam2009-03-301-0/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | o call ieee80211_encap in ieee80211_start so frames passed down to drivers are already encapsulated o remove ieee80211_encap calls in drivers o fixup wi so it recreates the 802.3 head it requires from the 802.11 header contents o move fast-frame aggregation from ath to net80211 (conditional on IEEE80211_SUPPORT_SUPERG): - aggregation is now done in ieee80211_start; it is enabled when the packets/sec exceeds ieee80211_ffppsmin (net.wlan.ffppsmin) and frames are held on a staging queue according to ieee80211_ffagemax (net.wlan.ffagemax) to wait for a frame to combine with - drivers must call back to age/flush the staging queue (ath does this on tx done, at swba, and on rx according to the state of the tx queues and/or the contents of the staging queue) - remove fast-frame-related data structures from ath - add ieee80211_ff_node_init and ieee80211_ff_node_cleanup to handle per-node fast-frames state (we reuse 11n tx ampdu state) o change ieee80211_encap calling convention to include an explicit vap so frames coming through a WDS vap are recognized w/o setting M_WDS With these changes any device able to tx/rx 3Kbyte+ frames can use fast-frames. Reviewed by: thompsa, rpaulo, avatar, imp, sephe
* MFP mesh11s:rpaulo2009-03-301-1/+1
| | | | Add mesh debugging bit replacing the now deprecated RADKEYS.
* o add ic_rt to track the rate table for the current channel; this enablessam2009-03-291-0/+2
| | | | | calculation of packet transmit times to do things like check txop limits o remove equivalent driver code and convert to use net80211 state
* Eliminate ic_myaddr so changing the mac address of a device works correctly:sam2009-03-291-2/+2
| | | | | | | | | | | o remove ic_myaddr from ieee80211com o change ieee80211_ifattach to take the mac address of the physical device and use that to setup the lladdr. o replace all references to ic_myaddr in drivers by IF_LLADDR o related cleanups (e.g. kill dead code) PR: kern/133178 Reviewed by: thompsa, rpaulo
* Minor cleanups of tdma protocol handling:sam2009-03-181-1/+1
| | | | | | | | | | | o break out version-related code to simplify rev'ing the protocol o add parameter validation macros so checks that appear multiple places are consistent (and easy to change) o add protocol version check when looking for a scan candidate o improve scan debug output format o rewrite beacon update handling to calculate a bitmask of changed values and pass that down through the driver callback so drivers can optimize work o do slot bounds check before use when parsing received beacons
* remove ic_stats; it was intended to accumulate stats from vaps as theysam2009-02-131-1/+0
| | | | were reaped but was never used and is inaccessible
* oops, fix octal escape sequencesam2009-02-111-1/+1
|
* fix mis-numbering of IEEE80211_MSG_BITSsam2009-02-111-4/+4
|
* change ic_getradiocaps driver callback to include the max # channelssam2009-01-271-1/+1
| | | | so callers know the size of the array passed down
* o make %b msg bit defines public (to user apps too)sam2009-01-271-0/+31
| | | | o rename IEEE80211_C_CRYPTO_BITS to IEEE80211_CRYPTO_BITS
* TDMA support for long distance point-to-point links using ath devices:sam2009-01-081-2/+13
| | | | | | | | | | | | | | | o add net80211 support for a tdma vap that is built on top of the existing adhoc-demo support o add tdma scheduling of frame transmission to the ath driver; it's conceivable other devices might be capable of this too in which case they can make use of the 802.11 protocol additions etc. o add minor bits to user tools that need to know: ifconfig to setup and configure, new statistics in athstats, and new debug mask bits While the architecture can support >2 slots in a TDMA BSS the current design is intended (and tested) for only 2 slots. Sponsored by: Intel
* Fix definition of IEEE80211_CHAN_MAX; it was defined as 255 butsam2008-12-151-1/+1
| | | | | | | really was meant to be 256. Adjust usage accordingly and replace bogus usage of this value in checking IEEE channel #'s. NB: this causes an ABI change; ifconfig must be recompiled
OpenPOWER on IntegriCloud