Make ieee80211_ref_node() a macro so we can pass __func__, __LINE__
in for IEEE80211_DEBUG_REFCNT as we do for other refcount related
functions. Add the appropriate IEEE80211_DPRINTF() call to the
_ieee80211_ref_node() implementation to support wlandebug(8) +node
printf style tracing.
As a plus we can now also use Dtrace fbt on the
_ieee80211_{ref,free}_node() implementations with futher logic,
gathering backtraces, etc. more flexibly.
Sponsored by: The FreeBSD Foundation
X-MFC: never
ieee80211_unref_node() was only used in two error cases in
ieee80211_send_nulldata(). There we do not need to guard against
ni pointer reuse after decrementing the refcount of the ni as we
only update the stats and return.
Update the man page and remove the link for the now gone function.
Sponsored by: The FreeBSD Foundation
X-MFC: never
Reviewed by: adrian, emaste
Differential Revision: https://reviews.freebsd.org/D42035
Looking through the allocation/free and reference cycle of nodes we have
a few (publicly) (almost) unused macros and functions.
Start making them private and reducing the amount of entry paths to the
same/similar functionality.
First is to make ieee80211_alloc_node() static as it is nowhere used
in the tree outside this file.
Sponsored by: The FreeBSD Foundation
X-MFC: no
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
Remove the KPI/KBI changes from ieee80211_node.h and always use the
macros to pass in __func__ and __LINE__ to the functions.
The actual implementations are prefixed by "_" rather than suffixed
by "_debug" as they no longer are "debug"-specific.
Some of the select functions were not actually using the passed in
func, line options; however they are calling other functions which
use them. Directly call the internal implementation in those cases
passing the arguments on.
Use a file-local __debrefcnt_used define to mark the arguments __unused
in cases when we compile without IEEE80211_DEBUG_REFCNT and hope the
toolchain is intelligent enough to not pass them at all in those cases.
Also _ieee80211_free_node() now has a conflict so make the previous
_ieee80211_free_node() the new __ieee80211_free_node().
Add IEEE80211_DEBUG_REFCNT to the NOTES file on amd64 to keep exercising
the option.
Sponsored by: The FreeBSD Foundation
X-MFC: never
Discussed on: freebsd-wireless
Reviewed by: adrian
Differential Revision: https://reviews.freebsd.org/D37529
Add a void *ni_drv_data field to struct ieee80211_node that drivers
can use to backtrack to their internal state from a net80211 node.
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
X-Differential Revision: https://reviews.freebsd.org/D30654 (abandoned)
Sort a few VHT160 and 80+80 lines, update some comments, and remove
a superfluous ','.
No functional changes intended.
MFC after: 1 week
Sponsored by: The FreeBSD Foundation
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
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.
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.
* 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 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.
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.
This just stores pointers to the IE; it doesn't yet parse anything.
Note: it blows out the size of ieee80211_node, so this will require
ye olde kernel/modules recompile.
- Add a counter into 'struct ieee80211_node_table' to save current number
of allocated nodes.
(allows to remove array overflow checking in ieee80211_iterate_nodes()).
- Add ieee80211_iterate_nodes_vap() function; unlike non-vap version,
it iterates on nodes for specified vap only.
In addition to the above:
- Remove ieee80211_iterate_nt(); it is not used by drivers / net80211
outside ieee80211_iterate_nodes() function + cannot be separated due
to structural changes in code.
Since size of 'struct ieee80211_node_table' (part of ieee80211com,
which is a part of driver's softc) is changed all wireless drivers /
kernel need to be recompiled.
Tested with wpi(4), STA mode.
Reviewed by: adrian
Differential Revision: https://reviews.freebsd.org/D7996
The adhoc probe/beacon input path was creating nodes for all SSIDs.
This wasn't a problem when the NICs were configured to only process
frames for the current BSSID, but that didn't allow IBSS merges.
Once avos and I flipped on "beacons from all BSSIDs" to allow for
correct IBSS merging, we found this interesting behaviour.
This adds a check against the current SSID.
* If there's no VAP SSID, allow anything
* If there's a VAP SSID, check if the incoming frame has a suitable
SSID and if so, allow it.
This prevents nodes being created for other SSIDs in probe and beacon
frames - ie, beacons overlapping IBSSes with different SSIDs, and
probe requests from arbitrary devices.
Tested:
* AR9380, IBSS mode, both local and other IBSSes.
Reviewed by: avos
Differential Revision: https://reviews.freebsd.org/D7959
Drop scan generation number and node table scan lock - the only place
where ni_scangen is checked is in ieee80211_timeout_stations() (and it
is used to prevent duplicate checking of the same node); node scan lock
protects only this variable + node table scan generation number.
This will fix (at least) next LOR (hostap mode):
lock order reversal:
1st 0xc175f84c urtwm0_scan_loc (urtwm0_scan_loc) @ /usr/src/sys/modules/wlan/../../net80211/ieee80211_node.c:2019
2nd 0xc175e018 urtwm0_com_lock (urtwm0_com_lock) @ /usr/src/sys/modules/wlan/../../net80211/ieee80211_node.c:2693
stack backtrace:
#0 0xa070d1c5 at witness_debugger+0x75
#1 0xa070d0f6 at witness_checkorder+0xd46
#2 0xa0694cce at __mtx_lock_flags+0x9e
#3 0xb03ad9ef at ieee80211_node_leave+0x12f
#4 0xb03afd13 at ieee80211_timeout_stations+0x483
#5 0xb03aa1c2 at ieee80211_node_timeout+0x42
#6 0xa06c6fa1 at softclock_call_cc+0x1e1
#7 0xa06c7518 at softclock+0xc8
#8 0xa06789ae at intr_event_execute_handlers+0x8e
#9 0xa0678fa0 at ithread_loop+0x90
#10 0xa0675fbe at fork_exit+0x7e
#11 0xa08af910 at fork_trampoline+0x8
In addition to the above:
* switch to ieee80211_iterate_nodes();
* do not assert that node table lock is held, while calling node_age();
that's not really needed (there are no resources, which can be protected
by this lock) + this fixes LOR/deadlock between ieee80211_timeout_stations()
and ieee80211_set_tim() (easy to reproduce in HOSTAP mode while
sending something to an STA with enabled power management).
Tested:
* (avos) urtwn0, hostap mode
* (adrian) AR9380, STA mode
* (adrian) AR9380, AR9331, AR9580, hostap mode
Notes:
* This changes the net80211 internals, so you have to recompile all of it
and the wifi drivers.
Submitted by: avos
Approved by: re (delphij)
Differential Revision: https://reviews.freebsd.org/D6833
The ath(4) driver now sees beacons and management frames for different
BSSIDs in IBSS mode, which is a problem when you're in a very busy
IBSS environment.
So, expose this function so drivers can use it to check if the current
RX node is actually for a BSS we need to pay attention to or not.
PR: kern/208644
Sponsored by: Eva Automation. Inc.
field and into a separate fast-frames staging pointer in ieee80211_node.
The A-MPDU TX path allows txa_private to be used by drivers. So it will
clash with any attempt to use fast-frames. Now, fast-frames is not really
anything special - it's just a custom ethernet frame type that contains
two MSDUs into one MPDU. So all the NIC has to support doing is transmitting
up to a 4KiB frame with an arbitrary ethertype and bam! Fast-frames.
However, using txa_private means we can /either/ do fast-frames or A-MPDU TX,
so fast frames has been turned off in the Atheros HAL for 11n chipsets.
This is a bit silly - it actually means that 802.11 performance to/from
11abg Atheros chips is actually better than between an 11abg atheros device
and an 11n Atheros device.
So:
* create a new mbuf staging queue for fast frames. It only queues a single
frame in the staging queue (and there's a top-level ic staging queue
used for expiry/tracking) so it's just an mbuf pointer per TID.
* Still use the ampdu TX packet counter to determine whether to do
aggregation or not. It'll double count if we start doing both A-MPDU TX
and fast frames, but that's not all that important right now.
* Initialise the pps tracker so ticks isn't zero. This ensures that
fast-frames actually gets used - without it, the ticks math overflows
and the pps math always sets txa_pps=0. This is the same bug that
plagued A-MPDU TX starting logic.
This actually allows fast-frames transmit to occur between the AR9331
(in 11n HT/20 mode) and AR9170 (if_otus) in 11bg mode.
Now, this is a great big no-op on atheros 11n hardware, so don't worry.
It may mean you start seeing more reliable fast-frames transmission on
11abg hardware which may expose some more amusing bugs.
TODO:
* further testing and debugging of all of this before flipping on
fast-frames in if_ath (for 11n) and if_otus.
This problem happens when using ACL policy to filter mesh STA
but two nodes have different policy. Then one of them will try to
peer all the time. This can also help if for any reason one of the
peering mesh STA have problems sending/receiving peer frames.
* Modified struct ieee80211_node to include two new fields:
+ struct callout ni_mlhtimer /* link mesh backoff timer */
+ uint8_t ni_mlhcnt /* link mesh holding counter */
* Added two new sysctl (check sysctl -d for more info):
+ net.wlan.mesh.backofftimeout=5000
+ net.wlan.mesh.maxholding=2;
* When receiving a beacon and we are in IEEE80211_NODE_MESH_IDLE
check if ni_mlhcnt >= ieee80211_mesh_maxholding, if so do not do anything;
* In mesh_peer_timeout_cb when transitioning from IEEE80211_NODE_MESH_HOLDING
to IEEE80211_NODE_MESH_IDLE increment ni_mlhcnt, and eventually start
ieee80211_mesh_backofftimeout;
Approved by: adrian (mentor)
iterate lock.
This causes LORs and deadlocks as some code paths will have the com lock
held when calling ieee80211_iterate_nodes().
Here, the comlock isn't held during the node table and node iteration
locks; and the callback isn't called with any (extra) lock held.
PR: kern/170098
Submitted by: moonlightakkiy@yahoo.ca
MFC after: 4 weeks
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
This introduces struct ieee80211_rx_stats - which stores the various kinds
of RX statistics which a MIMO and non-MIMO 802.11 device can export.
It also fleshes out the mimo export to userland (node_getmimoinfo()).
It assumes that MIMO radios (for now) export both ctl and ext channels.
Non-11n MIMO radios are possible (and I believe Atheros made at least
one), so if that chipset support is added, extra flags to the
struct ieee80211_rx_stats can be added to extend this support.
Two new input functions have been added - ieee80211_input_mimo() and
ieee80211_input_mimo_all() - which MIMO-aware devices can call with
MIMO specific statistics.
802.11 devices calling the non-MIMO input functions will still function.
This framework allows drivers to abstract the rate control algorithm and
just feed the framework with the usable parameters. The rate control
framework will now deal with passing the parameters to the selected
algorithm. Right now we have AMRR (the default) and RSSADAPT but there's
no way to select one with ifconfig, yet.
The objective is to have more rate control algorithms in the net80211
stack so all drivers[0] can use it. Ideally, we'll have the well-known
sample rate control algorithm in the net80211 at some point so all
drivers can use it (not just ath).
[0] all drivers that do rate control in software, that is.
Reviewed by: bschmidt, thompsa, weyongo
MFC after: 1 months
net80211 wireless stack. This work is based on the March 2009 D3.0 draft
standard. This standard is expected to become final next year.
This includes two main net80211 modules, ieee80211_mesh.c
which deals with peer link management, link metric calculation,
routing table control and mesh configuration and ieee80211_hwmp.c
which deals with the actually routing process on the mesh network.
HWMP is the mandatory routing protocol on by the mesh standard, but
others, such as RA-OLSR, can be implemented.
Authentication and encryption are not implemented.
There are several scripts under tools/tools/net80211/scripts that can be
used to test different mesh network topologies and they also teach you
how to setup a mesh vap (for the impatient: ifconfig wlan0 create
wlandev ... wlanmode mesh).
A new build option is available: IEEE80211_SUPPORT_MESH and it's enabled
by default on GENERIC kernels for i386, amd64, sparc64 and pc98.
Drivers that support mesh networks right now are: ath, ral and mwl.
More information at: http://wiki.freebsd.org/WifiMesh
Please note that this work is experimental. Also, please note that
bridging a mesh vap with another network interface is not yet supported.
Many thanks to the FreeBSD Foundation for sponsoring this project and to
Sam Leffler for his support.
Also, I would like to thank Gateworks Corporation for sending me a
Cambria board which was used during the development of this project.
Reviewed by: sam
Approved by: re (kensmith)
Obtained from: projects/mesh11s
long-term work before they can be serviced. Packets are tagged and
assigned an age (in seconds) at the point they are added to the
queue. If a packet is not retrieved before it's age expires it is
reclaimed. Tagging can take two forms: a reference to an ieee80211_node
(as happens in the tx path) or an opaque token in cases where there
is no reference or the node structure is not stable (i.e. it's going
to be destroyed).
o add ic_stageq to replace the per-node wds staging queue used for
dynamic wds
o add ieee80211_mac_hash for building ageq tokens; this computes a
32-bit hash from an 802.11 mac address (copied from the bridge)
o while here fix a stray ';' noticed in IEEE80211_PSQ_INIT
Reviewed by: rpaulo
Approved by: re (kensmith)
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.
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
sleepable context for net80211 driver callbacks. This removes the need for USB
and firmware based drivers to roll their own code to defer the chip programming
for state changes, scan requests, channel changes and mcast/promisc updates.
When a driver callback completes the hardware state is now guaranteed to have
been updated and is in sync with net80211 layer.
This nukes around 1300 lines of code from the wireless device drivers making
them more readable and less race prone.
The net80211 layer has been updated as follows
- all state/channel changes are serialised on the taskqueue.
- ieee80211_new_state() always queues and can now be called from any context
- scanning runs from a single taskq function and executes to completion. driver
callbacks are synchronous so the channel, phy mode and rx filters are
guaranteed to be set in hardware before probe request frames are
transmitted.
Help and contributions from Sam Leffler.
Reviewed by: sam
o add net80211 support for a tdma vap that is built on top of the
existing adhoc-demo support
o add tdma scheduling of frame transmission to the ath driver; it's
conceivable other devices might be capable of this too in which case
they can make use of the 802.11 protocol additions etc.
o add minor bits to user tools that need to know: ifconfig to setup and
configure, new statistics in athstats, and new debug mask bits
While the architecture can support >2 slots in a TDMA BSS the current
design is intended (and tested) for only 2 slots.
Sponsored by: Intel
indicates if an association id is required before outbound traffic
is permitted. This cleans up the previous change that broke mcast
traffic "to the stack" in ap mode as a side effect.
Reviewed by: sephe, thompsa, weongyo
don't duplicate this. These are setup according to the role of the
node--the bss node for ap and adhoc modes need to use parameters
that are the least common denomimator of all nodes in the bss;
otherwise we are setting up params for a station joining a bss and
we select those according to the capabilities of the station.
This stuff needs more work as we do extra work due to having setup
in common code paths shared by nodes using both roles.
