This makes amrr_node_stats() cleaner and allows the rate printing to be
reusable.
Submitted by: Neel Chauhan <neel at neelc.org>
Reviewed by: adrian
Differential Revision: https://reviews.freebsd.org/D22318
misunderstanding that the function does not work additive
when repeatedly called for diffferent bands.
Reviewed by: avos (a few months ago)
MFC after: 2 weeks
- Perform ifp mismatch checks (to determine if a send tag is allocated
for a different ifp than the one the packet is being output on), in
ip_output() and ip6_output(). This avoids sending packets with send
tags to ifnet drivers that don't support send tags.
Since we are now checking for ifp mismatches before invoking
if_output, we can now try to allocate a new tag before invoking
if_output sending the original packet on the new tag if allocation
succeeds.
To avoid code duplication for the fragment and unfragmented cases,
add ip_output_send() and ip6_output_send() as wrappers around
if_output and nd6_output_ifp, respectively. All of the logic for
setting send tags and dealing with send tag-related errors is done
in these wrapper functions.
For pseudo interfaces that wrap other network interfaces (vlan and
lagg), wrapper send tags are now allocated so that ip*_output see
the wrapper ifp as the ifp in the send tag. The if_transmit
routines rewrite the send tags after performing an ifp mismatch
check. If an ifp mismatch is detected, the transmit routines fail
with EAGAIN.
- To provide clearer life cycle management of send tags, especially
in the presence of vlan and lagg wrapper tags, add a reference count
to send tags managed via m_snd_tag_ref() and m_snd_tag_rele().
Provide a helper function (m_snd_tag_init()) for use by drivers
supporting send tags. m_snd_tag_init() takes care of the if_ref
on the ifp meaning that code alloating send tags via if_snd_tag_alloc
no longer has to manage that manually. Similarly, m_snd_tag_rele
drops the refcount on the ifp after invoking if_snd_tag_free when
the last reference to a send tag is dropped.
This also closes use after free races if there are pending packets in
driver tx rings after the socket is closed (e.g. from tcpdrop).
In order for m_free to work reliably, add a new CSUM_SND_TAG flag in
csum_flags to indicate 'snd_tag' is set (rather than 'rcvif').
Drivers now also check this flag instead of checking snd_tag against
NULL. This avoids false positive matches when a forwarded packet
has a non-NULL rcvif that was treated as a send tag.
- cxgbe was relying on snd_tag_free being called when the inp was
detached so that it could kick the firmware to flush any pending
work on the flow. This is because the driver doesn't require ACK
messages from the firmware for every request, but instead does a
kind of manual interrupt coalescing by only setting a flag to
request a completion on a subset of requests. If all of the
in-flight requests don't have the flag when the tag is detached from
the inp, the flow might never return the credits. The current
snd_tag_free command issues a flush command to force the credits to
return. However, the credit return is what also frees the mbufs,
and since those mbufs now hold references on the tag, this meant
that snd_tag_free would never be called.
To fix, explicitly drop the mbuf's reference on the snd tag when the
mbuf is queued in the firmware work queue. This means that once the
inp's reference on the tag goes away and all in-flight mbufs have
been queued to the firmware, tag's refcount will drop to zero and
snd_tag_free will kick in and send the flush request. Note that we
need to avoid doing this in the middle of ethofld_tx(), so the
driver grabs a temporary reference on the tag around that loop to
defer the free to the end of the function in case it sends the last
mbuf to the queue after the inp has dropped its reference on the
tag.
- mlx5 preallocates send tags and was using the ifp pointer even when
the send tag wasn't in use. Explicitly use the ifp from other data
structures instead.
- Sprinkle some assertions in various places to assert that received
packets don't have a send tag, and that other places that overwrite
rcvif (e.g. 802.11 transmit) don't clobber a send tag pointer.
Reviewed by: gallatin, hselasky, rgrimes, ae
Sponsored by: Netflix
Differential Revision: https://reviews.freebsd.org/D20117
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
That should shorten 'ifconfig <wlan> list txparam' output since
unsupported modes will not be shown.
Checked with RTL8188EE, STA mode.
MFC after: 2 weeks
Do not try to clear 'basic rate' bit from roamRate; it cannot be here and,
actually, this operation clears 'MCS rate' bit instead, breaking comparison
for 11n / 11ac modes.
Tested with RTL8188CUS, HOSTAP mode + RTL8821AU, STA mode.
MFC after: 3 days
ifconfig(8) prints per-mode parameters if they are non-zero; since
we have 13 possible modes with 3...5 typically supported this change
should greatly reduce amount of information for 'ifconfig <wlan> list roam'
command.
While here ensure that sta_roam_check() will not use roaming parameters
for unsupported modes (it should not).
This change effectively reverts r188776.
MFC after: 2 weeks
Wrap ieee80211_add_channel_list_2ghz into another function
which supplies default (1-14) channel list to it and drop
its copies from drivers.
Checked with RTL8188EE, country US / JP / KR / UA.
MFC after: 2 weeks
Replace in-place implementation with system-wide one; since it
guarantees non-zero result drop all less-than-one checks from
drivers and net80211.
MFC after: 2 weeks
There is may be only 11b channel (since chanflags[] table
maps MODE_AUTO to the corresponding 11b channel flags).
Checked with RTL8812AU, STA mode.
MFC after: 5 days
Change the way how channel list mode <-> desired mode match is done:
- Match channel list mode for next non-auto desired modes:
* 11b: 11g, 11ng, 11acg;
* 11a: 11na, 11ac
- Add pre-defined channels only when one of the next conditions met:
* the desired channel mode is 'auto' or
* the desired channel and selected channel list modes are exactly
the same or
* the previous rule (11g / 11n / 11ac promotion) applies.
Before r275875 construction work properly for all except
11ng / 11na / 11acg / 11ac modes - these were broken at all
(i.e., the scan list was empty); after r275875 all checks were removed,
so scan table was populated by all device-compatible channels
(desired mode was ignored).
For example, if I will set 'ifconfig wlan0 mode 11ng' for RTL8821AU:
- pre-r275875: nothing, scan will not work;
- after r275875: both 11ng and 11na bands were scanned; also, since 11b
channel list was used, 14th channel was scanned too.
- after this change: only 11ng - 1-13 channels - are used for scanning.
Tested with:
* RTL8188EE, STA mode.
* RTL8821AU, STA mode.
MFC after: 5 days
Since r287197 ieee80211com is a part of drivers softc; as a result,
after detach all pointers to it (iv_ic, ni_ic) are invalid. Most
possible users (tasks, interrupt handlers) are blocked / removed
when device is stopped; however, ioctl handlers were not tracked
and may crash if ieee80211com structure is accessed.
Since ieee80211com pointer access from ieee80211vap structure is not
protected by lock (constant after interface creation) and used in
many other places just use reference counting for ioctl handlers;
on detach set 'detached' flag and wait until reference counter goes to 0.
For HEAD ieee80211vap size was changed (__FreeBSD_version bumped);
however, in stable branches I'm going to split / reuse the last
iv_spare field for KBI stability.
Tested with:
- rsu(4), SIOCSIFCAP (-rxcsum) ioctl;
- rtwn_pci(4), SIOCG80211 / IEEE80211_IOC_HTPROTMODE ioctl.
MFC after: 1 week
For most wireless drivers Rx mbuf is allocated as one
contiguous chunk; only few are using chains for allocations -
but even then at least MCLBYTES (minus Rx descriptor size) is
available in the first mbuf.
In addition to the above, m_pullup was never called here - otherwise,
reallocation will break post-crypto_decap logic (ieee80211_decap,
ieee80211_deliver_data...), so just remove it; length check is left
in case if some truncated frame appears here.
PR: 234241
MFC after: 1 week
There may be various side effects (device timeout, firmware and / or
kernel panic) when an invalid (or inapplicable - e.g., an MCS rate
for 11g-only device) is set; check rates before sending the frame to
the driver.
How-to-reproduce:
Set an MCS (real or bogus - with 0x80 bit set) rate in ibp_rate0 field
for any device that uses ieee80211_isratevalid() for rate checks -
rum(4), run(4), ural(4), bwi(4) or ral(4); if kernel is compiled
with INVARIANTS the check will result in "rate %d is basic/mcs?" panic.
Tested with WUSB54GC (rum(4)), AP mode.
MFC after: 1 week
Check if rate control structures were allocated before trying to
access them in various places; this was possible before on
allocation failure (unlikely), but was revealed after r342211
where allocation was deferred.
In case if driver uses wlan_amrr(4) and it is loaded it
is possible to reproduce the panic via
sysctl net.wlan.<number>.rate_stats
(for wlan0 the number will be 0).
Tested with: RTL8188EE, AP mode + RTL8188CUS, STA mode.
MFC after: 3 days
if_dead() is called during device detach - check if interface is
still exists before trying to refresh vap MAC address
(IF_LLADDR will trigger page fault otherwise).
MFC after: 5 days
ieee80211_alloc_node() does not initialize rateset tables; that's not
expected by rate control modules and will result in array access at
index -1 - where ni_essid[] array is located (zeroed at allocation, so
there are no user-visible consequences).
Just delay rate control initialization to the moment, when rateset
tables are initiaziled; nothing will use rates here anyway.
MFC after: 4 days
The comment above ieee80211_ageq_cleanup specifically notes that the queue
is assumed to be empty, and in order to make it so, ieee80211_ageq_drain
must be used.
Submitted by: Augustin Cavalier <waddlesplash@gmail.com>
Obtained from: Haiku (dffc3e235360cd7b71261239ee8507b7d62a1471)
MFC after: 1 week
As the comment says, ifdetach might be called during the course of driver
detach if initialization failed. This shouldn't be a total failure, though,
we just have nothing to do there.
This has been modified slightly from Augustin's original commit to move the
bail-out slightly earlier since the ic wouldn't have been added to the
ic list in the first place, and a comment has been added describing when
this might be an issue.
Submitted by: Augustin Cavalier <waddlesplash@gmail.com>
Obtained from: Haiku (e6f6c1b4633532a8ad37c803dc7c65601e5b24ba)
This fixes 32-bit compat (no ioctl command defintions are required
as struct ifreq is the same size). This is believed to be sufficent to
fully support ifconfig on 32-bit systems.
Reviewed by: kib
Obtained from: CheriBSD
MFC after: 1 week
Relnotes: yes
Sponsored by: DARPA, AFRL
Differential Revision: https://reviews.freebsd.org/D14900
Move copy-pasted code for RTS/CTS frame allocation into net80211.
While here, add stat / debug message for allocation failures
(copied from run(4)) + return error here in bwn(4).
Reviewed by: adrian
Differential Revision: https://reviews.freebsd.org/D14628
- Add some basic checks for i_fc* bits (ToDS, FromDS, MoreFrag, Protected);
those are used / checked across various places in Tx path.
- Mark injected 802.11 frame as encapsulated (just as it should be).
- Classify 802.11 frame in a proper way (extract ether_type from LLC header
for Data frames, use AC_BE queue for others (NoData / Management / Control).
- Subtract header length from tx_bytes statistics (so it will correspond
to the comment).
Was checked with RTL8188EU (AP) + Intel 6205 (STA).
Reviewed by: adrian
Differential Revision: https://reviews.freebsd.org/D13161
Select proper mode when node can do VHT.
Currently there are no drivers with VHT support in the tree,
so this should be noop.
Reviewed by: adrian
Differential Revision: https://reviews.freebsd.org/D9806
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.
The duplicate detection code currently expects A-MSDU frames to be encaped -
they're decap'ed /after/ duplicate detection.
However for ath10k (and iwm hardware later on) the firmware supports
doing A-MSDU decap in hardware - which shows up as multiple frames with
the same sequence number and IV.
This is the first part of decap handling - if we see a stretch of A-MSDU
frames from the driver with the MORE bit set, then don't treat them
as duplicates.
This isn't 100% complete as crypto sequence number handling and "A-MSDU in
A-MPDU" needs handling, but it's a start.
This should be a glorified no-op for everyone. Please tell me if it isn't.
Fragment number field (part of i_seq) is used for AAD calculation;
as a result, without this patch every driver without h/w crypto support
need to clear it before ieee80211_crypto_encap().
Also fixes rtwn(4) A-MPDU Tx with dev.rtwn.%d.hwcrypto tunable
set to 0 (h/w crypto is disabled).
Tested with:
* Intel 6205, STA mode.
* RTL8188EU, STA mode.
Differential Revision: https://reviews.freebsd.org/D10753
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!
For now there isn't any per-VAP WME state. The eventual aim is to migrate
the driver direct use of WME parameters over to use these methods as
appropriate (global for most devices, per-VAP for firmware NICs that support
it) in preparation for actual per-VAP WME (and other thing) state change
support.
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
If this is the last running vap wait until device will be powered off
(fixes panic when 'ifconfig wlan0 destroy' is executed for running iwn(4)
interface).
Tested with:
- Intel 6205, STA mode.
- RTL8188EU, STA / IBSS modes.
- RTL8821AU, STA / HOSTAP modes.
This should reduce overhead for aggregates (since every second frame
clears the queue and reschedules the task there is no need to cancel
the callout here; let it just run once at the end - even if queue is
empty).
Reported by: adrian
This should allow to drop 'ieee80211_ff_[age/flush]' calls from drivers
(an additional call can be made from ieee80211_tx_complete()
for non-default ieee80211_ffagemax values to prevent stalls -
but it will require an additional counter for transmitted frames).
Tested with RTL8821AU, STA mode (A-MSDU part only).
Reviewed by: adrian
Differential Revision: https://reviews.freebsd.org/D9984
As part of (eventual) p2p/tdls/multi-STA support, a lot of global configuration
parameters (WME, ERP (slot, preamble), channel width, HT protmode, etc are the
biggest offenders) should be per-VAP.
For multi-BSS VAP operation they may be linked, but for p2p/TDLS
operation that can be off-channel they can definitely be different
(think: 2GHz STA, 5GHz p2p.)
The global configuration view of these is mostly a "configure the current
non-smart-firmware NIC" view. This should be split up into per-VAP state,
then a global non-smart-firmware-NIC management layer to handle channel
changes and such in software.
This is step one in a loooong road for this. It should be a big non-functional
change for everyone.
* create a per-VAP WME update call.
* call it if its set, and call the global callback if it isn't
This still uses global WME state - it's just preparation for a future change
which will make the WME state per-VAP and fall through to a shared WME
configuration for hostap operation.
Note: this requires a full kernel recompile; the internal net80211 ABI has changed.
Reviewed by: avos
Differential Revision: https://reviews.freebsd.org/D9986
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
* Migrate the rx_params stuff out from ieee80211_freebsd.h where it doesn't belong -
this isn't freebsd specific anymore.
* Don't use a hard-coded number of chains in the ioctl header; now we can shuffle
MAX_CHAINS around so it can be used in the right spot.
* Extend the signal/noisefloor levels in the mimo stats struct to userland to include
the signal and noisefloor levels for each 20MHz slice of a 160MHz channel.
* Bump the number of EVM pilots in preparation for 4x4 and 160MHz channels.
Tested:
* ath(4), STA mode
* iwn(4), STA mode
* local ath10k port, STA mode
TODO:
* 11ax chips will come with 5GHz 8x8 hardware for lots of MU-MIMO - I'll re-bump it
at that point.
Note:
* This breaks the driver and ifconfig ABI; please recompile the kernel,
ifconfig and wpa_supplicant/hostapd.
* 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.
The quiet time counter update is happening each time the IE is added,
which also means it happens for each quiet time IE addition to the probe
response.
Only update the countdown if we request ie (ie, beacon updates.)
Flags
- IEEE80211_F_ASCAN
- IEEE80211_F_SIBSS
- IEEE80211_F_IBSSON
are not used since r170530 (old WI compatibility ioctls removal)
and r178354 (removed from other places).
IEEE80211_F_TXPOW_FIXED was never utilized; initially added with
IEEE80211_F_TXPOW_AUTO / IEEE80211_F_TXPOW_OFF flags,
which were replaced with IEEE80211_C_TXPMGT capability check in r138568.
Reviewed by: adrian
Differential Revision: https://reviews.freebsd.org/D9369
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
* allocate an ext bit for fragment offload. Some NICs (like the ath10k
hardware in native wifi or 802.3 mode) support doing packet fragmentation
in firmware/hardware, so we don't have to do it here.
* allocate an ext bit for VHT and start using it.
I added IEEE80211_TX_LOCK() a few years ago because there were races between
seqno allocation, driver queuing and crypto IV allocation. This meant that
they'd appear out of sequence and the receiver would drop them, leading to
terrible performance or flat out traffic hangs.
This flag should be set by drivers that do their own sequence number
allocation for all frames it needs to happen for, including beacon frames.
Eventually this should lead to the driver taking care of locking for
allocating seqno and other traffic-triggered events (eg addba setup.)
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. :/
This sets up:
* vht capabilities in vaps;
* calls vht_announce to announce VHT capabilities if any;
* sets up vht20, vht40 and vht80 channels, assuming the regulatory code
does the right thing with 80MHz available ranges;
* adds support to the ieee80211_add_channel_list_5ghz() code to populate
VHT channels, as this is the API my ath10k driver is using;
* add support for the freq1/freq2 field population and lookup that
VHT channels require.
The VHT80 code assumes that the regulatory domain already has limited VHT80
bands to, well, 80MHz wide chunks.
This is needed for two reasons:
* Drivers will need to know what the negotiated set of VHT capabilities
and rates are in order to configure (and reconfigure for opmode/chanwidth
changes) how to speak to a given peer; and
* Because some vendors are "special", we should be careful in what we announce
to them during peer association.
This isn't the complete solution, as I still need to make sure that when
sending out probe requests before we know what we want, we don't limit
the capabilities being announced. This is important for IBSS/mesh work
later on as probe request/response exchanges are the first hint at what
a peer supports. I'll look at adding that to the API soon.
This is a skeleton set based on ieee80211_ht.c. It implements some IE
parsing, some basic unfinished negotiation, and channel promotion/demotion.
However, by itself it's not enough to do VHT - notably, the actual
channel promotion for STA mode at least is done in ieee80211_ht.c as
part of htinfo_update_chw(). I was .. quite amused when I found that
out.
I'm checking this in so others can see progress rather than one huge
commit when VHT is "done" (which will likely be quite a while.)
* Add the VHT capability element to the driver capabilities so ifconfig
can see if VHT is available
* Add ioctl plumbing for enabling/disabling VHT and each of the VHT
widths.
Note: this DOES change the ABI (the driver caps ioctl struct size, sigh)
so this will require a recompile of at least ifconfig.
In preparation for VHT station support, we need to store VHT IEs when
scanning so we can choose to upgrade to VHT.
This doesn't change the ABI - it just steals spare[] entries.
The VHT operational element (VHTOPMODE) isn't a uint32_t - it's
the MCS sets, freq1/freq2 parameters and channel width.
So, store the channel width too in lieu of just storing the
IE struct.
This changes the VHT parameter layout in ieee80211_node but it
doesn't change ABI at all.
The 11n code uses these bits for both configuration /and/ controlling
the channel width on softmac chips - it uses it to find the widest
width for all VAPs (eg a HT20 vap and a HT40 vap) to know what to
configure the ic_curchan.
For fullmac devices it isn't /as/ important, as each virtual device
exposed by the firmware will likely have its own configuration and the
firmware figures out what to do to enable it.
These came from Linux mac80211 headers and are configuration bits, not
VHTOPMODE field parameters.
Whilst here, add the field names for the VHTCAP bits.
Tested:
* ath10k, 11ac STA mode
* rename the ieee80211com field for vht mcsinfo to be ic_, not iv;
* add a vht config field, stealing from the spares I left there.
This doesn't change the ABI.
The ath10k firmware supports hardware WEP offload, and in native wifi mode
(or 802.3 ethernet mode, for that matter) the WEP key isn't actually included
in the TX payload from net80211. Instead, a separate firmware command is issued
that sets the default TX key to be the specified key.
However, net80211 doesn't at all inform the driver layer that this is
occuring - it just "expects" to be inserting WEP header information
when doing WEP TX, even with hardware encryption.
So, to better support the newer world order, turn the default TX key assignment
into a VAP method that can be overridden by the driver and ensure its wrapped
in a crypto begin/end set. That way it should be correctly atomic from the
point of view of keychanges (as long as the driver does the right thing.)
It'd be nice if we passed through to the key_set call a flag that says
"also make this the default key" - that's captured here by calling the
deftxkey method after the key_set method. Maybe I can do that later.
Note: this is a net80211 ABI change, and will require a kernel+modules
recompile. Happy Holidays, etc.
Tested:
* ath10k driver port
* rtwn_usb, WEP station
This is a work in progress and some of this stuff may change;
but hopefully I'm laying down enough stuff and space in fields
to allow it to grow without another major recompile.
We'll see!
* Add a net80211 PHY type for VHT 2G and VHT 5G.
Note - yes, VHT is supposed to be for 5GHZ, however some vendors
(*cough* most of them) support some subset of VHT rate support
in 2GHz. No - not 80MHz wide channels, but at least some MCS8-9
support, maybe some beamforming, and maybe some longer A-MPDU
aggregates. I don't want to even think about MU-MIMO on 2GHz.
* Add an ifmedia placeholder type for VHT rates.
* Add channel flags for VHT, VHT20/40U/40D/80/80+80/160
* Add channel macros for the above
* Add ieee80211_channel fields for the VHT information and flags,
along with some padding (so this struct definitely grows.)
* Add a phy type flag for VHT - 'v'
* Bump the number of channels to a much higher amount - until we get
something like the linux mac80211 chanctx abstraction (where the
stack provides a current channel configuration via callbacks,
versus the driver ever checking ic->ic_curchan or similar) we'll
have to populate VHT+HT combinations.
Eg, there'll likely be a full set of duplicate VHT20/40 channels to match
HT channels. There will also be a full set of duplicate VHT80 channels -
note that for VHT80, its assumed you're doing VHT40 as a base, so we
don't need a duplicate of VHT80 + 20MHz only primary channels, only
a duplicate of all the VHT40 combinations.
I don't want to think about VHT80+80 or VHT160 for now - and I won't,
as the current device I'm doing 11ac bringup on (QCA9880) only does
VHT80.
I'll likely revisit the channel configuration and scanning related
stuff after I get VHT20/40 up.
* Add vht flags and the basic MCS rate setup to ieee80211com, ieee80211vap
and ieee80211_node in preparation for 11ac configuration.
There is zero code that uses this right now.
* Whilst here, add some more placeholders in case I need to extend
out things by some uint32_t flag sized fields. Hopefully I won't!
What I haven't yet done:
* any of the code that uses this
* any of the beamforming related fields
* any of the MU-MIMO fields required for STA/AP operation
* any of the IE fields in beacon frame / probe request/response handling
and the calculations required for shifting beacon contents around
when the TIM grows/shrinks
This will require a full rebuild of net80211 related programs -
ifconfig, hostapd, wpa_supplicant.
