#
94fc800f |
|
18-Feb-2024 |
Gordon Bergling <gbe@FreeBSD.org> |
net80211: Fix two typos in kernel messages - s/defered/deferred/ MFC after: 5 days
|
#
e85eb4c8 |
|
02-Dec-2023 |
Bjoern A. Zeeb <bz@FreeBSD.org> |
net80211: adjust more VHT structures/fields Replace ieee80211_ie_vhtcap with ieee80211_vht_cap and ieee80211_ie_vht_operation with ieee80211_vht_operation. The "ie" version has the two bytes type/length at the beginning which we did not actually use as such (the one place doing did just as unused extra work). Using the non-"ie" versions allows us to re-use them on shared code. Using an enum helps us to not accidentally get unsuppored or unhandled values tough we cannot use it in the struct as we need to ensure the field width. ieee80211_vht_operation is guarded by _KERNEL/WANT_NET80211. While the header is supposed to be exported to user land historically, software such as wpa bring their own structure definitions. For in-tree usage it is only ifconfig which really cares (at least for now). Sponsored by: The FreeBSD Foundation MFC after: 3 days Reviewed by: adrian (earlier), cc Differential Revision: https://reviews.freebsd.org/D42901
|
#
de607e3c |
|
29-Oct-2023 |
Bjoern A. Zeeb <bz@FreeBSD.org> |
net80211: move net_epoch into net80211 Move the net_epoch into net80211 around the if_input calls and out of the driver (in this first case LinuxKPI). This reduces coverage but also allows us to alloc in calls like (*ampdu_rx_start) which do not actually pass data up the stack. The follow-up commits will revert b65f813c1ab99448278961c5ca80dc422b1eae29, 21c4082de9e2cf9a0fd81a9a981ab06022956847, 17c328b6aebfa03cd1c2cbfbbc617e3b341bf1e4, af2441fbc7fa9e522e7f8697e5a181bdd4ff9e00, and 6c3e93cb5a4aa4b8a2d8d4d326f2a7c34d3a4458 for ath. Sponsored by: The FreeBSD Foundation MFC after: 3 days Tested by: few (rtwn, ath, iwlwifi, ...) Reviewed by: adrian Differential Revision: https://reviews.freebsd.org/D42427
|
#
fdafd315 |
|
24-Nov-2023 |
Warner Losh <imp@FreeBSD.org> |
sys: Automated cleanup of cdefs and other formatting Apply the following automated changes to try to eliminate no-longer-needed sys/cdefs.h includes as well as now-empty blank lines in a row. Remove /^#if.*\n#endif.*\n#include\s+<sys/cdefs.h>.*\n/ Remove /\n+#include\s+<sys/cdefs.h>.*\n+#if.*\n#endif.*\n+/ Remove /\n+#if.*\n#endif.*\n+/ Remove /^#if.*\n#endif.*\n/ Remove /\n+#include\s+<sys/cdefs.h>\n#include\s+<sys/types.h>/ Remove /\n+#include\s+<sys/cdefs.h>\n#include\s+<sys/param.h>/ Remove /\n+#include\s+<sys/cdefs.h>\n#include\s+<sys/capsicum.h>/ Sponsored by: Netflix
|
#
685dc743 |
|
16-Aug-2023 |
Warner Losh <imp@FreeBSD.org> |
sys: Remove $FreeBSD$: one-line .c pattern Remove /^[\s*]*__FBSDID\("\$FreeBSD\$"\);?\s*\n/
|
#
4d846d26 |
|
10-May-2023 |
Warner Losh <imp@FreeBSD.org> |
spdx: The BSD-2-Clause-FreeBSD identifier is obsolete, drop -FreeBSD The SPDX folks have obsoleted the BSD-2-Clause-FreeBSD identifier. Catch up to that fact and revert to their recommended match of BSD-2-Clause. Discussed with: pfg MFC After: 3 days Sponsored by: Netflix
|
#
3d0d5b21 |
|
23-Jan-2023 |
Justin Hibbits <jhibbits@FreeBSD.org> |
IfAPI: Explicitly include <net/if_private.h> in netstack Summary: In preparation of making if_t completely opaque outside of the netstack, explicitly include the header. <net/if_var.h> will stop including the header in the future. Sponsored by: Juniper Networks, Inc. Reviewed by: glebius, melifaro Differential Revision: https://reviews.freebsd.org/D38200
|
#
c9b7e9df |
|
31-Aug-2022 |
Bjoern A. Zeeb <bz@FreeBSD.org> |
net80211 / drivers: rename to IEEE80211_FC0_SUBTYPE_QOS_DATA Going through the Frame (Sub)types the "QOS Data" being called "QOS" scheme leads to a naming conflict for QOS_CFPOLL and QOS_CFACKPOLL (if added). Rename QOS* to QOS_DATA* to avoid the conflict and to also better match the standards name. No functional changes intended. Sponsored by: The FreeBSD Foundation MFC after: 5 days Reviewed by: hselasky Differential Revision: https://reviews.freebsd.org/D36409
|
#
bd29f817 |
|
17-Aug-2022 |
Bjoern A. Zeeb <bz@FreeBSD.org> |
net80211: consistently use the IEEE80211_M_ memory related options Replace a malloc() by IEEE80211_MALLOC(). For malloc flags even in the local ieee80211_freebsd.c there was a mix of both versions M_ and IEEE80211_M_. Consistently use the IEEE80211_M_ malloc options everywhere. If the field is changed for malloc, it'll also be changed for the other accessor functions taking a "how" field to avoid any confusion. Sponsored by: The FreeBSD Foundation MFC after: 1 week Reviewed by: adrian Differential Revision: https://reviews.freebsd.org/D36249
|
#
2889cbe2 |
|
12-Aug-2022 |
Adrian Chadd <adrian@FreeBSD.org> |
net80211: add an IEEE80211_IS_PROTECTED() macro Summary: This returns whether the given 802.11 frame has the protected bit set. Test Plan: * tested in AP/STA mode * STA mode - local athp/ath10k driver * AP mode - in tree ath driver Subscribers: imp, melifaro, glebius Reviewed by: bz Approved by: bz Differential Revision: https://reviews.freebsd.org/D36183
|
#
05ea7a3e |
|
24-Nov-2021 |
Bjoern A. Zeeb <bz@FreeBSD.org> |
net80211: fix -Wunused-but-set-variable warnings 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
|
#
ffc19cf5 |
|
06-Jun-2021 |
Mathy Vanhoef <Mathy.Vanhoef@kuleuven.be> |
net80211: prevent plaintext injection by A-MSDU RFC1042/EAPOL frames 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
|
#
f024bdf1 |
|
06-Jun-2021 |
Mathy Vanhoef <Mathy.Vanhoef@kuleuven.be> |
net80211: mitigation against A-MSDU design flaw 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
|
#
11572d7d |
|
06-Jun-2021 |
Mathy Vanhoef <Mathy.Vanhoef@kuleuven.be> |
net80211: reject mixed plaintext/encrypted fragments 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
|
#
af7d9f8e |
|
18-Mar-2021 |
Bjoern A. Zeeb <bz@FreeBSD.org> |
net80211: prefix get_random_bytes() with net80211_ Both linux/random.h and net80211 have a function named get_random_bytes(). With overlapping files included these collide. Arguably the function could be renamed in linuxkpi but the generic name should also not be used in net80211 so rename it there. Sponsored-by: The FreeBSD Foundation MFC-after: 2 weeks Reviewed-by: philip, adrian Differential Revision: https://reviews.freebsd.org/D29335
|
#
662c1305 |
|
01-Sep-2020 |
Mateusz Guzik <mjg@FreeBSD.org> |
net: clean up empty lines in .c and .h files
|
#
f1481c8d |
|
30-Jun-2020 |
Adrian Chadd <adrian@FreeBSD.org> |
[net80211] Migrate HT/legacy protection mode and preamble calculation to per-VAP flags The later firmware devices (including iwn!) support multiple configuration contexts for a lot of things, leaving it up to the firmware to decide which channel and vap is active. This allows for things like off-channel p2p sta/ap operation and other weird things. However, net80211 is still focused on a "net80211 drives all" when it comes to driving the NIC, and as part of this history a lot of these options are global and not per-VAP. This is fine when net80211 drives things and all VAPs share a single channel - these parameters importantly really reflect the state of the channel! - but it will increasingly be not fine when we start supporting more weird configurations and more recent NICs. Yeah, recent like iwn/iwm. Anyway - so, migrate all of the HT protection, legacy protection and preamble stuff to be per-VAP. The global flags are still there; they're now calculated in a deferred taskqueue that mirrors the old behaviour. Firmware based drivers which have per-VAP configuration of these parameters can now just listen to the per-VAP options. What do I mean by per-channel? Well, the above configuration parameters really are about interoperation with other devices on the same channel. Eg, HT protection mode will flip to legacy/mixed if it hears ANY BSS that supports non-HT stations or indicates it has non-HT stations associated. So, these flags really should be per-channel rather than per-VAP, and then for things like "do i need short preamble or long preamble?" turn into a "do I need it for this current operating channel". Then any VAP using it can query the channel that it's on, reflecting the real required state. This patch does none of the above paragraph just yet. I'm also cheating a bit - I'm currently not using separate taskqueues for the beacon updates and the per-VAP configuration updates. I can always further split it later if I need to but I didn't think it was SUPER important here. So: * Create vap taskqueue entries for ERP/protection, HT protection and short/long preamble; * Migrate the HT station count, short/long slot station count, etc - into per-VAP variables rather than global; * Fix a bug with my WME work from a while ago which made it per-VAP - do the WME beacon update /after/ the WME update taskqueue runs, not before; * Any time the HT protmode configuration changes or the ERP protection mode config changes - schedule the task, which will call the driver without the net80211 lock held and all correctly serialised; * Use the global flags for beacon IEs and VAP flags for probe responses and other IE situations. The primary consumer of this is ath10k. iwn could use it when sending RXON, but we don't support IBSS or AP modes on it yet, and I'm not yet sure whether it's required in STA mode (ie whether the firmware parses beacons to change protection mode or whether we need to.) Tested: * AR9280, STA/AP * AR9380, DWDS STA+STA/AP * ath10k work, STA/AP * Intel 6235, STA * Various rtwn / run NICs, DWDS STA and STA configurations
|
#
8379e8db |
|
15-Jun-2020 |
Adrian Chadd <adrian@FreeBSD.org> |
[net80211] Add initial U-APSD negotiation support. U-APSD (unscheduled automatic power save delivery) is a power save method that's a bit better than legacy PS-POLL - stations can mark frames with an extra flag that tells the AP to leak out more frames after it sends its own frames rather than needing to send a PS-POLL to get another frame from the AP. Now, this code just handles the negotiation bits; it doesn't actually implement U-APSD. That's up to drivers, and nothing in the tree yet implements this. I /may/ implement this for ath(4) if I eventually care enough but right now I plan on just implementing it for firmware offload based NICs that handle this in the NIC. I'll commit the ifconfig bit after this and I may have some follow-up commits as this gets used more by me in local testing. This should be a glorious no-op for everyone else. If things change for anyone that isn't fixed by a complete recompile then please reach out to me.
|
#
f3f08e16 |
|
10-Feb-2019 |
Andriy Voskoboinyk <avos@FreeBSD.org> |
net80211(4): hide casts for 'i_seq' field offset calculation inside ieee80211_getqos() and reuse it in various places. Checked with RTL8188EE, HOSTAP mode + RTL8188CUS, STA mode. MFC after: 2 weeks
|
#
fe267a55 |
|
27-Nov-2017 |
Pedro F. Giffuni <pfg@FreeBSD.org> |
sys: general adoption of SPDX licensing ID tags. 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.
|
#
85c4e670 |
|
19-May-2017 |
Adrian Chadd <adrian@FreeBSD.org> |
[net80211] prepare for A-MSDU/A-MPDU offload crypto / sequence number checking. 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!
|
#
46788bb1 |
|
19-Feb-2017 |
Adrian Chadd <adrian@FreeBSD.org> |
[net80211] validate VHT IEs.
|
#
7f19273c |
|
19-Feb-2017 |
Adrian Chadd <adrian@FreeBSD.org> |
[net80211] fix up VHT IE comparison typo Whilst here, add a comment that I need to validate VHT IEs.
|
#
20235662 |
|
19-Feb-2017 |
Adrian Chadd <adrian@FreeBSD.org> |
[net80211] fix NULL pointer dereference in VHT operation in hostap mode. The vht IEs are NULL at this point, so we shouldn't upgrade a node to VHT. I'll fix the upgrade after this! Tested: * ath10k, hostap mode
|
#
51172f62 |
|
13-Jan-2017 |
Adrian Chadd <adrian@FreeBSD.org> |
[net80211] Initial VHT node upgrade/downgrade support and initial IE parsing. 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. :/
|
#
fe75b452 |
|
18-Nov-2016 |
Adrian Chadd <adrian@FreeBSD.org> |
[net80211] handle hardware encryption offload in the receive path * 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
|
#
7db788c6 |
|
14-Nov-2016 |
Andriy Voskoboinyk <avos@FreeBSD.org> |
net80211: switch from ieee80211_iterate_nodes() to ieee80211_iterate_nodes_vap() where possible; this should make the code a bit cleaner.
|
#
95d9a127 |
|
13-Sep-2016 |
Andriy Voskoboinyk <avos@FreeBSD.org> |
net80211: improve error checking in ieee80211_parse_{wpa,rsn}() - Add few checks for group/pairwise ciphers into ieee80211_parse_{wpa,rsn}(). - Split error code and cipher value in wpa_cipher() / rsn_cipher(); current hack with (1 << 32) does not work - it's 1, not 0 (detected by CSA). - Return IEEE80211_REASON_UNSUPP_RSN_IE_VERSION instead of IEEE80211_REASON_IE_INVALID when version field is not equal to RSN_VERSION. Tested with wpi(4) / urtwn(4) (HOSTAP mode). Reviewed by: adrian Differential Revision: https://reviews.freebsd.org/D7887
|
#
4d4d5e25 |
|
09-Jun-2016 |
Andriy Voskoboinyk <avos@FreeBSD.org> |
net80211: fix duplicate packet counter incrementation. Remove 'if_inc_counter(ifp, IFCOUNTER_OPACKETS, 1);' from raw xmit and apbridge path; it will be incremented by ieee80211_tx_complete() after packet transmission. Noticed by: Imre Vadasz <imre@vdsz.com>
|
#
6dbbec93 |
|
19-May-2016 |
Andriy Voskoboinyk <avos@FreeBSD.org> |
net80211: fix more compiler warnings. ieee80211.c: add_chanlist(): 'error' variable will be uninitialized if no channels were passed; return '0' instead. ieee80211_action.c: ieee80211_send_action_register(): drop 'break' after 'return'. ieee80211_crypto_none.c: none_encap(): 'keyid' is not used in non-debug builds; hide it behind IEEE80211_DEBUG ifdef. ieee80211_freebsd.c: Staticize global 'ieee80211_debug' variable (used only in this file). ieee80211_hostap.c: Fix a comment (associatio -> association). ieee80211_ht.c: ieee80211_setup_htrates(): initialize 'maxunequalmcs' to 0 to mute compiler warning. ieee80211_hwmp.c: hwmp_recv_preq(): copy 'prep' between conditional blocks to fix -Wshadow warning. ieee80211_mesh.c: mesh_newstate(): remove duplicate 'ni' definition. mesh_recv_group_data(): fix -Wempty-body warning in non-debug builds. ieee80211_phy.c: ieee80211_compute_duration(): remove 'break' after panic() call. ieee80211_scan_sta.c: Hide some TDMA-specific macros under IEEE80211_SUPPORT_TDMA ifdef adhoc_pick_bss(): remove 'ic' pointer redefinition. ieee80211_sta.c: sta_beacon_miss(): remove 'ic' pointer redefinition. ieee80211_superg.c: superg_ioctl_set80211(): drop unreachable return. Tested with clang 3.8.0, gcc 4.6.4 and gcc 5.3.0.
|
#
601a2543 |
|
12-May-2016 |
Andriy Voskoboinyk <avos@FreeBSD.org> |
net80211: drop some unused variables / local macros Most of them left after some commits (r178354, r191544, r287197 etc.); some were never used. Found by: Clang Static Analyzer
|
#
a4641f4e |
|
03-May-2016 |
Pedro F. Giffuni <pfg@FreeBSD.org> |
sys/net*: minor spelling fixes. No functional change.
|
#
4357a5d1 |
|
20-Apr-2016 |
Andriy Voskoboinyk <avos@FreeBSD.org> |
net80211: hide subtype mask & shift in function call. 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
|
#
d72d72d3 |
|
20-Apr-2016 |
Andriy Voskoboinyk <avos@FreeBSD.org> |
net80211: provide descriptions for reason codes Add text description for deauth/disassoc/etc reason codes in addition to 'reason: <number>' string. Reviewed by: adrian Obtained from: IEEE Std 802.11-2012, 8.4.1.7 "Reason Code field" Differential Revision: https://reviews.freebsd.org/D5367
|
#
4ba33fd1 |
|
20-Apr-2016 |
Andriy Voskoboinyk <avos@FreeBSD.org> |
net80211 (trivial, noop): remove duplicate check from hostap_recv_mgmt() Differential Revision: https://reviews.freebsd.org/D5483
|
#
31021a2b |
|
20-Apr-2016 |
Andriy Voskoboinyk <avos@FreeBSD.org> |
net80211: replace internal LE_READ_*/LE_WRITE_* macro with system le*dec / le*enc functions. Replace net80211 specific macros with system-wide bytestream encoding/decoding functions: - LE_READ_2 -> le16dec - LE_READ_4 -> le32dec - LE_WRITE_2 -> le16enc - LE_WRITE_4 -> le32enc + drop ieee80211_input.h include, where it was included for these operations only. Reviewed by: adrian Differential Revision: https://reviews.freebsd.org/D6030
|
#
0e6cbef2 |
|
05-Apr-2016 |
Adrian Chadd <adrian@FreeBSD.org> |
[net80211] missed commit from last one - always cleanup superg state.
|
#
1ffa8d7e |
|
29-Feb-2016 |
Andriy Voskoboinyk <avos@FreeBSD.org> |
net80211: eliminate copy-paste nearby ieee80211_check_rxseq() Approved by: adrian (mentor) Differential Revision: https://reviews.freebsd.org/D4043
|
#
665d5ae9 |
|
18-Feb-2016 |
Andriy Voskoboinyk <avos@FreeBSD.org> |
net80211: add few missing subtype names. - 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
|
#
d3a4ade3 |
|
11-Oct-2015 |
Adrian Chadd <adrian@FreeBSD.org> |
net80211: free node reference in the ieee80211_parent_xmitpkt() when error happened. Move error handling into ieee80211_parent_xmitpkt() instead of spreading it between functions. Submitted by: <s3erios@gmail.com> Differential Revision: https://reviews.freebsd.org/D3772
|
#
e14a2a4c |
|
25-May-2015 |
Gleb Smirnoff <glebius@FreeBSD.org> |
Cleanup compat shims for FreeBSD versions that predate 10.0-RELEASE. There are no plans to merge anything save a trivial bugfix to stable/9. Discussed with: adrian
|
#
b9b53389 |
|
25-May-2015 |
Adrian Chadd <adrian@FreeBSD.org> |
Convert malloc/free back to #define's, as part of OS portability work. DragonflyBSD uses the FreeBSD wireless stack and drivers. Their malloc() API is named differently, so they don't have userland/kernel symbol clashes like we do (think libuinet.) So, to make it easier for them and to port to other BSDs/other operating systems, start hiding the malloc specific bits behind defines in ieee80211_freebsd.h. DragonflyBSD can now put these portability defines in their local ieee80211_dragonflybsd.h. This should be a great big no-op for everyone running wifi. TODO: * kill M_WAITOK - some platforms just don't want you to use it * .. and/or handle it returning NULL rather than waiting forever. * MALLOC_DEFINE() ? * Migrate the well-known malloc names (eg M_TEMP) to net80211 namespace defines.
|
#
c79f192c |
|
25-May-2015 |
Adrian Chadd <adrian@FreeBSD.org> |
Begin plumbing ieee80211_rx_stats through the receive path. 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.
|
#
c3ebe019 |
|
12-May-2015 |
Adrian Chadd <adrian@FreeBSD.org> |
Do not check sequence number for QoS Null frames; set it for generated QoS Null 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>
|
#
2808a02b |
|
10-May-2015 |
Adrian Chadd <adrian@FreeBSD.org> |
Prepare for supporting driver-overridden curchan when submitting scan 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.
|
#
dea45121 |
|
19-Sep-2014 |
Gleb Smirnoff <glebius@FreeBSD.org> |
Mechanically convert to if_inc_counter().
|
#
5945b5f5 |
|
08-Jan-2014 |
Kevin Lo <kevlo@FreeBSD.org> |
Rename definition of IEEE80211_FC1_WEP to IEEE80211_FC1_PROTECTED. 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
|
#
76039bc8 |
|
26-Oct-2013 |
Gleb Smirnoff <glebius@FreeBSD.org> |
The r48589 promised to remove implicit inclusion of if_var.h soon. Prepare 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.
|
#
b1051653 |
|
21-Aug-2013 |
Adrian Chadd <adrian@FreeBSD.org> |
Add in some backwards compatability hacks to make -HEAD net80211 compile on -9.
|
#
86bd0491 |
|
19-Aug-2013 |
Andre Oppermann <andre@FreeBSD.org> |
Add m_clrprotoflags() to clear protocol specific mbuf flags at up and downwards layer crossings. Consistently use it within IP, IPv6 and ethernet protocols. Discussed with: trociny, glebius
|
#
e7495198 |
|
07-Aug-2013 |
Adrian Chadd <adrian@FreeBSD.org> |
Convert net80211 over to using if_transmit for the dispatch from the upper layer(s). This eliminates the if_snd queue from net80211. Yay! This unfortunately has a few side effects: * It breaks ALTQ to net80211 for now - sorry everyone, but fixing parallelism and eliminating the if_snd queue is more important than supporting this broken traffic scheduling model. :-) * There's no VAP and IC flush methods just yet - I think I'll add some NULL methods for now just as placeholders. * It reduces throughput a little because now net80211 will drop packets rather than buffer them if the driver doesn't do its own buffering. This will be addressed in the future as I implement per-node software queues. Tested: * ath(4) and iwn(4) in STA operation
|
#
5cda6006 |
|
08-Mar-2013 |
Adrian Chadd <adrian@FreeBSD.org> |
Bring over my initial work from the net80211 TX locking branch. 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.
|
#
7ea3aada |
|
05-Jan-2013 |
Adrian Chadd <adrian@FreeBSD.org> |
Handle ps-poll data frame if_transmit() failure. If the data frame transmission failures, it may have a node reference that needs cleaning up. If the frame is marked as M_ENCAP then it should treat recvif as a node reference and clear it. Now - since the mbuf has been freed by calling if_transmit() (even on failure), the mbuf has to be treated as invalid. Hence why the ifp is used.
|
#
88954eb0 |
|
21-Dec-2012 |
Adrian Chadd <adrian@FreeBSD.org> |
Remove a use of if_start() - instead, use if_transmit() to dispatch the frame.
|
#
eb1b1807 |
|
05-Dec-2012 |
Gleb Smirnoff <glebius@FreeBSD.org> |
Mechanically substitute flags from historic mbuf allocator with malloc(9) flags within sys. Exceptions: - sys/contrib not touched - sys/mbuf.h edited manually
|
#
e7f0d7cf |
|
02-Oct-2012 |
Adrian Chadd <adrian@FreeBSD.org> |
Migrate the power-save functions to be overridable VAP methods. 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.
|
#
5a8801b0 |
|
17-Dec-2011 |
Bernhard Schmidt <bschmidt@FreeBSD.org> |
Remove now redundant mac argument. Discussed with: adrian@
|
#
957458a8 |
|
14-Dec-2011 |
Adrian Chadd <adrian@FreeBSD.org> |
Modify the ACL code slightly to support a few nifty things: * Call it before sending probe responses, so the ACL code has the chance to reject sending them. * Pass the whole frame to the ACL code now, rather than just the destination MAC - that way the ACL module can look at the frame contents to determine what the response should be. This is part of some uncommitted work to support band steering. Sponsored by: Hobnob, Inc.
|
#
cd0b8f2d |
|
03-May-2011 |
Adrian Chadd <adrian@FreeBSD.org> |
Fix some corner cases in the net80211 sequence number retransmission 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.
|
#
893c4d6e |
|
22-Feb-2011 |
Bernhard Schmidt <bschmidt@FreeBSD.org> |
Make sure to only accept and handle action frames which are for us. In promiscuous mode we might receive stuff which otherwise gets filtered by hardware.
|
#
96283082 |
|
21-Feb-2011 |
Bernhard Schmidt <bschmidt@FreeBSD.org> |
Add a new mgmt subtype "ACTION NO ACK" defined in 802.11n-2009, while here 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
|
#
a7d5f7eb |
|
19-Oct-2010 |
Jamie Gritton <jamie@FreeBSD.org> |
A new jail(8) with a configuration file, to replace the work currently done by /etc/rc.d/jail.
|
#
8d3cd908 |
|
06-Apr-2010 |
Rui Paulo <rpaulo@FreeBSD.org> |
MFC r203422, r205516: When receiving a management frame, pass the mbuf to bpf before calling iv_recv_mgmt(). iv_recv_mgmt() will generate management frame responses and pass them to bpf before the management frame that triggered the response. PR: 144323 Submitted by: Alexander Egorenkov <egorenar at gmail.com> Sponsored by: iXsystems, inc.
|
#
4e87d54a |
|
27-Mar-2010 |
Rui Paulo <rpaulo@FreeBSD.org> |
Add a comment explaining the previous commit. Submitted by: sam
|
#
323f12ab |
|
23-Mar-2010 |
Rui Paulo <rpaulo@FreeBSD.org> |
When receiving a management frame, pass the mbuf to bpf before calling iv_recv_mgmt(). iv_recv_mgmt() will generate management frame responses and pass them to bpf before the management frame that triggered the response. PR: 144323 Submitted by: Alexander Egorenkov <egorenar at gmail.com> MFC after: 2 weeks Sponsored by: iXsystems, inc.
|
#
2b80a340 |
|
03-Feb-2010 |
Rui Paulo <rpaulo@FreeBSD.org> |
When taking the AMPDU reorder fastpath, need_tap wasn't being initialized. Initialize on declaration to avoid this. Found with: clang static analyzer
|
#
f59310a1 |
|
07-Dec-2009 |
Rui Paulo <rpaulo@FreeBSD.org> |
Fix typo in comment Submitted by: Paul B Mahol <onemda at gmail.com>
|
#
76340123 |
|
05-Jul-2009 |
Sam Leffler <sam@FreeBSD.org> |
Revamp 802.11 action frame handling: 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)
|
#
2bfc8a91 |
|
07-Jun-2009 |
Sam Leffler <sam@FreeBSD.org> |
iv_flags_ext is full, make room by moving HT-related flags to a new iv_flags_ht word
|
#
b8ee2a22 |
|
05-Jun-2009 |
Sam Leffler <sam@FreeBSD.org> |
correct status code returned for ht capability mismatch on assoc/reassoc
|
#
7131987d |
|
03-Jun-2009 |
Sam Leffler <sam@FreeBSD.org> |
When a channel switch is done to a channel with different operating characteristics force the stations to re-associate so protocol state is re-initialized. Note that for 11h/DFS this is irrelevant as channel changes are never cross-band. Reviewed by: ctlaw
|
#
4e150988 |
|
03-Jun-2009 |
Sam Leffler <sam@FreeBSD.org> |
After a channel switch mark associated stations so they will immediately be probed as inactive; this more quickly weeds out stations that don't follow to the new channel.
|
#
e1cfcbcb |
|
01-Jun-2009 |
Sam Leffler <sam@FreeBSD.org> |
Fix monitor mode vaps to work as intended: 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
|
#
a6c3cf3e |
|
25-May-2009 |
Sam Leffler <sam@FreeBSD.org> |
Fix handling of devices w/o radiotap support: 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
|
#
5463c4a4 |
|
20-May-2009 |
Sam Leffler <sam@FreeBSD.org> |
Overhaul monitor mode handling: o replace DLT_IEEE802_11 support in net80211 with DLT_IEEE802_11_RADIO and remove explicit bpf support from wireless drivers; drivers now use ieee80211_radiotap_attach to setup shared data structures that hold the radiotap header for each packet tx/rx o remove rx timestamp from the rx path; it was used only by the tdma support for debugging and was mostly useless due to it being 32-bits and mostly unavailable o track DLT_IEEE80211_RADIO bpf attachments and maintain per-vap and per-com state when there are active taps o track the number of monitor mode vaps o use bpf tap and monitor mode vap state to decide when to collect radiotap state and dispatch frames; drivers no longer explicitly directly check bpf state or use bpf calls to tap frames o handle radiotap state updates on channel change in net80211; drivers should not do this (unless they bypass net80211 which is almost always a mistake) o update various drivers to be more consistent/correct in handling radiotap o update ral to include TSF in radiotap'd frames o add promisc mode callback to wi Reviewed by: cbzimmer, rpaulo, thompsa
|
#
dc7bf546 |
|
26-Apr-2009 |
Sam Leffler <sam@FreeBSD.org> |
print both fc bytes when hitting a protocol version mismatch
|
#
49eae5f7 |
|
26-Apr-2009 |
Sam Leffler <sam@FreeBSD.org> |
add iv_recv_ctl method to allow hooking rx ctl frame handling
|
#
8bbd3e41 |
|
26-Apr-2009 |
Sam Leffler <sam@FreeBSD.org> |
o use shared code to handle bpf tap and mbuf cleanup o swap conditional order to put the cheapest first
|
#
339ccfb3 |
|
30-Mar-2009 |
Sam Leffler <sam@FreeBSD.org> |
Hoist 802.11 encapsulation up into net80211: 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
|
#
616190d0 |
|
24-Mar-2009 |
Sam Leffler <sam@FreeBSD.org> |
split Atheros SuperG support out into it's own file that's included only with a new IEEE80211_SUPPORT_SUPERG option
|
#
72fecb4d |
|
31-Dec-2008 |
Sam Leffler <sam@FreeBSD.org> |
follow prevailing style
|
#
e2126dec |
|
18-Dec-2008 |
Sam Leffler <sam@FreeBSD.org> |
convert MALLOC/FREE to malloc/free
|
#
12c290fe |
|
15-Dec-2008 |
Sam Leffler <sam@FreeBSD.org> |
fix comment Submitted by: Daan Vreeken
|
#
1b999d64 |
|
14-Dec-2008 |
Sam Leffler <sam@FreeBSD.org> |
Replace adhoc checks in ieee80211_start with a per-node flag that 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
|
#
aea78d20 |
|
22-Nov-2008 |
Kip Macy <kmacy@FreeBSD.org> |
convert calls to IFQ_HANDOFF to if_transmit
|
#
d6f57961 |
|
30-Oct-2008 |
Sam Leffler <sam@FreeBSD.org> |
Fix checks for fast frames negotiation. ni_ath_flags holds the 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
|
#
63092fce |
|
25-Oct-2008 |
Sam Leffler <sam@FreeBSD.org> |
New ap-side power save implementation; the main change is to allow drivers to queue frames previously encapsulated on a separate high priority list that is dispatched before the unencapsulated frames (to preserve order).
|
#
c5abbba3 |
|
23-Oct-2008 |
Dag-Erling Smørgrav <des@FreeBSD.org> |
Revert the removal of the MALLOC and FREE macros from the net80211 code. Requested by: sam
|
#
1ede983c |
|
23-Oct-2008 |
Dag-Erling Smørgrav <des@FreeBSD.org> |
Retire the MALLOC and FREE macros. They are an abomination unto style(9). MFC after: 3 months
|
#
d7f03759 |
|
19-Oct-2008 |
Ulf Lilleengen <lulf@FreeBSD.org> |
- Import the HEAD csup code which is the basis for the cvsmode work.
|
#
74fdefa7 |
|
25-Sep-2008 |
Sam Leffler <sam@FreeBSD.org> |
must do a deep copy of mcast packets as they can be modified after dispatch Submitted by: "Jared Go" <jared@hobnob.com>
|
#
fdabd982 |
|
21-Sep-2008 |
Sam Leffler <sam@FreeBSD.org> |
Revamp ht ie handling: 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.
|
#
45f856e3 |
|
21-Sep-2008 |
Sam Leffler <sam@FreeBSD.org> |
Cleanup AMPDU handling: 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)
|
#
693e3122 |
|
26-Jul-2008 |
Sam Leffler <sam@FreeBSD.org> |
don't deauth a station because it sends a ps-poll w/ a bogus aid in it; turns out some devices do this and since we otherwise validate the station is associated and don't use the aid for anything being lenient here allows them to function Submitted by: Chris Zimmermann MFC after: 2 weeks
|
#
b032f27c |
|
20-Apr-2008 |
Sam Leffler <sam@FreeBSD.org> |
Multi-bss (aka vap) support for 802.11 devices. 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)
|