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
The standard uses 80+80 and 80p80 but nowhere 80_80.
Switch the latter to 80P80 for all the macros and comments refering
to #defined flags which I could find.
The only place we leave as 80p80 is the ifconfig command line arguments
as we spell them all in lower case.
Ideally we would use 80+80 for any interactions with the user and
80P80 for anything internal but let us not confuse parsers and
hence avoid the '+' in either case.
Reviewed by: adrian, gnn
MFC after: 2 weeks
Sponsored by: Rubicon Communications, LLC (d/b/a "Netgate")
Differential Revision: https://reviews.freebsd.org/D26001
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
In the 11n world, most NICs did A-MPDU receive/transmit offloading but
not A-MSDU offloading. So, the net80211 A-MPDU receive path would just
receive MPDUs, do the reordering bit, pass it up to the rest of
net80211 for crypto decap and then do A-MSDU decap before throwing ethernet
frames up to the rest of the system.
However 11ac and 11ax NICs are increasingly doing A-MSDU offload (and
newer 11ax stuff does socket offload, but hey I don't want to scare people
JUST yet) - so although A-MPDU reordering may be done in the OS, A-MSDUs
look like a normal MPDU. This means that all the MSDUs are actually
faked into a set of MPDUs with matching 802.11 header - the sequence number,
QoS header and any encryption verification bits (like IV) are just copied.
This shows up as MASSIVE packet loss in net80211, cause after the first MPDU
we just toss the rest.
(And don't get me started about ethernet decap with A-MPDU host reordering;
we'll have to cross that bridge for later 11ac and 11ax bits too.)
Anyway, this work changes each A-MPDU reorder slot into an mbufq.
The mbufq is treated as a whole set of frames to pass up to the stack
and reordered/de-duped as a group. The last frame in the reorder list
is checked to see if it's an A-MSDU final frame so any duplicates are
correctly tossed rather than double-received. Other than that, the
rest of the logic is unchanged.
The previous commit did a small subset of this - if there wasn't any reordering
going on then it'd accept the A-MSDUs. This is the rest of the needed work.
This is a no-op for 11n NICs doing A-MPDU reordering but needing software
A-MSDU decap - they aren't tagged as A-MSDU and so any subsequent
frames added to the reorder slot are tossed.
Tested:
* QCA9880 (ath10k/athp) - STA/AP mode;
* RT3593 (if_rsu) - 11n STA+DWDS mode (I'm committing through it rn);
* QCA9380 (if_ath) - STA/AP mode.
When doing A-MSDU offload handling the driver is required to mark
A-MSDUs from the same MPDU with the same sequence number.
It then tags them as AMSDU (if it's a decap'ed A-MSDU) and AMSDU_MORE
(saying there's more AMSDUs decapped in the same MSDU.)
This allows encryption and sequence number offload to work right.
In the A-MSDU path the sequence number check looks at the A-MSDU flags
in the frame to see whether it's part of the same seqno and will pass them
(ie, not increment rx_seq until the last A-MSDU is seen from the driver,
or a new seqno shows up.0
However, I did this work in the A-MSDU path but not the A-MSDU in A-MPDU path.
For the non A-MDSU offload case the A-MPDU receive reordering will do its
thing and then pass up the MPDU up for decap - which then will see it's
an A-MSDU and decap each sub-frame. But this isn't done for offloaded
A-MSDU frames.
This requires two parts:
* Don't bump the RX sequence number, same as above; and
* If frames go into the reordering buffer, they need to be added into the slot
as a set of frames rather than a single frame, so once a new seqno shows up
this slot can be marked as "full" and we can move on.
This patch does the first. The latter requires that I find and commit
work to change rxa_m from an mbuf to an mbufq and the nhandle A-MSDU
there. But, the first is enough to allow the normal case (ie, no or not
a lot of A-MPDU RX reordering) to work.
This allows the athp driver (QCA9880) throughput to go from VERY low
(like 5mbit TCP, 1/3-1/4 expected UDP throughput) to ~ 250mbit TCP
and > 300mbit UDP on a VHT/40 channel. TCP sucks because, well, it
shows up as MASSIVE packet loss when all but one frame in a decap'ed
A-MSDU stream is dropped. Le whoops.
Now, where'd I put that laptop with the patch for rxa_m mbufq that
I wrote like in 2017...
Tested:
* AR9380, STA/AP mode (a big no-op, no A-MSDU hardware decap);
* if_run (RT3593), STA DWDS mode (A-MPDU / A-MSDU receive, but again
no A-MSDU hardware decap);
* QCA9880, STA/AP mode (which is doing hardware A-MPDU/A-MSDU decap,
but no A-MPDU reordering in the firmware.)
This is hopefully a big no-op unless you're running some extra
patches to flip on A-MSDU options in a driver.
802.11n supports sending A-MSDU in A-MPDU. That lets you do things
like pack small frames into an A-MSDU and stuff /those/ into an A-MPDU.
It allows for much more efficient airtime because you're not
wasting time sending small frames - which is still a problem when
doing A-MPDU as there's still per-frame overhead and minimum A-MPDU
density requirements.
It, however, is optional for 802.11n. A lot of stuff doesn't advertise
it (but does it, just wait!); and I know that ath10k does it and my
ath(4) driver work supports it.
Now, 802.11ac makes A-MSDU in A-MPDU something that can happen more
frequently, because even though you can send very large A-MPDUs
(like 1 megabyte and larger) you still have the small frame problem.
So, 802.11ac NICs like ath10k and iwm will support A-MSDU in A-MPDU
out of the box if it's enabled - and you can negotiate it.
So, let's lay down the ground work to enable A-MSDU in A-MPDU.
This will allow hardware like iwn(4) and ath(4) which supports
software A-MSDU but hardware A-MPDU to be more efficient.
Drivers that support A-MSDU in A-MPDU will set TX/RX htcap flags.
Note this is separate from the software A-MSDU encap path; /that/
dictates whether net80211 is doing A-MSDU encapsulation or not.
These HTC flags control negotiation, NOT encapsulation.
Once this negotiation and driver bits are done, hardware like
rtwn(4), run(4), and others will be able to use A-MSDU even without
A-MPDU working; right now FF and A-MSDU aren't even attempted
if you're an 11n node. It's a small hold-over from the initial
A-MPDU work and I know how to fix it, but to flip it on properly
I need to be able to negotiate or ignore A-MSDU in A-MPDU.
Oh and the fun part - some 11ac APs I've tested will quite happily
decap A-MSDU in A-MPDU even though they don't negotiate it when
doing 802.11n. So hey, I know it works - I just want to properly
handle things. :-)
Tested:
* AR9380, STA/AP mode
net80211 currently doesn't negotiate A-MSDU in A-MPDU during ADDBA.
I've added the field in net80211 and this commit:
* Prints out the ADDBA field value during ADDBA;
* Adds some comments around where I need to follow up with some
negotiation logic.
Right now we don't have a driver flag anywhere which controls
whether A-MSDU in A-MPDU is allowed. I know it works (I have it
manually turned on at home on a couple test APs, heh!) but
I can't flip it on until we can negotiate it.
Tested:
* AR9380, STA/AP mode, printing out ADDBA requests
r357614 added CTLFLAG_NEEDGIANT to make it easier to find nodes that are
still not MPSAFE (or already are but aren’t properly marked).
Use it in preparation for a general review of all nodes.
This is non-functional change that adds annotations to SYSCTL_NODE and
SYSCTL_PROC nodes using one of the soon-to-be-required flags.
Mark all low hanging fruits as MPSAFE.
Reviewed by: markj
Approved by: kib (mentor, blanket)
Differential Revision: https://reviews.freebsd.org/D23626
Update node flags when driver supports SMPS, not when it is disabled or
in dynamic mode ((iv_htcaps & HTCAP_SMPS) != 0).
Checked with RTL8188EE (1T1R), STA mode - 'smps' word should disappear
from 'ifconfig wlan0' output.
MFC after: 2 weeks
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.
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!
This is in preparation for A-MSDU decap in A-MPDU support.
* refactor out the code to purge a single reorder slot into ampdu_rx_purge_slot().
* refactor out the code to add a frame to the given reorder slot
to ampdu_rx_add_slot().
This should be a big no-op as far as current code is concerned.
Tested:
* QCA9880v2, STA mode (11ac)
* iwn(4), STA mode (11n)
Reviewed by: avos
Differential Revision: https://reviews.freebsd.org/D10328
The "dispatch a frame from the A-MPDU reorder buffer" code is essentially
duplicated in a couple of places. This refactors it out into a single
place in preparation for A-MSDU in A-MPDU offload support, where multiple
A-MSDUs are decap'ed in hardware to 802.3/802.11 frames, but with the
same sequence number.
Reviewed by: avos
Differential Revision: https://reviews.freebsd.org/D10240
ucast/mcast/mgmt HT rate.
- Init global ieee80211_htrateset only once; neither ic_htcaps nor
ic_txstream is changed when device is attached;
- Move global ieee80211_htrateset structure to ieee80211com;
there was a possible data race when more than 1 wireless device is
used simultaneously;
- Discard unsupported rates in ieee80211_ioctl_settxparams(); otherwise,
an unsupported value may break connectivity (actually,
'ifconfig wlan0 ucastrate 8' for RTL8188EU results in immediate
disconnect + infinite 'device timeout's after it).
Tested with:
- Intel 6205, STA mode.
- RTL8821AU, STA mode.
Reviewed by: adrian
Differential Revision: https://reviews.freebsd.org/D9871
After some digging and looking at packet traces, it looks like the
sequence number allocation being done by net80211 doesn't meet
802.11-2012.
Specifically, group addressed frames (broadcast, multicast) have
sequence numbers allocated from a separate pool, even if they're
QoS frames.
This patch starts to try and address this, both on transmit and
receive.
* When receiving, don't throw away multicast frames for now.
It's sub-optimal, but until we correctly track group addressed
frames via another TID counter, this is the best we can do.
* When doing A-MPDU checks, don't include group addressed frames
in the sequence number checks.
* When transmitting, don't allocate group frame sequence numbers
from the TID, instead use the NONQOS TID for allocation.
This may fix iwn(4) 11n because I /think/ this was one of the
handful of places where ni_txseqs[] was being assigned /outside/
of the driver itself.
This however doesn't completely fix things - notably the way that
TID assignment versus WME assignment for driver hardware queues
will mess up multicast ordering. For example, if all multicast
QoS frames come from one sequence number space but they're
expected to obey the QoS value assigned, they'll end up in
different queues in the hardware and go out in different
orders.
I can't fix that right now and indeed fixing it will require some
pretty heavy lifting of both the WME<->TID QoS assignment, as well
as figuring out what the correct way for drivers to behave.
For example, both iwn(4) and ath(4) shouldn't put QoS multicast
traffic into the same output queue as aggregate traffic, because
the sequence numbers are all wrong. So perhaps the correct thing
to do there is ignore the WME/TID for QoS traffic and map it all
to the best effort queue or something, and ensure it doesn't
muck up the TID/blockack window tracking. However, I'm /pretty/
sure that is still going to happen.
.. maybe I should disable multicast QoS frames in general as well,
but I don't know what that'll do for whatever the current state
of 802.11s mesh support is.
Tested:
* STA mode, ath10k NIC
* AP mode, AR9344/AR9580 AP
* iperf tcp/udp tests with concurrent multicast QoS traffic.
Before this, iperfs would fail pretty quickly because the sending
AP would start sending out QoS multicast frames that would be
out of order from the rest of the TID traffic, causing the blockack
window to get way, way out of sync.
This now doesn't occur.
TODO:
* verify which QoS frames SHOULD be tagged as M_AMPDU_MPDU.
For example, QoS NULL frames shouldn't be tagged!
Reviewed by: avos
Differential Revision: https://reviews.freebsd.org/D9357
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. :/
Unfortunately (sigh) some firmware doesn't provide the RX BA starting point,
so we need to cope and set a "close enough" sequence number so we (hopefully!)
don't discard frames as duplicates.
Tested:
* QCA9880v2, athp driver (under development), STA mode
IBSS negotiation is a subset of the STA/AP negotiation. We always have a
current channel, so base the HT capabilities on the current channel.
This is then put into IBSS probe requests to inform peers of our
11n capabilities.
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.
This is in preparation for exposing configuring STBC flags up to ifconfig
so STBC TX/RX can be configured at runtime.
* Set the FHT_STBC flags for TX/RX if the HT capabilitiex exist
* Clear the RX STBC HT capability flag when creating a HTCAP IE, so
we only announce it if it's configured in the FHT flags.
Tested:
* AR9331 (carambola2), AP/STA modes
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
I was seeing the stack constantly attempt to renegotiate A-MPDU TX
even after 3 failures. My hunch is that the direct ticks comparison
is failing around the ticks wrap-around point.
This failure shouldn't /really/ happen normally, but it turns out being
the IBSS master node on FreeBSD doesn't quite setup 11n right, so
negotiating A-MPDU TX fails.
It's 2016 and vendors (including us!) still have 802.11n TX/RX sequence
handling bugs. It's suboptimal, but I'd rather see us default to handling
things in a sensible way.
So, just delete the #ifdef'ed code for now. I'll leave the option in
so it doesn't break existing configurations.
This all started because I've started getting reports about urtwn not
working after I enabled 802.11n support, and it's because the ARM kernel
configs don't include A-MPDU RX aging.
This makes it easier to track which node is having what done do it
during normal use.
This is likely the eighth time I've done this since I started doing
net80211 development, so I think it's about time I just committed it.
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.
I've seen some cases where we get stuck in a loop constantly trying to
negotiate A-MPDU TX which is definitely not supposed to happen.
This will let me see if it's something funky with the retry count or
not.
in the superg fast-frames code.
This harks back to an earlier commit (r280349) where I found that
initialising the pps code with ticks=0 would cause hilariously bad
hz ticks wraparound failures, leading to never actually aggregating
traffic. This is still true for the superg path and so I have to
do the same thing there.
This is a big no-op; a subsequent commit will flip this on so it
works with the fast-frames transmit path.
Tested:
* AR9170, otus(4) - STA mode, 11bg operation
* AR9331, AP mode
Some fullmac devices may rely on the stack starting it but not doing it.
Whilst here, remove a duplicate LE_* macro definition, thanks to
Andriy Voskoboinyk <s3erios@gmail.com>.
for re-ordering.
Devices like if_rsu don't pass through action/management frames but do send
firmware commands to inform us of things. One of those notifications is
the RX A-MPDU negotiated parameters.
years for head. However, it is continuously misused as the mpsafe argument
for callout_init(9). Deprecate the flag and clean up callout_init() calls
to make them more consistent.
Differential Revision: https://reviews.freebsd.org/D2613
Reviewed by: jhb
MFC after: 2 weeks
to us. Instead, advertise what we can do based on what the AP says and what
we're capped at by the VAP settings.
For non-STA modes we still advertise what our VAP settings are.
It may be that I've over-complicated this and instead of capping things
we can just always announce what we're capable of. But this should at least
stop the blatantly wrong handling of A-MPDU parameters.
(I'll happily simplify things if someone can dig up a replacement, better
compliant behaviour.)
PR: kern/176201
There's a bug in the ticks handling where when initialised at '0', once
the ticks counter wrapped the comparison math would never trigger.
The pps calculation would never happen, and thus aggregation was never
enabled.
It manifests itself as "oh you only get 11n transmit aggregation for the
first 10 minutes of uptime."
I'm sure there are other ticks related issues lurking in net80211.
Tested:
* ath / iwn, both with 'wlandebug +11n' and a little bit of iperf to
kick off the transmit A-MPDU negotiation once the pps gets high enough.
- Wrong integer type was specified.
- Wrong or missing "access" specifier. The "access" specifier
sometimes included the SYSCTL type, which it should not, except for
procedural SYSCTL nodes.
- Logical OR where binary OR was expected.
- Properly assert the "access" argument passed to all SYSCTL macros,
using the CTASSERT macro. This applies to both static- and dynamically
created SYSCTLs.
- Properly assert the the data type for both static and dynamic
SYSCTLs. In the case of static SYSCTLs we only assert that the data
pointed to by the SYSCTL data pointer has the correct size, hence
there is no easy way to assert types in the C language outside a
C-function.
- Rewrote some code which doesn't pass a constant "access" specifier
when creating dynamic SYSCTL nodes, which is now a requirement.
- Updated "EXAMPLES" section in SYSCTL manual page.
MFC after: 3 days
Sponsored by: Mellanox Technologies
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.
before using said node.
The "blessed" way here is to take a node reference before referencing
anything inside the node, otherwise the node can be freed between
the time the pointer is copied/dereferenced and the time the node contents
are used.
This mirrors fixes that I've done elsewhere in the net80211/driver
stack.
PR: kern/178470
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.
