kernel/802_11: Remove some dead includes.

<net/if.h>: Do not include <net/if_var.h> for _KERNEL

* Clean up an ancient leftover: do not include <net/if_var.h> from <net/if.h>
for kernel stuffs.

* Adjust various files to include the necess

<net/if.h>: Do not include <net/if_var.h> for _KERNEL

* Clean up an ancient leftover: do not include <net/if_var.h> from <net/if.h>
for kernel stuffs.

* Adjust various files to include the necessary <net/if_var.h> header.

NOTE:
I have also tested removing the inclusion of <net/if.h> from <net/if_var.h>,
therefore add <net/if.h> inclusion for those files that need it but only
included <net/if_var.h>. For some files, the header inclusion orderings are
also adjusted.

show more ...

wlan - Sync netproto/802_11 from FreeBSD part 1/N

* Sync netproto/802_11 from FreeBSD, fbsd git dd885b9a0a0e, May 11 2016.

wlan - Update wlan from Adrian / FreeBSD

* Update the wlan infrastructure, initially working with ath.

kernel/802_11: Fix panic when the desired ratectl algorithm is unavailable.

Set the default to NONE. When a driver calls ieee80211_ratectl_init(), try
to use AMRR etc. if NONE is selected. Drivers m

kernel/802_11: Fix panic when the desired ratectl algorithm is unavailable.

Set the default to NONE. When a driver calls ieee80211_ratectl_init(), try
to use AMRR etc. if NONE is selected. Drivers may still select other
algorithms using ieee80211_ratectl_set() prior to calling _init().

Due to our broken ieee80211_load_module(), we do not currently autoload
the desired ratectl algorithm like FreeBSD does. Instead, a message about
manually loading the module will be printed (see ieee80211_dragonfly.c).

Reported-by: profmakx
Taken-from: FreeBSD

show more ...

ratectl_none - first pass at updating to the new wlan infrastructure

This will ultimately be the default ratectl algorithm for wireless
NIC drivers.

Adapt to new net80211 stack.

- Store tx rate control parameters in drivers, so switching between tx rate
control algorithms will not loose configured values.
- Move tx rate control private structures into its implementation fi

- Store tx rate control parameters in drivers, so switching between tx rate
control algorithms will not loose configured values.
- Move tx rate control private structures into its implementation file.

show more ...

Rename "short/long" retry counter to "data/rts" retry counter. The
original names are inherited from ath(4)'s rate control algorithms,
while ath(4) actually uses short retry counter as rts retry cou

Rename "short/long" retry counter to "data/rts" retry counter. The
original names are inherited from ath(4)'s rate control algorithms,
while ath(4) actually uses short retry counter as rts retry counter,
and long retry counter as data retry counter. According to the short
retry counter usage in 802.11 standard, it can be used as data retry
counter too. Using the "short/long" retry counter is confusing (yah,
I was confused) and most hardwares seem to provide "data/rts" retry
counter, so switch to the new name: "data/rts" retry counter.

This change does not affect ONOE/AMRR TX rate control algorithms
operation in netproto/802_11, but it paves the way for Sample TX rate
control algorithm.

show more ...

Implement a generic TX rate control algorithm framework in 802.11 layer.
It is highly modulized so TX rate control algorithms can be added with ease.
Only limited interfaces are exported for driver t

Implement a generic TX rate control algorithm framework in 802.11 layer.
It is highly modulized so TX rate control algorithms can be added with ease.
Only limited interfaces are exported for driver to use, so most of the WiFi
drivers can be converted without too much trouble. It does not affect WiFi
drivers which are unaware of the new framework yet. Also, the new framework
allows TX rate control algorithm to be changed without touching the 802.11
state machine or reinitializing WiFi devices.

Two TX rate control algorithms are factored out from ath(4) driver:
1) Onoe TX rate control algorithm, which is suitable for almost any kinds of
WiFi NIC driver, especially for 11b devices. (*)
2) AMRR TX rate control algorithm, which should _only_ be used by the WiFi NIC
which supports multi-rate retry. More information of this TX rate control
algorithm is available at:
http://www-sop.inria.fr/rapports/sophia/RR-5208.html

In order to use the framework, individual WiFi driver needs to do following:
1) Tell the framework, which TX rate control algorithms it supports and which
one to be used as the default, by setting up ieee80211com.ic_ratectl.
2) Call ieee80211_ratectl_newstate() in driver's own newstate() function.
3) When set up hardware TX descriptors, which normally contain TX rate related
fields, instead of accessing ieee80211_node.ni_txrate directly, call
ieee80211_ratectl_findrate() to get a rate set from the framework.
4) When TX completes, feed TX state (e.g. failure, number of retries) to the
framework by calling ieee80211_ratectl_tx_complete().

Teach ifconfig(8) to print and set the TX rate control algorithm.


# (*) There is no formal paper for this algorithm, but following two papers
# have brief introduction of this TX rate control algorithm:
# http://www-sop.inria.fr/rapports/sophia/RR-5208.html
# http://www.pdos.lcs.mit.edu/papers/jbicket-ms.pdf

show more ...