MFC @ r241285

IFC @ r242684

Sync from head

Merge head r233826 through r240095.

Don't call the node iteration function inside the node table / node
iterate lock.

This causes LORs and deadlocks as some code paths will have the com lock
held when calling ieee80211_iterate_nodes()

Don't call the node iteration function inside the node table / node
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

show more ...

MFC

Merge head r233826 through r234834.

IFC @ r234692

sys/amd64/include/cpufunc.h
sys/amd64/include/fpu.h
sys/amd64/amd64/fpu.c
sys/amd64/vmm/vmm.c

- Add API to allow vmm FPU state init/save/restore.

FP stuff discussed with: kib

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)

Merge head r232686 through r233825 into projects/pf/head.

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
dr

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

show more ...

Remove redundant forward declaration of struct ieee80211com.

Approved by: bschmidt

Add initial support for MIMO statistics to net80211.

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.

Add initial support for MIMO statistics to net80211.

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.

show more ...

MFC r206367, r206358, r206370, r206371, r206372, r206398, r206415,
r206416, r206417, r206418, r206418:

net80211 ratectl framework.

Update to current version of head.

Merge svn+ssh://svn.freebsd.org/base/head@206571

net80211 rate control framework (net80211 ratectl).

This framework allows drivers to abstract the rate control algorithm and
just feed the framework with the usable parameters. The rate control
fram

net80211 rate control framework (net80211 ratectl).

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

show more ...

Merge from head

Merge from head up to r188941 (last revision before the USB stack switch)

- MFC @196061

Implementation of the upcoming Wireless Mesh standard, 802.11s, on the
net80211 wireless stack. This work is based on the March 2009 D3.0 draft
standard. This standard is expected to become final nex

Implementation of the upcoming Wireless Mesh standard, 802.11s, on the
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

show more ...

Add ieee80211_ageq; a facility for staging packets that require
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
que

Add ieee80211_ageq; a facility for staging packets that require
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)

show more ...

- Merge from HEAD

When associating to an AP we don't know if HT is negotiated until
we receive the AssocResp, so we can only set ni_txparms properly
at that point. To make this possible make node_setuptxparms public

When associating to an AP we don't know if HT is negotiated until
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.

show more ...

reserve node flag bits for a-msdu tx/rx