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

Remove empty DragonFly CVS IDs.

Sync with latest net80211 changes from FreeBSD, therby removing DFly's
ratectl code.

Adapt to new net80211 stack.

First pass at converting the net80211 infrastrcture from FreeBSD.

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

- Define 802.11 modulation types as 'enum ieee80211_modtype'.
- Expose ieee80211_rate2modtype() for pubic use.
- Add definition for DIFS, slot time and contention window.
- Add addition field in TX r

- Define 802.11 modulation types as 'enum ieee80211_modtype'.
- Expose ieee80211_rate2modtype() for pubic use.
- Add definition for DIFS, slot time and contention window.
- Add addition field in TX rate control state structure, so drivers can
give hints to TX rate control algorithms about their capabilities.
- Add Sample TX rate control support:
http://www.pdos.lcs.mit.edu/papers/jbicket-ms.pdf
It is factored out and adapted from the one in ath(4).
- In ieee80211_ratectl.h, expose only IEEE80211_RATECTL_{ONOE,AMRR,SAMPLE}
for user space program.
- Teach ifconfig(8) to show and set Sample TX rate control algorithm.
- Fix a node leakage on rt2560_tx_mgt() error handling path.
- Support Onoe and Sample TX rate control algorithm in 2560 part of
ral(4), and use Sample TX rate control algorithm as the default TX
rate control algorithm. [*]
- Make ral(4) depend on wlan_ratectl_{onoe,sample}.
- Hook Sample TX rate control algorithm into GENERIC and LINT.

# [*]
# If Sample TX rate control algorithm is used, I get almost 100~200%
# UDP_STREAM netperf TX performance boost than the original TX rate
# control algorithm in open/noisy enviroments, and +200~500Kbits/s
# UDP_STREAM netperf TX performance boost under good conditions.

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

Rename printf -> kprintf in sys/ and add some defines where necessary
(files which are used in userland, too).

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