* 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.
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. :/
* 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
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
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.
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
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
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)
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.
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
- 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
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.
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.
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>
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.
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.
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)
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)
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
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
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.
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
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.
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
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
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.
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
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
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
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/...
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)
