summaryrefslogtreecommitdiffstats
path: root/sys/net80211/ieee80211_node.c
Commit message (Collapse)AuthorAgeFilesLines
* Replace the homegrown implementation of nitems() with calls to nitems()rpaulo2013-08-141-3/+1
| | | | | | | | | (param.h). Operating systems that don't have nitems() can easily define it on their own net80211 OS-specific header file. Discussed with: adrian
* Initial cut at making IBSS support 802.11n aware.adrian2013-01-261-2/+60
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | * Add HTINFO field decoding to ieee80211_ies_expand() - it's likely not 100% correct as it's not looking at the draft 11n HTINFO location, but I don't think anyone will care. * When doing an IBSS join make sure the 11n channel configuration is used - otherwise the 11a/11bg channel will be used and there won't be any chance for an upgrade to 11n. * When creating an IBSS network, ensure the channel is updated to an 11n channel so other 11n nodes can see it and speak to it with MCS rates. * Add a bit of code that's disabled for now which handles the HT field updating. This won't work out very well with lots of adhoc nodes as we'd end up ping-ponging between the HT configuration for each node. Instead, we should likely only pay attention to the "master" node we initially associated against and then ensure we propagate that information forward in our subsequent beacons. However, due to the nature of IBSS (ie, there's no specific "master" node in the specification) it's unclear which node we should lift the HT parameters from. So for now this assumes the HT parameters are squirreled away in the initial beacon/probe response. So there's some trickiness here. With ap/sta pairing, the probe response just populates a legacy node and the association request/response is what is used for negotiation 11n-ness (and upgrading things as needed.) With ibss networks, the pairing is done with probe request/response, with discovery being done by creating nodes when new beacons in the IBSS / BSSID are heard. There's no assoc request/response frames going on. So the trick here has been to figure out where to upgrade things. I don't like how I just taught ieee80211_sta_join() to "speak" HT - I'd rather there be an upgrade path when an IBSS node joins and there are HT parameters present. Once I've done that, I'll kill this HT special casing that's going on in ieee80211_sta_join(). Tested: * AR9280, AR5416, AR5212 - basic iperf and ping interoperability tests whilst in a non-encrypted adhoc network. TODO: * Fix up the HT upgrade path for IBSS nodes rather than adding code in ieee80211_sta_join(), then remove my code from there. * When associating, there's a concept of a "master" node in the IBSS which is the node you first joined the network through. It's possible the correct thing to do is to listen to HT updates and configure WME parameters from that node. However, once that node goes away, which node(s) should be listened to for configuration changes? For things like HT channel width, it's likely going to be ok to just associate as HT40 and then use the per-neighbor rate control and HTINFO/HTCAP fields to figure out which rates and configuration to speak. Ie, for a 20MHz 11n node, just speak 20MHz rates to it. It shouldn't "change", like what goes on in AP/STA configurations.
* Fix a crash bug introduced in the iterate node work recently done.adrian2012-09-161-1/+9
| | | | | | When resuming, the first VAP is checked for max_aid; however if there is no VAP, this results in a NULL pointer dereference and kernel panic.
* Fix an incorrect comparison.adrian2012-08-161-3/+2
| | | | PR: kern/170098
* Don't call the node iteration function inside the node table / nodeadrian2012-08-151-14/+108
| | | | | | | | | | | | | | iterate lock. This causes LORs and deadlocks as some code paths will have the com lock held when calling ieee80211_iterate_nodes(). Here, the comlock isn't held during the node table and node iteration locks; and the callback isn't called with any (extra) lock held. PR: kern/170098 Submitted by: moonlightakkiy@yahoo.ca MFC after: 4 weeks
* Create a new task to handle 802.11n channel width changes.adrian2012-03-251-0/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Revert r220907 and r220915.adrian2011-04-221-17/+5
| | | | | Changing the size of struct ieee80211_mimo_info changes the STA info data, breaking ifconfig in general.
* Change the MIMO userland export ABI to include flags, number of radio chains,adrian2011-04-211-5/+17
| | | | | | extended EVM statistics and EXT channel data. ifconfig still displays 3 chains worth of ctl noise/rssi.
* Add initial support for MIMO statistics to net80211.adrian2011-04-081-1/+20
| | | | | | | | | | | | | | | | | | This introduces struct ieee80211_rx_stats - which stores the various kinds of RX statistics which a MIMO and non-MIMO 802.11 device can export. It also fleshes out the mimo export to userland (node_getmimoinfo()). It assumes that MIMO radios (for now) export both ctl and ext channels. Non-11n MIMO radios are possible (and I believe Atheros made at least one), so if that chipset support is added, extra flags to the struct ieee80211_rx_stats can be added to extend this support. Two new input functions have been added - ieee80211_input_mimo() and ieee80211_input_mimo_all() - which MIMO-aware devices can call with MIMO specific statistics. 802.11 devices calling the non-MIMO input functions will still function.
* Honor device capabilities while initializing ni_htrates.bschmidt2011-03-131-4/+1
| | | | | | Instead of hardcoding MCS0-15 generate the table dynamically, also restrict the MCS rates to our own capabilities while parsing a htcap element.
* Pull ieee80211_ratectl_node_init() calls from drivers into net80211.bschmidt2011-01-171-0/+4
| | | | | | | | This fixes hostap mode for at least ral(4) and run(4), because there is no sufficient call into drivers which could be used initialize the node related ratectl variables. MFC after: 3 days
* Instead of using the AMRR ratectl algo as default for drivers which havebschmidt2010-11-061-10/+5
| | | | | | | | | | | | | | | 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
* Wrap remaining ieee80211_ratectl_node_init() calls missed in r211314.bschmidt2010-08-211-3/+6
| | | | MFC after: 1 week
* Introduce IEEE80211_C_RATECTL, drivers which use the ratectl frameworkbschmidt2010-08-141-2/+4
| | | | | | should set this capability. MFC after: 2 weeks
* Initialize ni_txrate after txparams have been setup. Some driversbschmidt2010-08-141-0/+4
| | | | | | | | calculate various things prior to association based on ni_txrate and rely on it being nonzero. PR: kern/149185 MFC after: 2 weeks
* Fix typo. No functional change.rpaulo2010-04-281-1/+1
| | | | Obtained from: DragonFlyBSD
* net80211 rate control framework (net80211 ratectl).rpaulo2010-04-071-0/+2
| | | | | | | | | | | | | | | | | 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
* Remove extraneous semicolons, no functional changes.mbr2010-01-071-1/+1
| | | | | Submitted by: Marc Balmer <marc@msys.ch> MFC after: 1 week
* Implementation of the upcoming Wireless Mesh standard, 802.11s, on therpaulo2009-07-111-6/+67
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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-8/+11
| | | | | | | | | | | | | | | | | | | 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)
* When associating to an AP we don't know if HT is negotiated untilsam2009-06-111-6/+6
| | | | | | we receive the AssocResp, so we can only set ni_txparms properly at that point. To make this possible make node_setuptxparms public as ieee80211_node_setuptxparms.
* iv_flags_ext is full, make room by moving HT-related flags to a newsam2009-06-071-4/+4
| | | | iv_flags_ht word
* Overhaul monitor mode handling:sam2009-05-201-3/+3
| | | | | | | | | | | | | | | | | | | | | | | | 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
* correct handling of ctl frames: the sender's address is always i_addr2 forsam2009-05-141-12/+0
| | | | | | | frames we should expect to process (old code was trying to handle frames we should never see--like ACK) Reviewed by: thompsa, cbzimmer
* Create a taskqueue for each wireless interface which provides a serialisedthompsa2009-05-021-3/+15
| | | | | | | | | | | | | | | | | | | | | | | 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
* fix txparms setup for 108G sta's: ieee80211_iserp_rateset does notsam2009-04-131-2/+3
| | | | | | identify a station operating in turbo-boost mode because it has a pure ofdm rate set; add an explicit check for the channel type instead of depending on IEEE80211_NODE_ERP being set
* Hoist 802.11 encapsulation up into net80211:sam2009-03-301-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | 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
* 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
* split Atheros SuperG support out into it's own file that's included onlysam2009-03-241-0/+13
| | | | with a new IEEE80211_SUPPORT_SUPERG option
* mark nodes created by way of neighbor discovery need to be marked as ERPsam2009-02-201-0/+4
| | | | so they get the correct tx parameters setup by node_settxparms
* Add modes for 1/2 and 1/4-width channels so we have separate roamingsam2009-02-191-0/+4
| | | | | | | | | | | | | | | | | | and xmit parameters. This makes it possible to use tdma on fractional channels. o add IEEE80211_MODE_HALF and IEEE80211_MODE_QUARTER; note these are band-agnostic (may need revisiting) o setup all default rates in ic_sup_rates instead of doing it only for active modes; we need these to calculate the default tx parameters which are not recalculated after a regulatory update (can't just recalculate after installing a new channel list because we might clobber user settings) o remove special case code in ieee80211_get_suprates; this is now a candidate for an inline or removal o add various entries for new modes (roaming+tx params, wme, rate mapping, scan set setup, country ie construction, tdma, basic rates) Note these modes are intentionally not visible through if_media.
* o replace ieee80211_node_reclaim by individual operations to release thesam2009-02-121-60/+2
| | | | | | | | | | references to iv_bss and the sta table; this is equivalent and causes direct reclaim of the old bss node when any references in packets inflight are reclaimed (previously the old node would sit in the bss table until the inactivity processing reclaimed it) o remove ieee80211_node_reclaim now that it's only use is gone Reviewed by: avatar, cbzimmer
* improve key index map reclaim debug msgsam2009-02-111-6/+5
|
* set ni_txparms for static turbo modesam2009-01-291-6/+11
|
* TDMA support for long distance point-to-point links using ath devices:sam2009-01-081-1/+15
| | | | | | | | | | | | | | | 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
* only mark an infrastructure node to require an associd for xmit; fixes adhocsam2009-01-071-1/+4
| | | | mode sta's that join an existing ibss
* mark discovered neighbors QoS capable if they advertise wmesam2008-12-311-0/+4
|
* convert MALLOC/FREE to malloc/freesam2008-12-181-10/+10
|
* Fix ucastkey teardown for drivers that plumb clear keys or similarsam2008-12-151-1/+1
| | | | | | | | | | (e.g. ath): we must check the key index and not whether the key points at a cipher other than "undef". This looks like it's been broken for a while. Might be worth adding an explicit clear cipher at some point though this would require changes to the usage of IEEE80211_KEY_UNDEFINED. PR: 125906
* Replace adhoc checks in ieee80211_start with a per-node flag thatsam2008-12-151-13/+5
| | | | | | | | indicates if an association id is required before outbound traffic is permitted. This cleans up the previous change that broke mcast traffic "to the stack" in ap mode as a side effect. Reviewed by: sephe, thompsa, weongyo
* o re-enable a lock assertsam2008-10-261-5/+5
| | | | o while here reformat a comment to sync w/ other repot's
* New ap-side power save implementation; the main change is to allow driverssam2008-10-261-7/+6
| | | | | to queue frames previously encapsulated on a separate high priority list that is dispatched before the unencapsulated frames (to preserve order).
* set erp flag and tx parameter state when joining a bss; this allowssam2008-10-251-0/+3
| | | | drivers to use ni_txparms
* improve inactivity handling debug supportsam2008-10-251-5/+29
|
* change ieee80211_sta_join to take an explicit channel instead ofsam2008-10-251-2/+2
| | | | | using the value in the scan parameters; this will be used to fix issues with 11b operation
* Revert the removal of the MALLOC and FREE macros from the net80211 code.des2008-10-231-10/+12
| | | | Requested by: sam
* Retire the MALLOC and FREE macros. They are an abomination unto style(9).des2008-10-231-12/+10
| | | | MFC after: 3 months
* cleanup bss node setup; syncs w/ p4 state that's been in use for monthssam2008-09-221-8/+10
|
* RIFS support; needs driver callback for dynamic state changesam2008-09-221-1/+2
|
* MIMO power save support; still needs callbacks for notifying driverssam2008-09-211-1/+3
| | | | of dynamic state change in station mode.
OpenPOWER on IntegriCloud