MFC r305895:

[net80211] add a HT method to populate HTCAP based on IBSS requirements.

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.

Copy head@r302406 to stable/11 as part of the 11.0-RELEASE cycle.
Prune svn:mergeinfo from the new branch, as nothing has been merged
here.

Additional commits post-branch will follow.

Approved by: re (implicit)
Sponsored by: The FreeBSD Foundation

[net80211] Initial A-MSDU support for testing / evaluation

A-MSDU is another 11n aggregation mechanism where multiple ethernet
frames get LLC encapsulated (so they have a length field), padded,
and put in a single MPDU (802.11 MAC frame.) This means it gets sent
out as a single frame, with a single seqno, it's acked as one frame, etc.

It turns out that, hah, atheros fast frames is almost but not quite
like this, so I'm reusing all of the current superg/fast-frames stuff
in order to actually transmit A-MSDU. Yes, this means that A-MSDU
frames are also only aggregated two at a time, so it's not necessarily
a huge win, but it's better than nothing.

This doesn't do anything by default - the driver needs to say it does
A-MSDU as well as set the AMSDU software TX capability so this code path
gets exercised.

For now, the only driver that enables this is urtwn. I'll enable it
for rsu at some point soon.
Tested:

* Add an amsdu encap path to aggregate two frames, same as the
fast-frames path.

* Always do the superg init/teardown and node init/teardown stuff,
regardless of whether the nodes are doing fast-frames (the ATH
capability stuff.) That way we can reuse it for amsdu.

* Don't do AMSDU for multicast/broadcast and EAPOL frames.

* If we're doing A-MPDU, then don't bother doing FF/A-MSDU.
We can likely do both together, but I don't want to change
behaviour.

* Teach the fast frames approx txtime logic to support the 11n
rates. But, since we don't currently have a full "current rate"
support, assume it's HT20, long-gi, etc. That way we overshoot
on the TX time estimation, so we're always inside the requirements.
(And we only aggregate two frames for now, so we're not really
going to exceed that.)

* Drop the maximum FF age default down to 2ms, otherwise we end up
with some very annoyingly large latencies.

TODO:

* We only aggregate two ethernet frames, so I'm not checking the max
A-MSDU size. But when it comes time to support >2 frames, we should
obey that.

Tested:

* urtwn(4)

Abstract out the ampdu TX pps initialisation code so it can be reused
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

Add external facing methods to control TX A-MPDU negotiaton.
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>.

Add an external facing function to manually set the RX A-MPDU parameters
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.

Migrate the net80211 TX aggregation state to be from per-AC to per-TID.

TODO:

* Test mwl(4) more thoroughly!

Reviewed by: bschmidt (for iwn)

Create a new task to handle 802.11n channel width changes.

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

Complete the MCS rate table based on the final 802.11n std. While here
adjust the IEEE80211_HTRATE_MAXSIZE constant, only MCS0 - 76 are valid
the other bits in the mcsset IE (77 - 127) are either reserved or used
for TX parameters.

Decrement rxa_pad due to the addition of rxa_private.

Add a private field to struct ieee80211_rx_ampdu do hold driver specific
data.

Sponsored by: iXsystems, inc

Revamp 802.11 action frame handling:
o add a new facility for components to register send+recv handlers
o ieee80211_send_action and ieee80211_recv_action now use the registered
handlers to dispatch operations
o rev ieee80211_send_action api to enable passing arbitrary data
o rev ieee80211_recv_action api to pass the 802.11 frame header as it may
be difficult to locate
o update existing IEEE80211_ACTION_CAT_BA and IEEE80211_ACTION_CAT_HT handling
o update mwl for api rev

Reviewed by: rpaulo
Approved by: re (kensmith)

pad data structures to enable integration of future features w/o abi breakage

promote ieee80211_seq typedef

o make %b msg bit defines public (to user apps too)
o rename IEEE80211_C_CRYPTO_BITS to IEEE80211_CRYPTO_BITS

Sync BAR frame handling with out of tree work:
o correct BAR frame construction for AMPDU
o retransmit BAR frames until ACK'd or timeout (use tunables to
control behaviour, default is very aggressive)
o defer seq# update until BAR frame is ACK'd
o add BAR response handling callback for driver to interpose and
push new state to device or push pending aggregates

While here also:
o add backpointer to node in the per-tid tx aggregation data structure
o move ampdu tx state setup/teardown work to separate functions

Revamp ht ie handling:
o change ieee80211_parse_htcap and ieee80211_parse_htinfo to save only
internal state obtained from the ie's; no dynamic state such as
ni_chw is altered
o add ieee80211_ht_updateparams to parse ht cap+info ie's and update
dynamic node state
o change ieee80211_ht_node_init to not take an htcap ie that is parsed;
instead have the caller make a separate call as one caller wants to
parse the ie while another wants to parse both cap+info ie's and
update state so can better do this with ieee80211_ht_updateparams

These changes fix sta mode state handling where the node's channel
width was shifted to ht20/ht40 prematurely.

change ieee80211_ampdu_stop to take an explicit reason code

Cleanup starting seq# for tx ampdu:
o use txa_start to form the addba request and purge txa_seqstart
o fill txa_start before calling ic_addba_request to permit drivers
to override when they handle seq# generation (e.g. mwl)

moreve the aggregation q; it's not being used and
there's a better way to do this

move inline keyword to silence compiler complaints

Multi-bss (aka vap) support for 802.11 devices.

Note this includes changes to all drivers and moves some device firmware
loading to use firmware(9) and a separate module (e.g. ral). Also there
no longer are separate wlan_scan* modules; this functionality is now
bundled into the wlan module.

Supported by: Hobnob and Marvell
Reviewed by: many
Obtained from: Atheros (some bits)

add opaque pointer to tx ampdu state for drivers

MFC after: 3 days

sync 11n support with vap code base; many changes based on interop
testing with all major vendors

MFC after: 1 week

Update beacon handling to sync w/ vap code base:
o add driver callback to handle notification of beacon changes;
this is required for devices that manage beacon frames themselves
(devices must override the default handler which does nothing)
o move beacon update-related flags from ieee80211com to the beacon
offsets storage (or handle however a driver wants)
o expand beacon offsets structure with members needed for 11h/dfs
and appie's
o change calling convention for ieee80211_beacon_alloc and
ieee80211_beacon_update
o add overlapping bss support for 11g; requires driver to pass
beacon frames from overlapping bss up to net80211 which is not
presently done by any driver
o move HT beacon contents update to a routine in the HT code area

Reviewed by: avatar, thompsa, sephe
Approved by: re (blanket wireless)

Update 802.11 wireless support:
o major overhaul of the way channels are handled: channels are now
fully enumerated and uniquely identify the operating characteristics;
these changes are visible to user applications which require changes
o make scanning support independent of the state machine to enable
background scanning and roaming
o move scanning support into loadable modules based on the operating
mode to enable different policies and reduce the memory footprint
on systems w/ constrained resources
o add background scanning in station mode (no support for adhoc/ibss
mode yet)
o significantly speedup sta mode scanning with a variety of techniques
o add roaming support when background scanning is supported; for now
we use a simple algorithm to trigger a roam: we threshold the rssi
and tx rate, if either drops too low we try to roam to a new ap
o add tx fragmentation support
o add first cut at 802.11n support: this code works with forthcoming
drivers but is incomplete; it's included now to establish a baseline
for other drivers to be developed and for user applications
o adjust max_linkhdr et. al. to reflect 802.11 requirements; this eliminates
prepending mbufs for traffic generated locally
o add support for Atheros protocol extensions; mainly the fast frames
encapsulation (note this can be used with any card that can tx+rx
large frames correctly)
o add sta support for ap's that beacon both WPA1+2 support
o change all data types from bsd-style to posix-style
o propagate noise floor data from drivers to net80211 and on to user apps
o correct various issues in the sta mode state machine related to handling
authentication and association failures
o enable the addition of sta mode power save support for drivers that need
net80211 support (not in this commit)
o remove old WI compatibility ioctls (wicontrol is officially dead)
o change the data structures returned for get sta info and get scan
results so future additions will not break user apps
o fixed tx rate is now maintained internally as an ieee rate and not an
index into the rate set; this needs to be extended to deal with
multi-mode operation
o add extended channel specifications to radiotap to enable 11n sniffing

Drivers:
o ath: add support for bg scanning, tx fragmentation, fast frames,
dynamic turbo (lightly tested), 11n (sniffing only and needs
new hal)
o awi: compile tested only
o ndis: lightly tested
o ipw: lightly tested
o iwi: add support for bg scanning (well tested but may have some
rough edges)
o ral, ural, rum: add suppoort for bg scanning, calibrate rssi data
o wi: lightly tested

This work is based on contributions by Atheros, kmacy, sephe, thompsa,
mlaier, kevlo, and others. Much of the scanning work was supported by
Atheros. The 11n work was supported by Marvell.