aboutsummaryrefslogtreecommitdiff
path: root/sys/net80211/ieee80211_adhoc.c
Commit message (Collapse)AuthorAgeFilesLines
* net80211: fix -Wunused-but-set-variable warningsBjoern A. Zeeb2021-11-241-1/+4
| | | | | | | | | | Put the offending variables under the appropriate #ifdefs (mostly IEEE80211_DEBUG, in one case IEEE80211_SUPPORT_SUPERG, and in two cases under __notyet__ to revisit why these had been left there but not used). Sponsored by: The FreeBSD Foundation MFC after: 10 days
* net80211: prevent plaintext injection by A-MSDU RFC1042/EAPOL framesMathy Vanhoef2021-09-301-6/+12
| | | | | | | | | | | | | | | | | | | | | No longer accept plaintext A-MSDU frames that start with an RFC1042 header with EtherType EAPOL. This is done by only accepting EAPOL packets that are included in non-aggregated 802.11 frames. Note that before this patch, FreeBSD also only accepted EAPOL frames that are sent in a non-aggregated 802.11 frame due to bugs in processing EAPOL packets inside A-MSDUs. In other words, compatibility with legitimate devices remains the same. This relates to section 6.5 in the 2021 Usenix "FragAttacks" (Fragment and Forge: Breaking Wi-Fi Through Frame Aggregation and Fragmentation) paper. Submitted by: Mathy Vanhoef (Mathy.Vanhoef kuleuven.be) Security: CVE-2020-26144 PR: 256120 MFC after: 7 days Differential Revision: https://reviews.freebsd.org/D30665
* net80211: mitigation against A-MSDU design flawMathy Vanhoef2021-09-301-1/+1
| | | | | | | | | | | | | | | | | | | | | | | Mitigate A-MSDU injection attacks by detecting if the destination address of a subframe equals an RFC1042 (i.e., LLC/SNAP) header, and if so dropping the complete A-MSDU frame. This mitigates known attacks, although new (unknown) aggregation-based attacks may remain possible. This defense works because in A-MSDU aggregation injection attacks, a normal encrypted Wi-Fi frame is turned into an A-MSDU frame. This means the first 6 bytes of the first A-MSDU subframe correspond to an RFC1042 header. In other words, the destination MAC address of the first A-MSDU subframe contains the start of an RFC1042 header during an aggregation attack. We can detect this and thereby prevent this specific attack. This relates to section 7.2 in the 2021 Usenix "FragAttacks" (Fragment and Forge: Breaking Wi-Fi Through Frame Aggregation and Fragmentation) paper. Submitted by: Mathy Vanhoef (Mathy.Vanhoef kuleuven.be) Security: CVE-2020-24588 PR: 256119 Differential Revision: https://reviews.freebsd.org/D30664
* net80211: reject mixed plaintext/encrypted fragmentsMathy Vanhoef2021-09-301-1/+1
| | | | | | | | | | | | | | | | ieee80211_defrag() accepts fragmented 802.11 frames in a protected Wi-Fi network even when some of the fragments are not encrypted. Track whether the fragments are encrypted or not and only accept successive ones if they match the state of the first fragment. This relates to section 6.3 in the 2021 Usenix "FragAttacks" (Fragment and Forge: Breaking Wi-Fi Through Frame Aggregation and Fragmentation) paper. Submitted by: Mathy Vanhoef (Mathy.Vanhoef kuleuven.be) Security: CVE-2020-26147 PR: 256118 Differential Revision: https://reviews.freebsd.org/D30663
* [net80211] Send a probe request after IBSS node discoveryAdrian Chadd2020-06-051-2/+25
| | | | | | | | | | | | | | | | | | | | | This sends a probe request after IBSS node discovery through beacon frames. This allows things like HT and VHT capabilities to be "negotiated" in adhoc mode. It is .. kinda fire and pray - this isn't retried after discovery so it's quite possible that nodes occasionally don't come up with HT/VHT rate upgrades. At some point it may be a fun side project to add support for retrying these probe requests/negotiations after IBSS node discovery. Tested: * tested with multiple ath(4) NICs in 11n mode. Differential Revision: https://reviews.freebsd.org/D24979 Notes: svn path=/head/; revision=361811
* net80211(4): hide casts for 'i_seq' field offset calculation insideAndriy Voskoboinyk2019-02-101-5/+3
| | | | | | | | | | | ieee80211_getqos() and reuse it in various places. Checked with RTL8188EE, HOSTAP mode + RTL8188CUS, STA mode. MFC after: 2 weeks Notes: svn path=/head/; revision=343990
* sys: general adoption of SPDX licensing ID tags.Pedro F. Giffuni2017-11-271-0/+2
| | | | | | | | | | | | | | | | | Mainly focus on files that use BSD 2-Clause license, however the tool I was using misidentified many licenses so this was mostly a manual - error prone - task. The Software Package Data Exchange (SPDX) group provides a specification to make it easier for automated tools to detect and summarize well known opensource licenses. We are gradually adopting the specification, noting that the tags are considered only advisory and do not, in any way, superceed or replace the license texts. No functional change intended. Notes: svn path=/head/; revision=326272
* [net80211] prepare for A-MSDU/A-MPDU offload crypto / sequence number checking.Adrian Chadd2017-05-201-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | When doing AMSDU offload, the driver (for now!) presents 802.11 frames with the same sequence number and crypto sequence number / IV values up to the stack. But, this will trip afoul over the sequence number detection. So drivers now have a way to signify that a frame is part of an offloaded AMSDU group, so we can just ensure that we pass those frames up to the stack. The logic will be a bit messy - the TL;DR will be that if it's part of the previously seen sequence number then it belongs in the same burst. But if we get a repeat of the same sequence number (eg we sent an ACK but the receiver didn't hear it) then we shouldn't be passing those frames up. So, we can't just say "all subframes go up", we need to track whether we've seen the end of a burst of frames for the given sequence number or not, so we know whether to actually pass them up or not. The first part of doing all of this is to ensure the ieee80211_rx_stats struct is available in the RX sequence number check path and the RX ampdu reorder path. So, start by passing the pointer into these functions to avoid doing another lookup. The actual support will come in a subsequent commit once I know the functionality actually works! Notes: svn path=/head/; revision=318566
* [net80211] Initial VHT node upgrade/downgrade support and initial IE parsing.Adrian Chadd2017-01-131-1/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This is the bulk of the magic to start enabling VHT channel negotiation. It is absolutely, positively not yet even a complete VHT wave-1 implementation. * parse IEs in scan, assoc req/resp, probe req/resp; * break apart the channel upgrade from the HT IE parsing - do it after the VHT IEs are parsed; * (dirty! sigh) add channel width decision making in ieee80211_ht.c htinfo_update_chw(). This is the main bit where negotiated channel promotion through IEs occur. * Shoehorn in VHT node init ,teardown, rate control, etc calls like the HT versions; * Do VHT channel adjustment where appropriate Tested: * monitor mode, ath10k port * STA mode, ath10k port - VHT20, VHT40, VHT80 modes TODO: * IBSS; * hostap; * (ignore mesh, wds for now); * finish 11n state engine - channel width change, opmode notifications, SMPS, etc; * VHT basic rate negotiation and acceptance criteria when scanning, associating, etc; * VHT control/management frame handling (group managment and operating mode being the two big ones); * Verify TX/RX VHT rate negotiation is actually working correctly. Whilst here, add some comments about seqno allocation and locking. To achieve the full VHT rates I need to push seqno allocation into the drivers and finally remove the IEEE80211_TX_LOCK() I added years ago to fix issues. :/ Notes: svn path=/head/; revision=312015
* [net80211] Only send out a probe request if we see an unknown IBSS node that ↵Adrian Chadd2016-11-221-13/+12
| | | | | | | matches our SSID. Notes: svn path=/head/; revision=308956
* [net80211] flesh out more IBSS 11n supportAdrian Chadd2016-11-221-2/+35
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | * Pepper comments around which describe what state(s) we're in when faking up 11n nodes. * By default don't fake it up as 11n until we properly negotiate the 11n capabilities using probe request/response frames. * Send a probe request with our HT information, as the 802.11-2012 spec suggests. * Reassociate with the driver if we've been promoted. This is done because although learning a peer via beacons can learn 11n state, learning peers via hearing probe frames and broadcast frames does not. Thus, sometimes you end up with an 11n peer in the peer table and sometimes you don't. Note that the probe request/response exchange may not actually succeed. Ideally we'd put the peer into some blocking state until we've exchanged probe request/reponse to learn capabilities, or we timeout and just stay non-11n. This is more an experiment to get 11n IBSS nodes actually discovering each other and be able to transmit. There are other issues that creep up which I'll attempt to address in future commits. Tested: * AR9380 NICs in 11n mode. Reviewed by: avos Differential Revision: https://reviews.freebsd.org/D8365 Notes: svn path=/head/; revision=308949
* [net80211] handle hardware encryption offload in the receive pathAdrian Chadd2016-11-191-5/+16
| | | | | | | | | | | | | | | | | | | * teach the crypto modules about receive offload - although I have to do some further reviewing in places where we /can't/ have an RX key * teach the RX data path about receive offload encryption - check the flag, handle NULL key, do decap and checking as appropriate. Tested: * iwn(4), STA mode * ath(4), STA and AP mode * ath10k port, STA mode (hardware encryption) Reviewed by: avos Differential Revision: https://reviews.freebsd.org/D8533 Notes: svn path=/head/; revision=308823
* net80211: switch from ieee80211_iterate_nodes() toAndriy Voskoboinyk2016-11-141-3/+4
| | | | | | | | ieee80211_iterate_nodes_vap() where possible; this should make the code a bit cleaner. Notes: svn path=/head/; revision=308656
* [net80211] don't add IBSS node table entries for neighbors from other SSIDs.Adrian Chadd2016-09-211-1/+13
| | | | | | | | | | | | | | | | | | | | | | | | | | | | The adhoc probe/beacon input path was creating nodes for all SSIDs. This wasn't a problem when the NICs were configured to only process frames for the current BSSID, but that didn't allow IBSS merges. Once avos and I flipped on "beacons from all BSSIDs" to allow for correct IBSS merging, we found this interesting behaviour. This adds a check against the current SSID. * If there's no VAP SSID, allow anything * If there's a VAP SSID, check if the incoming frame has a suitable SSID and if so, allow it. This prevents nodes being created for other SSIDs in probe and beacon frames - ie, beacons overlapping IBSSes with different SSIDs, and probe requests from arbitrary devices. Tested: * AR9380, IBSS mode, both local and other IBSSes. Reviewed by: avos Differential Revision: https://reviews.freebsd.org/D7959 Notes: svn path=/head/; revision=306139
* net80211: fix possible panic in adhoc mode (INIT -> RUN state transition).Andriy Voskoboinyk2016-09-121-0/+13
| | | | | | | | | | | In case if there is already running interface, a second non-sta interface will omit scanning, going directly to RUN state. Handle this case for adhoc mode appropriately. Tested with RTL8821AU, 2 vaps in IBSS mode. Notes: svn path=/head/; revision=305757
* [net80211] re-revert the ibss "is this local to the bss" patch.Adrian Chadd2016-06-251-1/+4
| | | | | | | | | | | | | | | | | | | avos@ pointed out to me that this broke IBSS merging because the rest of the input path no longer was called for non-IBSS frames. I committed a change to not input non-IBSS frames, which stopped nodes being created for BSSes that weren't ours. Unfortunately thta stopped the input path for non-IBSS frames in general, so the management input path didn't work. So, I'll revert this until I come up with a better solution. (Hopefully before 11.) Reviewed by: avos Approved by: re (gjb) Notes: svn path=/head/; revision=302202
* net80211: drop some unused variables / local macrosAndriy Voskoboinyk2016-05-121-2/+1
| | | | | | | | | | Most of them left after some commits (r178354, r191544, r287197 etc.); some were never used. Found by: Clang Static Analyzer Notes: svn path=/head/; revision=299575
* sys/net*: minor spelling fixes.Pedro F. Giffuni2016-05-031-1/+1
| | | | | | | No functional change. Notes: svn path=/head/; revision=298995
* [net80211] fix indenting.Adrian Chadd2016-04-281-2/+2
| | | | | | | Sponsored by: Eva Automation, Inc. Notes: svn path=/head/; revision=298757
* [net80211] handle action frames in adhoc mode from the node that created the ↵Adrian Chadd2016-04-281-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | BSS. We don't have a separate bss node; instead we dup the first node we saw and turn that into the BSS node. This means that action frames from that node would be rejected. So, check that the node is the bss node /and/ the MAC doesn't match ni_macaddr. That's the "right" way for now to verify it's an unknown node. This fixes handling action frames in adhoc mode, which includes negotiating 11n aggregation via ADDBA/DELBA. This by itself isn't enough to correctly create 11n adhoc networks; but it is required for aggregation to be negotiated. Tested: * AR9380, 11n adhoc mode * broadcom 11ac adhoc (vendor platform) Sponsored by: Eva Automation, Inc. Notes: svn path=/head/; revision=298756
* net80211: hide subtype mask & shift in function call.Andriy Voskoboinyk2016-04-201-2/+1
| | | | | | | | | | | | | Hide subtype mask/shift (which is used for index calculation in ieee80211_mgt_subtype_name[] array) in function call. Tested with RTL8188CUS, STA mode. Reviewed by: adrian Differential Revision: https://reviews.freebsd.org/D5369 Notes: svn path=/head/; revision=298376
* [net80211] revert part of r282405 in order to restore IBSS behaviour.Adrian Chadd2016-04-091-4/+1
| | | | | | | | | | | | | | | | | | | This prevents nodes being created for peers on BSSes that are not our own. (Ie, same channel, IBSS, but different BSS.) The "IBSS merge" thing was fixed by me enabling "see all beacons" in the ath(4) driver a few months ago. Trouble is, we now need the filtering again. Tested: * ath(4), IBSS, on a very busy IBSS channel with lots (> 15) IBSS networks. PR: kern/208643 Sponsored by: Eva Automation, Inc. Notes: svn path=/head/; revision=297727
* net80211: eliminate copy-paste nearby ieee80211_check_rxseq()Andriy Voskoboinyk2016-03-011-18/+1
| | | | | | | | Approved by: adrian (mentor) Differential Revision: https://reviews.freebsd.org/D4043 Notes: svn path=/head/; revision=296254
* net80211: add few missing subtype names.Andriy Voskoboinyk2016-02-191-0/+2
| | | | | | | | | | | | | | - Add definitions for Timing Advertisement and Control Wrapper frames. - Refresh ieee80211_mgt_subtype_name and ieee80211_ctl_subtype_name arrays. - Count Timing Advertisement frames as discarded management frames in all modes. Approved by: adrian (mentor) Differential Revision: https://reviews.freebsd.org/D5331 Notes: svn path=/head/; revision=295795
* Begin plumbing ieee80211_rx_stats through the receive path.Adrian Chadd2015-05-251-10/+19
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Smart NICs with firmware (eg wpi, iwn, the new atheros parts, the intel 7260 series, etc) support doing a lot of things in firmware. This includes but isn't limited to things like scanning, sending probe requests and receiving probe responses. However, net80211 doesn't know about any of this - it still drives the whole scan/probe infrastructure itself. In order to move towards suppoting smart NICs, the receive path needs to know about the channel/details for each received packet. In at least the iwn and 7260 firmware (and I believe wpi, but I haven't tried it yet) it will do the scanning, power-save and off-channel buffering for you - all you need to do is handle receiving beacons and probe responses on channels that aren't what you're currently on. However the whole receive path is peppered with ic->ic_curchan and manual scan/powersave handling. The beacon parsing code also checks ic->ic_curchan to determine if the received beacon is on the correct channel or not.[1] So: * add freq/ieee values to ieee80211_rx_stats; * change ieee80211_parse_beacon() to accept the 'current' channel as an argument; * modify the iv_input() and iv_recv_mgmt() methods to include the rx_stats; * add a new method - ieee80211_lookup_channel_rxstats() - that looks up a channel based on the contents of ieee80211_rx_stats; * if it exists, use it in the mgmt path to switch the current channel (which still defaults to ic->ic_curchan) over to something determined by rx_stats. This is enough to kick-start scan offload support in the Intel 7260 driver that Rui/I are working on. It also is a good start for scan offload support for a handful of existing NICs (wpi, iwn, some USB parts) and it'll very likely dramatically improve stability/performance there. It's not the whole thing - notably, we don't need to do powersave, we should not scan all channels, and we should leave probe request sending to the firmware and not do it ourselves. But, this allows for continued development on the above features whilst actually having a somewhat working NIC. TODO: * Finish tidying up how the net80211 input path works. Right now ieee80211_input / ieee80211_input_all act as the top-level that everything feeds into; it should change so the MIMO input routines are those and the legacy routines are phased out. * The band selection should be done by the driver, not by the net80211 layer. * ieee80211_lookup_channel_rxstats() only determines 11b or 11g channels for now - this is enough for scanning, but not 100% true in all cases. If we ever need to handle off-channel scan support for things like static-40MHz or static-80MHz, or turbo-G, or half/quarter rates, then we should extend this. [1] This is a side effect of frequency-hopping and CCK modes - you can receive beacons when you think you're on a different channel. In particular, CCK (which is used by the low 11b rates, eg beacons!) is decodable from adjacent channels - just at a low SNR. FH is a side effect of having the hardware/firmware do the frequency hopping - it may pick up beacons transmitted from other FH networks that are in a different phase of hopping frequencies. Notes: svn path=/head/; revision=283535
* Do not check sequence number for QoS Null frames; set it for generated QoS NullAdrian Chadd2015-05-121-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | frames to 0 From IEEE Std. 802.11-2012, 8.3.2.1 "Data frame format", p. 415 (513): "The Sequence Control field for QoS (+)Null frames is ignored by the receiver upon reception." At this moment, any <mode>_input() function interprets them as regular QoS data frames with TID = 0. As a result, stations, that use another TX sequence for QoS Null frames (e.g. wpi(4), where (QoS) Null frames are generated by the firmware), may experience significant packet loss with any other NIC in hostap mode. Tested: * wpi(4) (author) * iwn(4) - Intel 5100, STA mode (me) PR: kern/200128 Submitted by: Andriy Voskoboinyk <s3erios@gmail.com> Notes: svn path=/head/; revision=282820
* Prepare for supporting driver-overridden curchan when submitting scanAdrian Chadd2015-05-101-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | results. Right now the scan infrastructure assumes the channel is under net80211 control, and that when receiving beacon frames for scanning, the current channel is indeed what ic_curchan is set to. But firmware NICs with firmware scan support need more than this - they can do background scans whilst hiding the off-channel behaviour from net80211. Ie, net80211 still thinks everything is associated and on the main channel, but it's getting scan results from all the background traffic. However sta_add() pays attention to ic_curchan and discards scan results that aren't on the right channel. CCK beacon frames can be decoded from adjacent channels so the receive path and sta_add discard these as appropriate. This is fine for software scanning like for ath(4), but not for firmware NICs. So with those, the whole concept of background firmware scanning won't work without major hacks (eg, overriding ic_curchan before calling the beacon input / scan add.) As part of my scan overhaul, modify sta_add() and the scan_add() APIs to take an explicit current channel. The normal RX path will set it to ic_curchan so it's a no-op. However, drivers may decide to (eventually!) override the scan method to set the "right" current channel based on what the firmware reports the scan state is. So for example, iwn, rsu and other NICs will eventually do this: * driver issues scan start firmware command; * firmware sends a "scan start on channel X" notify; * firmware sends a bunch of beacon RX's as part of the scan results; * .. and the driver will replace scan_add() curchan with channel X, so scan results are correct. * firmware sends a "scan start on channel Y" notify; * firmware sends more beacons... * .. the driver replaces scan_add() curchan with channel Y. Note: * Eventually, net80211 should eventually grow the idea of a per-packet current channel. It's possible in various modes (eg WAVE, P2P, etc) that individual frames can come in from different channels and that is under firmware control rather than driver/net80211 control, so we should support that. Notes: svn path=/head/; revision=282742
* Fix typo introduced in previous commit.Adrian Chadd2015-05-101-1/+1
| | | | | | | | PR: kern/199632 Submitted by: Andriy Voskoboinyk <s3erios@gmail.com> Notes: svn path=/head/; revision=282735
* Use bssid validation for data frames only + add RUN -> RUN state transitionAdrian Chadd2015-05-041-2/+7
| | | | | | | | | | | | However, IBSS merge will be performed only if a driver calls ieee80211_ibss_merge(); so, this applicable to the ath(4) only. Also, this should fix bug 167870. PR: kern/199632 Submitted by: Andriy Voskoboinyk <s3erios@gmail.com> Notes: svn path=/head/; revision=282405
* Mechanically convert to if_inc_counter().Gleb Smirnoff2014-09-191-1/+1
| | | | Notes: svn path=/head/; revision=271861
* Rename definition of IEEE80211_FC1_WEP to IEEE80211_FC1_PROTECTED.Kevin Lo2014-01-081-3/+3
| | | | | | | | | | | | | | The origin of WEP comes from IEEE Std 802.11-1997 where it defines whether the frame body of MAC frame has been encrypted using WEP algorithm or not. IEEE Std. 802.11-2007 changes WEP to Protected Frame, indicates whether the frame is protected by a cryptographic encapsulation algorithm. Reviewed by: adrian, rpaulo Notes: svn path=/head/; revision=260444
* The r48589 promised to remove implicit inclusion of if_var.h soon. PrepareGleb Smirnoff2013-10-261-0/+1
| | | | | | | | | | | to this event, adding if_var.h to files that do need it. Also, include all includes that now are included due to implicit pollution via if_var.h Sponsored by: Netflix Sponsored by: Nginx, Inc. Notes: svn path=/head/; revision=257176
* Disable this variable; the code using it is also disabled.Adrian Chadd2013-02-181-0/+2
| | | | Notes: svn path=/head/; revision=246930
* Disable this code and add a note as to why.Adrian Chadd2013-02-181-0/+15
| | | | | | | | It wasn't currently being called anyway - but being explicit about it can't hurt. Notes: svn path=/head/; revision=246927
* Initial cut at making IBSS support 802.11n aware.Adrian Chadd2013-01-261-0/+18
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | * 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. Notes: svn path=/head/; revision=245928
* Adjust the channel to correctly setup the HT flags when transitioningAdrian Chadd2012-12-101-1/+3
| | | | | | | | | | | | | | | | an IBSS VAP to RUN. An 11n IBSS was beaconing HTINFO/HTCAP IE's that didn't have any HT information setup (like the HT TX/RX MCS bitmask.) Tested: * AR9280, IBSS - both a statically setup channel and a scanned channel PR: kern/172955 Notes: svn path=/head/; revision=244078
* Undo the previous adhoc commit - doing the WME IE handling hereAdrian Chadd2012-12-091-10/+0
| | | | | | | | | | | | | | | | | | | | is totally wrong. If we parse the WME IE here, we'll be constantly updating the WME configuration from each WME enabled IBSS node we see. There's a separate issue where the WME configuration is blanked out when the interface is brought up; the WME parameters aren't "sticky." Also, ieee80211_init_neighbor() parses the ath IE, so doing it here isn't required. Sorry about the noise. PR: kern/165969 Notes: svn path=/head/; revision=244061
* Handle ath-specific and WME IE's in adhoc mode.Adrian Chadd2012-12-091-0/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 Notes: svn path=/head/; revision=244060
* Migrate the power-save functions to be overridable VAP methods.Adrian Chadd2012-10-021-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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. Notes: svn path=/head/; revision=241138
* Fix some corner cases in the net80211 sequence number retransmissionAdrian Chadd2011-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. Notes: svn path=/head/; revision=221418
* Make sure to only accept and handle action frames which are for us. InBernhard Schmidt2011-02-221-4/+13
| | | | | | | | promiscuous mode we might receive stuff which otherwise gets filtered by hardware. Notes: svn path=/head/; revision=218958
* Add a new mgmt subtype "ACTION NO ACK" defined in 802.11n-2009, while hereBernhard Schmidt2011-02-211-60/+41
| | | | | | | | | | | | 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 Notes: svn path=/head/; revision=218927
* Fix a couple of bugs with 802.11n:Rui Paulo2010-03-181-1/+7
| | | | | | | | | | | | | | 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/... Notes: svn path=/head/; revision=205277
* When taking the AMPDU reorder fastpath, need_tap wasn't beingRui Paulo2010-02-031-2/+1
| | | | | | | | | initialized. Initialize on declaration to avoid this. Found with: clang static analyzer Notes: svn path=/head/; revision=203422
* Revamp 802.11 action frame handling:Sam Leffler2009-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) Notes: svn path=/head/; revision=195377
* Fix handling of devices w/o radiotap support:Sam Leffler2009-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 Notes: svn path=/head/; revision=192765
* Overhaul monitor mode handling:Sam Leffler2009-05-201-20/+15
| | | | | | | | | | | | | | | | | | | | | | | | | | | 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 Notes: svn path=/head/; revision=192468
* whitespaceSam Leffler2009-05-021-0/+1
| | | | Notes: svn path=/head/; revision=191754
* print both fc bytes when hitting a protocol version mismatchSam Leffler2009-04-261-1/+2
| | | | Notes: svn path=/head/; revision=191547
* add iv_recv_ctl method to allow hooking rx ctl frame handlingSam Leffler2009-04-261-0/+8
| | | | Notes: svn path=/head/; revision=191546
generated by cgit v1.2.3 (git 2.25.1) at 2024-10-22 22:18:58 +0000