summaryrefslogtreecommitdiffstats
path: root/sys/net80211/ieee80211_sta.c
Commit message (Collapse)AuthorAgeFilesLines
* Handle ath-specific and WME IE's in adhoc mode.adrian2012-12-091-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The Adhoc support wasn't parsing and handling the ath specific and WME IEs, thus the atheros vendor support and WME TXOP parameters aren't being copied from the peer. It copies the WME parameters from whichever adhoc node it decides to associate to, rather than just having them be statically configured per adhoc node. This may or may not be exactly "right", but it's certainly going to be more convienent for people - they just have to ensure their adhoc nodes are setup with correct WME parameters. Since WME parameters aren't per-node but are configured on hardware TX queues, if some nodes support WME and some don't - or perhaps, have different WME parameters - things will get quite quirky. So ensure that you configure your adhoc nodes with the same WME parameters. Secondly - the Atheros Vendor IE is parsed and operated on per-node, so this should work out ok between nodes that do and don't do Atheros extensions. Once you see a becaon from that node and you setup the association state, it _should_ parse things correctly. TODO: * I do need to ensure that both adhoc setup paths are correctly updating the IE stuff. Ie, if the adhoc node is created by a data frame instead of a beacon frame, it'll come up with no WME/ath IE config. The next beacon frame that it receives from that node will update the state. I just need to sit down and better understand how that's suppose to work in IBSS mode. Tested: * AR5416 <-> AR9280 - fast frames and the WME configuration both popped up. (This is with a local HAL patch that enables the fast frames capability on the AR5416 chipsets.) PR: kern/165969
* Migrate the power-save functions to be overridable VAP methods.adrian2012-10-021-3/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* Create a new task to handle 802.11n channel width changes.adrian2012-03-251-2/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Only increment is_beacon_bad if we're not scanning.adrian2012-02-281-1/+2
| | | | | Otherwise things such as off-channel probe responses and beacons are also silently discarded and logged against this error counter.
* Track the number of bad beacons received.adrian2012-02-281-1/+3
| | | | PR: kern/165517
* .. add missing include from an incorrect merge.adrian2011-11-081-0/+2
| | | | Sponsored by: Hobnob, Inc.
* Reject frames in STA mode which are not destined to the local STA address.adrian2011-11-081-0/+24
| | | | | | | | | | | | | | | | | Some hardware (eg the AR9160 in STA mode) seems to "leak" unicast FROMDS frames which aren't destined to itself. This angers the net80211 stack - the existing code would fail to find an address in the node table and try passing the frame up to each vap BSS. It would then be accepted in the input routine and its contents would update the local crypto and sequence number state. If the sequence number / crypto IV replay counters from the leaked frame were greater than the "real" state, subsequent "real" frames would be rejected due to out of sequence / IV replay conditions. This is also likely helpful if/when multi-STA modes are added to net80211. Sponsored by: Hobnob, Inc.
* Add 802.11h quiet time element support into net80211.adrian2011-11-081-0/+2
| | | | | | | | | | | | 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
* Fix a panic in the wifi stack when a software beacon miss occurs in the ↵adrian2011-10-021-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | wrong state. The ieee80211_swbmiss() callout is not called with the ic lock held, so it's quite possible the scheduler will run the callout during a state change. This patch: * changes the swbmiss callout to be locked by the ic lock * enforces the ic lock being held across the beacon vap functions by grabbing it inside beacon_miss() and beacon_swmiss(). This ensures that the ic lock is held (and thus the VAP state stays constant) during beacon miss and software miss processing. Since the callout is removed whilst the ic lock is held, it also ensures that the ic lock can't be called during a state change or exhibit any race conditions seen above. Both Edgar and Joel report that this patch fixes the crash and doesn't introduce new issues. Reported by: Edgar Martinez <emartinez@kbcnetworks.com> Reported by: Joel Dahl <joel@vnode.se> Reported by: emaste
* Fix some corner cases in the net80211 sequence number retransmissionadrian2011-05-041-5/+1
| | | | | | | | | | | | | | | | | | | | | | | handling. The current sequence number code does a few things incorrectly: * It didn't try eliminating duplications from HT nodes. I guess it's assumed that out of order / retransmission handling would be handled by the AMPDU RX routines. If a HT node isn't doing AMPDU RX, then retransmissions need to be eliminated. Since most of my debugging is based on this (as AMPDU TX software packet aggregation isn't yet handled), handle this corner case. * When a sequence number of 4095 was received, any subsequent sequence number is going to be (by definition) less than 4095. So if the following sequence number (0) doesn't initially occur and the retransmit is received, it's incorrectly eliminated by the IEEE80211_FC1_RETRY && SEQ_LEQ() check. Try to handle this better. This almost completely eliminates out of order TCP statistics showing up during iperf testing for the 11a, 11g and non-aggregate 11n AMPDU RX case. The only other packet loss conditions leading to this are due to baseband resets or heavy interference.
* Fix a cut&paste error while parsing htcap/htinfo elements. This one isbschmidt2011-03-131-1/+1
| | | | | reponsible for not filling ni_htrates if a pre-ht information element is present.
* Make sure to only accept and handle action frames which are for us. Inbschmidt2011-02-221-4/+9
| | | | | promiscuous mode we might receive stuff which otherwise gets filtered by hardware.
* Add a new mgmt subtype "ACTION NO ACK" defined in 802.11n-2009, while herebschmidt2011-02-211-5/+14
| | | | | | | | | clean up parts of the *_recv_mgmt() functions. - make sure appropriate counters are bumped and debug messages are printed - order the unhandled subtypes by value and add a few missing ones - fix some whitespace nits - remove duplicate code in adhoc_recv_mgmt() - remove a useless comment, probably left in while c&p
* 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
* Initialize ni_txrate after txparams have been setup. Some driversbschmidt2010-08-141-0/+2
| | | | | | | | calculate various things prior to association based on ni_txrate and rely on it being nonzero. PR: kern/149185 MFC after: 2 weeks
* Fixing compilation bustage by adding the missing && back.avatar2010-06-111-1/+1
|
* Some odd APs send beacons on the same TX queue as non-beacons. This breaksrpaulo2010-06-101-1/+1
| | | | | | | | | | | | | | | | | 802.11 duplicate detection. Upon looking at the standard, we discover that 802.11-2007 says: "A receiving QoS STA is also required to keep only the most recent cache entry per<Address 2, TID, sequence-number> triple, storing only the most recently received fragment number for that triple. A receiving STA may omit tuples obtained from broadcast/multicast or ATIM frames from the cache." To fix this, we just disable duplicate detection for multicast/broadcast frames. Reviewed by: sam MFC after: 4 weeks Obtained from: DragonFly
* Fix a couple of bugs with 802.11n:rpaulo2010-03-181-1/+6
| | | | | | | | | | | o Process the BAR frame on the adhoc, mesh and sta modes o Fix the format of the ADDBA reply frame o Fix references to the spec section numbers Also, print the all the MCS rates in bootverbose. Sponsored by: iXsystems, Inc. Obtained from: //depot/user/rpaulo/80211n/...
* fixes a broken software beacon miss handler. There is a race to checkweongyo2010-03-141-0/+2
| | | | | | | vap->iv_bmiss_count == 0 in ieee80211_swbmiss because iv_swbmiss_task is enqueued by taskqueue. Reviewed by: rpaulo
* When taking the AMPDU reorder fastpath, need_tap wasn't beingrpaulo2010-02-031-2/+1
| | | | | | initialized. Initialize on declaration to avoid this. Found with: clang static analyzer
* Call ieee80211_radiotap_rx, not ieee80211_radiotap_tx on sta_input()rpaulo2010-01-251-1/+1
| | | | | | PR: 143163 Submitted by: Alexander Egorenkov <egorenar at gmail.com> MFC after: 3 days
* on transition to SLEEP state mark the station in power save, not awakesam2009-09-031-1/+1
| | | | MFC after: 3 days
* Revamp 802.11 action frame handling:sam2009-07-051-1/+1
| | | | | | | | | | | | | | 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)
* When associating to an AP we don't know if HT is negotiated untilsam2009-06-111-0/+1
| | | | | | 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-3/+3
| | | | iv_flags_ht word
* o station mode channel switch supportsam2009-06-041-7/+145
| | | | | | | | | | 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 handling of devices w/o radiotap support:sam2009-05-251-1/+1
| | | | | | | o do not attach DLT_IEEE802_11_RADIO unless both tx and rx headers are present; this is assumed in the capture code paths o verify the above with asserts in ieee80211_radiotap_{rx,tx} o add missing checks for active taps before calling ieee80211_radiotap_rx
* Overhaul monitor mode handling:sam2009-05-201-22/+17
| | | | | | | | | | | | | | | | | | | | | | | | 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
* whitespacesam2009-04-261-0/+1
|
* print both fc bytes when hitting a protocol version mismatchsam2009-04-261-1/+2
|
* add iv_recv_ctl method to allow hooking rx ctl frame handlingsam2009-04-261-0/+8
|
* o use shared code to handle bpf tap and mbuf cleanupsam2009-04-261-5/+2
| | | | o swap conditional order to put the cheapest first
* Remove spurious 'or'.rpaulo2009-04-231-1/+1
|
* Hoist 802.11 encapsulation up into net80211:sam2009-03-301-0/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | 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
* shuffle code so things build w/o INVARIANTS or IEEE80211_SUPPORT_SUPERGsam2009-03-251-3/+3
| | | | Prodded by: several
* split Atheros SuperG support out into it's own file that's included onlysam2009-03-241-69/+14
| | | | with a new IEEE80211_SUPPORT_SUPERG option
* convert MALLOC/FREE to malloc/freesam2008-12-181-1/+1
|
* Fix checks for fast frames negotiation. ni_ath_flags holds thesam2008-10-301-1/+1
| | | | | | | | | | | | | | capabilities reported by the ap. These need to be cross-checked against the local configuration in the vap. Previously we were only checking the ap capabilities which meant that if an ap reported it was ff-capable but we were not setup to use them we'd try to do ff aggregation and drop the frame. There are a number of problems to be fixed here but applying this fix immediately as the problem causes all traffic to stop (and has not workaround). Reported by: Ashish Shukla
* o use the new association callback to notify the driver when joining a bsssam2008-10-271-0/+5
| | | | | | | in sta and adhoc modes; this should've been done forever ago as most all drivers use this hook to set per-station transmit parameters such as for tx rate control o adjust drivers to remove explicit calls to the driver newassoc method
* add/improve debug msgssam2008-10-251-2/+2
|
* Revert the removal of the MALLOC and FREE macros from the net80211 code.des2008-10-231-1/+1
| | | | Requested by: sam
* Retire the MALLOC and FREE macros. They are an abomination unto style(9).des2008-10-231-1/+1
| | | | MFC after: 3 months
* 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.
* Revamp ht ie handling:sam2008-09-211-5/+6
| | | | | | | | | | | | | | | o change ieee80211_parse_htcap and ieee80211_parse_htinfo to save only internal state obtained from the ie's; no dynamic state such as ni_chw is altered o add ieee80211_ht_updateparams to parse ht cap+info ie's and update dynamic node state o change ieee80211_ht_node_init to not take an htcap ie that is parsed; instead have the caller make a separate call as one caller wants to parse the ie while another wants to parse both cap+info ie's and update state so can better do this with ieee80211_ht_updateparams These changes fix sta mode state handling where the node's channel width was shifted to ht20/ht40 prematurely.
* Cleanup AMPDU handling:sam2008-09-211-13/+9
| | | | | | | | | | | | | | | | | | | | | | For receive: o explicitly tag rx frames w/ M_AMPDU instead of passing frames through the reorder processing according to the node having HT and the frame being QoS data o relax ieee80211_ampdu_reorder asserts to allow any frame to be passed in, unsuitable frames are returned to the caller for normal processing; this permits drivers that cannot inspect the PLCP to mark all data frames as potential ampdu candidates with only a small penalty o add M_AMPDU_MPDU to identify frames resubmitted from the reorder q For transmit: o tag aggregation candidates with M_AMPDU_MPDU o fix the QoS ack policy set in ampdu subframes; we only support immediate BA streams which should be marked for "normal ack" to get implicit block ack behaviour; interestingly certain vendor parts BA'd frames with the 11e BA ack policy set o do not assign a sequence # to aggregation candidates; this must be done when frames are submitted for transmit (NB: this can/will be handled better when aggregation is pulled up to net80211)
* make all checks if ni_chw consistentsam2008-09-061-1/+1
|
* Multi-bss (aka vap) support for 802.11 devices.sam2008-04-201-0/+1647
Note this includes changes to all drivers and moves some device firmware loading to use firmware(9) and a separate module (e.g. ral). Also there no longer are separate wlan_scan* modules; this functionality is now bundled into the wlan module. Supported by: Hobnob and Marvell Reviewed by: many Obtained from: Atheros (some bits)
OpenPOWER on IntegriCloud