Merge ^/head r311546 through r311683.

[net80211] add VHT node flag; parsed chanwidth.

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 to

[net80211] add VHT node flag; parsed chanwidth.

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.

show more ...

Merge ^/head r309817 through r310168.

[net80211] start laying down the foundation for 11ac support.

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

[net80211] start laying down the foundation for 11ac support.

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.

show more ...

Merge ^/head r308870 through r309105.

[net80211] store references to VHT and related IEs.

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 k

[net80211] store references to VHT and related IEs.

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.

show more ...

Merge ^/head r308227 through r308490.

Fix improper use of "its".

Sponsored by: Dell EMC Isilon

Merge ^/head r306412 through r306905.

net80211: add one-vap version of ieee80211_iterate_nodes()

- Add a counter into 'struct ieee80211_node_table' to save current number
of allocated nodes.
(allows to remove array overflow checking in

net80211: add one-vap version of ieee80211_iterate_nodes()

- 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

show more ...

Merge ^/head r305892 through r306302.

[net80211] don't add IBSS node table entries for neighbors from other SSIDs.

The adhoc probe/beacon input path was creating nodes for all SSIDs.
This wasn't a problem when the NICs were configured t

[net80211] don't add IBSS node table entries for neighbors from other SSIDs.

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

show more ...

[net80211] remove node scan lock / generation number + fix few LORs

Drop scan generation number and node table scan lock - the only place
where ni_scangen is checked is in ieee80211_timeout_stations

[net80211] remove node scan lock / generation number + fix few LORs

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

show more ...

MFH

Sponsored by: The FreeBSD Foundation

[net8021] Pull out the ibss check code into a public function.

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 bu

[net8021] Pull out the ibss check code into a public function.

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.

show more ...

Merge from head

Sponsored by: Gandi.net

Merge from head

Merge ^/head r288197 through r288456.

Merge from head

Sync up with head (up to r288341).

Migrate the fast-frames transmit support away from using the txa_private
field and into a separate fast-frames staging pointer in ieee80211_node.

The A-MPDU TX path allows txa_private to be used by

Migrate the fast-frames transmit support away from using the txa_private
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.

show more ...

Merge fresh head.

IFC @247348.

Sync with HEAD.

Stop a mesh STA from flooding with peer frames.

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. Thi

Stop a mesh STA from flooding with peer frames.

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)

show more ...