#
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
|
#
ef48d4fa |
|
27-Oct-2023 |
Bjoern A. Zeeb <bz@FreeBSD.org> |
net80211: rename iv_flags_vht to iv_vht_flags While the flag field is internal start naming it as well as "iv_vht*" so we keep all "VHT" fields together. This breaks with what was done done for HT but with HE, EHT, .. coming one day seems the more logic choice. No functional changes intended. Sponsored by: The FreeBSD Foundation MFC after: 3 days Reviewed by: adrian, cc Differential Revision: https://reviews.freebsd.org/D42419
|
#
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
|
#
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
|
#
3dc7a189 |
|
30-Sep-2021 |
Bjoern A. Zeeb <bz@FreeBSD.org> |
net80211: correct input_sta length checks and control frame handling Correct input_sta "assertion" checks. CTS/ACK CTRL frames are shorter then sizeof(struct ieee80211_frame_min) and were thus running into the is_rx_tooshort error case. Use ieee80211_anyhdrsize() to handle this better but make sure we do at least have the first 2 octets needed for that. While here move the safety checks before any code which may not obey them later, just for good style. The non-scanning check further down assumes a frame format also not matching control frames. For now skip the checks for control frames which allows us to deal with some of them at least now. Sponsored by: The FreeBSD Foundation Obtained from: 20210906 wireless v0.91 code drop MFC after: 3 days Reviewed by: adrian Differential Revision: https://reviews.freebsd.org/D32238
|
#
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
|
#
fe5ebb23 |
|
24-Sep-2020 |
Bjoern A. Zeeb <bz@FreeBSD.org> |
Provide MS() and SM() macros for 80211 and wireless drivers. We have (two versions) of MS() and SM() macros which we use throughout the wireless code. Change all but three places (ath_hal, rtwn, and rsu) to the newly provided _IEEE80211_MASKSHIFT() and _IEEE80211_SHIFTMASK() macros. Also change one internal case using both _S and _M instead of just _S away from _M (one of the reasons rtwn and rsu were not changed). This was done semi-mechanically. No functional changes intended. Requested by: gnn (D26091) Reviewed by: adrian (pre line wrap) MFC after: 2 weeks Sponsored by: Rubicon Communications, LLC (d/b/a "Netgate") Differential Revision: https://reviews.freebsd.org/D26539
|
#
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.
|
#
48f25cc3 |
|
05-Jun-2020 |
Adrian Chadd <adrian@FreeBSD.org> |
[net80211] print out node A-MSDU state. Now that the node AMSDU TX/RX flags are correctly set in ieee80211_ht.c, we can print out the AMSDU state here.
|
#
d20ff6e6 |
|
05-Jun-2020 |
Adrian Chadd <adrian@FreeBSD.org> |
[net80211] Migrate short slot time configuration into per-vap and deferred taskqueue updates. The 11b/11g ERP and slot time update handling are two things which weren't migrated into the per-VAP state when Sam did the initial VAP work. That makes sense for a lot of setups where net80211 is driving radio state and the radio only cares about the shared state. However, as noted by a now deleted comment, the ERP and slot time updates aren't EXACTLY correct/accurate - they only take into account the most RECENTLY created VAP, and the state updates when one creates/destroys VAPs isn't exactly great. So: * track the short slot logic per VAP; * whenever the slot time configuration changes, just push it into a deferred task queue update so drivers don't have to serialise it themselves; * if a driver registers a per-VAP slot time handler then it'll just get the per VAP one; * .. if a driver registers a global one then the legacy behaviour is maintained - a single slot time is calculated and pushed out. Note that the calculated slot time is better than the existing logic - if ANY of the VAPs require long slot then it's disabled for all VAPs rather than whatever the last configured VAP did. Now, this isn't entirely complete - the rest of ERP tracking around short/long slot capable station tracking needs to be converted into per-VAP, as well as the preamble/barker flags. Luckily those also can be done in a similar fashion - keep per-VAP counters/flags and unify them before doing the driver update. I'll defer that work until later. All the existing drivers can keep doing what they're doing with the global slot time flags as that is maintained. One driver (iwi) used the per-VAP flags instead of the ic flags, so now that driver will work properly. This unblocks some ath10k porting work as the firmware takes the slot time configuration per-VAP rather than globally, and some firmware handles STA+AP and STA+STA (on same/different channels) configurations where the firmware will switch slot time as appropriate. Tested: * AR9380, STA/AP mode * AR9880 (ath10k), STA mode
|
#
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!
|
#
4d3dcce5 |
|
08-Feb-2017 |
Adrian Chadd <adrian@FreeBSD.org> |
[net80211] quiet IE handling improvements * on the station side, only call the quiet time IE method if we have a quiet IE - otherwise call the NULL method once, and then don't waste time calling NULL * on the beacon generation side - force a beacon regeneration each time quiet time is enabled/disabled. Without this, enabling/disabling quiet time IE would cause the beacon contents to be corrupted since none of the "move contents around" logic (like for CSA and TIM handling) is implemented. This changes the size of ieee80211_node so it requires a kernel recompile, but no userland recompile. Tested: * AR9380, AP mode, enabling/disabling quiet time IE * AR9380, STA mode, with upcoming driver changes.
|
#
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
|
#
260b8f08 |
|
17-Nov-2016 |
Imre Vadász <ivadasz@FreeBSD.org> |
[net80211] Don't check bgscanidle setting in net80211 for full-offload scan. If full-offload scan is used, the NIC driver (or rather the firmware of the NIC) should take care of interrupting and continuing the background scan. So net80211 should ignore the vap->iv_bgscanidle setting then, instead the NIC driver might look at this setting and pass it on to the firmware in some way if possible. Since full-offload scans won't be explicitly interrupted by net80211, it also doesn't really make sense to check the vap->iv_bgscanidle condition in that case, before starting a background scan. If the NIC driver advertises background scan support and full-offload scanning, the firmware should be able to execute that scan without interfering too much with our data traffic. Reviewed by: adrian, avos Approved by: adrian (mentor) Differential Revision: https://reviews.freebsd.org/D8539
|
#
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
|
#
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
|
#
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
|
#
169c392c |
|
09-Apr-2016 |
Adrian Chadd <adrian@FreeBSD.org> |
[net80211] add back in the ff/superg node init call that I accidentally deleted. It's mostly a no-op right now, so it shouldn't have changed behaviour.
|
#
1c7b0c84 |
|
05-Apr-2016 |
Adrian Chadd <adrian@FreeBSD.org> |
[net80211] Initial A-MSDU support for testing / evaluation A-MSDU is another 11n aggregation mechanism where multiple ethernet frames get LLC encapsulated (so they have a length field), padded, and put in a single MPDU (802.11 MAC frame.) This means it gets sent out as a single frame, with a single seqno, it's acked as one frame, etc. It turns out that, hah, atheros fast frames is almost but not quite like this, so I'm reusing all of the current superg/fast-frames stuff in order to actually transmit A-MSDU. Yes, this means that A-MSDU frames are also only aggregated two at a time, so it's not necessarily a huge win, but it's better than nothing. This doesn't do anything by default - the driver needs to say it does A-MSDU as well as set the AMSDU software TX capability so this code path gets exercised. For now, the only driver that enables this is urtwn. I'll enable it for rsu at some point soon. Tested: * Add an amsdu encap path to aggregate two frames, same as the fast-frames path. * Always do the superg init/teardown and node init/teardown stuff, regardless of whether the nodes are doing fast-frames (the ATH capability stuff.) That way we can reuse it for amsdu. * Don't do AMSDU for multicast/broadcast and EAPOL frames. * If we're doing A-MPDU, then don't bother doing FF/A-MSDU. We can likely do both together, but I don't want to change behaviour. * Teach the fast frames approx txtime logic to support the 11n rates. But, since we don't currently have a full "current rate" support, assume it's HT20, long-gi, etc. That way we overshoot on the TX time estimation, so we're always inside the requirements. (And we only aggregate two frames for now, so we're not really going to exceed that.) * Drop the maximum FF age default down to 2ms, otherwise we end up with some very annoyingly large latencies. TODO: * We only aggregate two ethernet frames, so I'm not checking the max A-MSDU size. But when it comes time to support >2 frames, we should obey that. Tested: * urtwn(4)
|
#
b8e29e06 |
|
29-Mar-2016 |
Adrian Chadd <adrian@FreeBSD.org> |
[net80211] migrate the time_* macros to ieee80211_* namespace. It turns out that these will clash very annoyingly with the linux macros in the linuxkpi layer, so let the wookie^Wlinux win. The only user that I can find is ath(4), so fix it there too.
|
#
d8c364fb |
|
21-Mar-2016 |
Andriy Voskoboinyk <avos@FreeBSD.org> |
net80211: enable software beacon miss timer in SLEEP state Tested with WUSB54GC, STA mode (w/ power saving enabled) Reviewed by: adrian Differential Revision: https://reviews.freebsd.org/D5545
|
#
8a54c061 |
|
21-Mar-2016 |
Andriy Voskoboinyk <avos@FreeBSD.org> |
net80211: add missing SLEEP -> AUTH state transition for station mode. Reviewed by: adrian Differential Revision: https://reviews.freebsd.org/D5269
|
#
467f437b |
|
03-Mar-2016 |
Andriy Voskoboinyk <avos@FreeBSD.org> |
net80211: drop <smth> -> INIT state transition warning (STA mode only) This warning is irrelevant, since user can execute 'ifconfig wlan0 down' (or turn off card via rfkill switch) at any time. Approved by: adrian (mentor) Differential Revision: https://reviews.freebsd.org/D5511
|
#
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
|
#
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.
|
#
3b00b9a6 |
|
20-Dec-2014 |
Adrian Chadd <adrian@FreeBSD.org> |
Break out the unicast/multicast TIM bit setting into "set something that indicates we have traffic" bit and a "do something if we have traffic bit." I'm going to be fleshing out this stuff more over time and it'll make more sense to have it broken out into two pieces here.
|
#
dea45121 |
|
19-Sep-2014 |
Gleb Smirnoff <glebius@FreeBSD.org> |
Mechanically convert to if_inc_counter().
|
#
f3b04ec6 |
|
24-Apr-2014 |
Adrian Chadd <adrian@FreeBSD.org> |
Add a SLEEP->SCAN transition. Without this a disassociate or scan request during SLEEP results in a hang. Whilst I'm here, add in some disabled code that will transition to RUN if there's multicast traffic. It's not needed for Atheros hardware but it may be for other hardware. Tested: * AR5416, STA mode (powersave) * AR5212, STA mode (powersave)
|
#
902840a5 |
|
23-Apr-2014 |
Adrian Chadd <adrian@FreeBSD.org> |
Begin fleshing out support for net80211 provided (legacy) sleep management. This transitions the VAP in and out of SLEEP state based on: * whether there's been an active transmission in the last (hardcoded) 500ms; * whether the TIM from the AP indicates there is data available. It uses the beacon reception to trigger the active traffic check. This way there's no further timer running to wake up the CPU from its own sleep states. Right now the VAP isn't woken up for multicast traffic - mostly because the only NIC I plan on doing this for right will auto wakeup and stay awake for multicast traffic indicated in the TIM. So I don't have to manually keep the hardware awake. This doesn't do anything if the NIC doesn't advertise it implements the new SWSLEEP capability AND if the VAP doesn't have powersave enabled. It also doesn't do much with ath(4) as it doesn't currently implement the SLEEP state. Tested: * AR5416, STA mode (with local ath(4) changes)
|
#
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
|
#
24effd11 |
|
09-Dec-2012 |
Adrian Chadd <adrian@FreeBSD.org> |
Handle ath-specific and WME IE's in adhoc mode. 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
|
#
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.
|
#
b94299c4 |
|
24-Mar-2012 |
Adrian Chadd <adrian@FreeBSD.org> |
Create a new task to handle 802.11n channel width changes. 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
|
#
e168e5f9 |
|
28-Feb-2012 |
Adrian Chadd <adrian@FreeBSD.org> |
Only increment is_beacon_bad if we're not scanning. Otherwise things such as off-channel probe responses and beacons are also silently discarded and logged against this error counter.
|
#
fd9a6137 |
|
27-Feb-2012 |
Adrian Chadd <adrian@FreeBSD.org> |
Track the number of bad beacons received. PR: kern/165517
|
#
9848863e |
|
08-Nov-2011 |
Adrian Chadd <adrian@FreeBSD.org> |
.. add missing include from an incorrect merge. Sponsored by: Hobnob, Inc.
|
#
38672d48 |
|
08-Nov-2011 |
Adrian Chadd <adrian@FreeBSD.org> |
Reject frames in STA mode which are not destined to the local STA address. 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.
|
#
32b0e64b |
|
07-Nov-2011 |
Adrian Chadd <adrian@FreeBSD.org> |
Add 802.11h quiet time element support into net80211. 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
|
#
23401900 |
|
01-Oct-2011 |
Adrian Chadd <adrian@FreeBSD.org> |
Fix a panic in the wifi stack when a software beacon miss occurs in the 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
|
#
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.
|
#
9d36b055 |
|
12-Mar-2011 |
Bernhard Schmidt <bschmidt@FreeBSD.org> |
Fix a cut&paste error while parsing htcap/htinfo elements. This one is reponsible for not filling ni_htrates if a pre-ht information element is present.
|
#
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
|
#
a7c6aabd |
|
06-Nov-2010 |
Bernhard Schmidt <bschmidt@FreeBSD.org> |
Instead of using the AMRR ratectl algo as default for drivers which have 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
|
#
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.
|
#
ad8e331b |
|
14-Aug-2010 |
Bernhard Schmidt <bschmidt@FreeBSD.org> |
Introduce IEEE80211_C_RATECTL, drivers which use the ratectl framework should set this capability. MFC after: 2 weeks
|
#
49d2c137 |
|
14-Aug-2010 |
Bernhard Schmidt <bschmidt@FreeBSD.org> |
Initialize ni_txrate after txparams have been setup. Some drivers calculate various things prior to association based on ni_txrate and rely on it being nonzero. PR: kern/149185 MFC after: 2 weeks
|
#
ca765120 |
|
10-Jun-2010 |
Tai-hwa Liang <avatar@FreeBSD.org> |
Fixing compilation bustage by adding the missing && back.
|
#
2bc3bd71 |
|
10-Jun-2010 |
Rui Paulo <rpaulo@FreeBSD.org> |
Some odd APs send beacons on the same TX queue as non-beacons. This breaks 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
|
#
88a85a4c |
|
17-Apr-2010 |
Weongyo Jeong <weongyo@FreeBSD.org> |
MFC r205140: fixes a broken software beacon miss handler. There is a race to check vap->iv_bmiss_count == 0 in ieee80211_swbmiss because iv_swbmiss_task is enqueued by taskqueue. Reviewed by: rpaulo
|
#
0917631f |
|
18-Mar-2010 |
Rui Paulo <rpaulo@FreeBSD.org> |
Fix a couple of bugs with 802.11n: 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/...
|
#
7e62e45f |
|
13-Mar-2010 |
Weongyo Jeong <weongyo@FreeBSD.org> |
fixes a broken software beacon miss handler. There is a race to check vap->iv_bmiss_count == 0 in ieee80211_swbmiss because iv_swbmiss_task is enqueued by taskqueue. Reviewed by: rpaulo
|
#
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
|
#
623592e0 |
|
29-Jan-2010 |
Rui Paulo <rpaulo@FreeBSD.org> |
MFC r202967: Call ieee80211_radiotap_rx, not ieee80211_radiotap_tx on sta_input() PR: 143163 Submitted by:Alexander Egorenkov <egorenar at gmail.com>
|
#
6f28738d |
|
24-Jan-2010 |
Rui Paulo <rpaulo@FreeBSD.org> |
Call ieee80211_radiotap_rx, not ieee80211_radiotap_tx on sta_input() PR: 143163 Submitted by: Alexander Egorenkov <egorenar at gmail.com> MFC after: 3 days
|
#
c32539d4 |
|
03-Sep-2009 |
Sam Leffler <sam@FreeBSD.org> |
on transition to SLEEP state mark the station in power save, not awake MFC after: 3 days
|
#
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)
|
#
d77148fb |
|
10-Jun-2009 |
Sam Leffler <sam@FreeBSD.org> |
When associating to an AP we don't know if HT is negotiated until 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.
|
#
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
|
#
c70761e6 |
|
04-Jun-2009 |
Sam Leffler <sam@FreeBSD.org> |
o station mode channel switch support 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
|
#
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
|
#
ec4313cb |
|
26-Apr-2009 |
Sam Leffler <sam@FreeBSD.org> |
whitespace
|
#
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
|
#
d4f7b233 |
|
23-Apr-2009 |
Rui Paulo <rpaulo@FreeBSD.org> |
Remove spurious 'or'.
|
#
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
|
#
0cd9c215 |
|
24-Mar-2009 |
Sam Leffler <sam@FreeBSD.org> |
shuffle code so things build w/o INVARIANTS or IEEE80211_SUPPORT_SUPERG Prodded by: several
|
#
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
|
#
e2126dec |
|
18-Dec-2008 |
Sam Leffler <sam@FreeBSD.org> |
convert MALLOC/FREE to malloc/free
|
#
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
|
#
e66b0905 |
|
27-Oct-2008 |
Sam Leffler <sam@FreeBSD.org> |
o use the new association callback to notify the driver when joining a bss 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
|
#
07760642 |
|
25-Oct-2008 |
Sam Leffler <sam@FreeBSD.org> |
add/improve debug msgs
|
#
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.
|
#
44f7a6ed |
|
21-Sep-2008 |
Sam Leffler <sam@FreeBSD.org> |
RIFS support; needs driver callback for dynamic state change
|
#
8c070d69 |
|
21-Sep-2008 |
Sam Leffler <sam@FreeBSD.org> |
MIMO power save support; still needs callbacks for notifying drivers of dynamic state change in station mode.
|
#
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)
|
#
0f52b1c4 |
|
06-Sep-2008 |
Sam Leffler <sam@FreeBSD.org> |
make all checks if ni_chw consistent
|
#
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)
|