net80211: add initial key management suites from 802.11-2016, APIs to register them

The WPA1/WPA2 driver capabilities aren't really enough in today's world.
There are a /lot/ more key management suites to support!

So, add initial support for net80211 and drivers to announce what
key management suites are supported. These are the list from 802.11-2016
section 9.4.2.25.3 (AKM suites.)

The flags are for software supported key management.

Drivers may support more key management suites and are welcome to
announce more; net80211 will only announce ones that we know
net80211 knows "enough" about to support correctly.

There /are/ other suites that may be interesting to some people in
the future that are not part of this set - eg if anyone ever
wants to support the Chinese WAPI standard - so this bitmap is not
specifically just the AKM suites in the RSN OUI.

This should eventually be communicated up to the wpa_supplicant and
hostapd via a replacement driver/vap capabilities call so they know
what to enable rather than just IEEE80211_C_WPA1 / IEEE80211_C_WPA2.

Differential Revision: https://reviews.freebsd.org/D44919
Reviewed by: bz

net80211: add driver / crypto methods to set the hardware / software cipher suites

Drivers currently announce hardware crypto cipher support by
setting up ic_cryptocaps.

This adds two public function calls:

* ieee80211_set_software_ciphers() - set the software cipher set;
* ieee80211_set_hardware_ciphers() - set the hardware cipher set.

For now these just call into the newly crypto routines to set the ciphers.

This then adds the two crypto routines, similarly named, to set
the hardware/software cipher suite.

This is a no-op right now - wep/tkip/ccmp are already set by default
so drivers aren't required to call these routines for software
encryption, and drivers already set ic_cryptocaps for hardware
encryption.

Differential Revision: https://reviews.freebsd.org/D44827

net80211: deal with lost state transitions

Since 5efea30f039c4 we can possibly lose a state transition which can
cause trouble further down the road.
The reproducer from 643d6dce6c1e can trigger these for example.
Drivers for firmware based wireless cards have worked around some of
this (and other) problems in the past.

Add an array of tasks rather than a single one as we would simply
get npending > 1 and lose order with other tasks. Try to keep state
changes updated as queued in case we end up with more than one at a
time. While this is not ideal either (call it a hack) it will sort
the problem for now.
We will queue in ieee80211_new_state_locked() and do checks there
and dequeue in ieee80211_newstate_cb().
If we still overrun the (currently) 8 slots we will drop the state
change rather than overwrite the last one.
When dequeing we will update iv_nstate and keep it around for historic
reasons for the moment.

The longer term we should make the callers of
ieee80211_new_state[_locked]() actually use the returned errors
and act appropriately but that will touch a lot more places and
drivers (possibly incl. changed behaviour for ioctls).

rtwn(4) and rum(4) should probably be revisted and net80211 internals
removed (for rum(4) at least the current logic still seems prone to
races).

PR: 271979, 271988, 275255, 263613, 274003
Sponsored by: The FreeBSD Foundation (in 2023)
MFC after: 3 days
Reviewed by: cc
Differential Revision: https://reviews.freebsd.org/D43389

net80211: migrate ic_vhtcaps, ic_vht_mcsinfo, ic_flags_vht

Like for the VAP rename ic_flags_vht to ic_vht_flags for consistency to
keep "VHT" fields together and merge ic_vhtcaps and ic_vht_mcsinfo
into struct ieee80211_vht_cap ic_vht_cap.

While the structure layout changes no other functional changes intended.

Sponsored by: The FreeBSD Foundation
MFC after: 3 days
Reviewed by: adrian, cc
Differential Revision: https://reviews.freebsd.org/D42421

net80211: combine iv_vhtcaps and iv_vht_mcsinfo

The iv_vhtcaps and iv_vht_mcsinfo fields together form
struct ieee80211_vht_cap so combine them into one field in the VAP
and keep the information together.

While the structure layout changes no other functional changes intended.

Sponsored by: The FreeBSD Foundation
MFC after: 3 days
Reviewed by: adrian, cc
Differential Revision: https://reviews.freebsd.org/D42420

net80211: rename iv_flags_vht to iv_vht_flags

While the flag field is internal start naming it as well as "iv_vht*"
so we keep all "VHT" fields together. This breaks with what was done
done for HT but with HE, EHT, .. coming one day seems the more logic
choice.

No functional changes intended.

Sponsored by: The FreeBSD Foundation
MFC after: 3 days
Reviewed by: adrian, cc
Differential Revision: https://reviews.freebsd.org/D42419

sys: Remove $FreeBSD$: one-line .c pattern

Remove /^[\s*]*__FBSDID\("\$FreeBSD\$"\);?\s*\n/

spdx: The BSD-2-Clause-FreeBSD identifier is obsolete, drop -FreeBSD

The SPDX folks have obsoleted the BSD-2-Clause-FreeBSD identifier. Catch
up to that fact and revert to their recommended match of BSD-2-Clause.

Discussed with: pfg
MFC After: 3 days
Sponsored by: Netflix

IfAPI: Explicitly include <net/if_private.h> in netstack

Summary:
In preparation of making if_t completely opaque outside of the netstack,
explicitly include the header. <net/if_var.h> will stop including the
header in the future.

Sponsored by: Juniper Networks, Inc.
Reviewed by: glebius, melifaro
Differential Revision: https://reviews.freebsd.org/D38200

net80211(4): Correct a grammar mistake in a source code comment

- s/the/be the/
- s/Mhz/MHz/
- s/it'll/it will/

Reported by: bz, danfe
MFC after: 3 days

net80211(4): Remove a double word in a source code comment

- s/the the/the/

MFC after: 3 days

net80211: consistently use the IEEE80211_M_ memory related options

Replace a malloc() by IEEE80211_MALLOC().
For malloc flags even in the local ieee80211_freebsd.c there was a mix
of both versions M_ and IEEE80211_M_.
Consistently use the IEEE80211_M_ malloc options everywhere.
If the field is changed for malloc, it'll also be changed for the
other accessor functions taking a "how" field to avoid any confusion.

Sponsored by: The FreeBSD Foundation
MFC after: 1 week
Reviewed by: adrian
Differential Revision: https://reviews.freebsd.org/D36249

net80211: add VHT5G and VHT2G checks/return to media_status

Add the fields for VHT (2Ghz and 5Ghz) to report back by media_status
so we actually have a chance to get the right information.

Sponsored by: The FreeBSD Foundation
MFC after: 1 week
Reviewed by: adrian
Differential Revision: https://reviews.freebsd.org/D35977

net80211: enhance (disabled) debugging

Add maxchans to the disabled debugging in addchan() and copychan_prev()
to aid debugging possible errors rreturned due to reaching maxchans
limits.

Sponsored by: The FreeBSD Foundation
MFC after: 3 days

net80211/drivers: improve ieee80211_rx_stats for band

While IEEE80211_R_BAND was defined, there was no place to store the
band. Add a field for that, adjust ieee80211_lookup_channel_rxstatus()
to require it, and update drivers passing "R_{FREQ|IEEE}" in already to
provide the band as well. For the moment keep the fall-back code
requiring all three fields.

Sponsored by: The FreeBSD Foundation
MFC after: 3 days
Reviewed by: adrian
Differential Revision: https://reviews.freebsd.org/D30662

net80211: update for (more) VHT160 support

Implement two macros IEEE80211_VHTCAP_SUPP_CHAN_WIDTH_IS_160MHZ()
and its 80+80 counter part to check in vhtcaps for appropriate
levels of support and use the macros throughout the code.

Add vht160_chan_ranges/is_vht160_valid_freq and handle analogue
to vht80 in various parts of the code.

Add ieee80211_add_channel_cbw() which also takes the CBW flag
fields and make the former ieee80211_add_channel() a wrapper to it.
With the CBW flags we can add HT/VHT channels passing them to
getflags() for the 2/5ghz functions.

In ifconfig(8) add the regdomain_addchans() support for VHT160
and VHT80P80.

With this (+ regdoain.xml updates) VHT160 channels can be
configured, listed, and pass regdomain where appropriate.

Tested with: iwlwifi
Reviewed by: adrian
MFC after: 10 days
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D26712

80211: non-functional changes

Sort a few VHT160 and 80+80 lines, update some comments, and remove
a superfluous ','.

No functional changes intended.

MFC after: 1 week
Sponsored by: The FreeBSD Foundation

net80211: enhance getflags*() and ieee80211_add_channel*()

For ieee80211_add_channel+*() we are passing in an int flag for
ht40 and in some cases another int flag for vht80 where we'd only
need two bits really.
Convert these variables to a bitflag and fold them together into one.
This also allows for VHT160 and VHT80P80 and whatever may come to
be considered. Define the various options currently needed.

Change the drivers (rtwn and rsu) which actually set this bit to non-0.
For convenience the "1" currently used for HT40 is preserved.

Enahnce getflags_5ghz() to handle the full set of VHT flags based
on the input flags from the the driver.

Update the regdomain implementation as well to make use of the new
flags and deal with higher [V]HT bandwidths.

ieee80211_add_channel() specifically did not take flags so it will
not support naything beyond 20Mhz channels.

Note: I am not entirely happy with the "cbw_flag[s]" name, but we
do use chan_flags elsewhere already.

MFC after: 2 weeks
Reviewed by: adrian, gnn
Sponsored by: Rubicon Communications, LLC (d/b/a "Netgate")
Differential revision: https://reviews.freebsd.org/D26091

net80211: improve media information for VHT5GHZ

Improve ieee80211_media_setup(), media2mode(), and
ieee80211_rate2media() for VHT5GHZ at least.

Reviewed by: adrian, gnn
MFC after: 2 weeks
Sponsored by: Rubicon Communications, LLC (d/b/a "Netgate")
Differential Revision: https://reviews.freebsd.org/D26089

net80211: set_vht_extchan() reverse order to always return best

In set_vht_extchan() the checks are performed in the order of VHT20/40/80.
That means if a channel has a lower and higheer VHT flag set we would
return the lower first.
We normally do not set more than one VHT flag so this change is supposed
to be a NOP but follows the logical thinking order of returning the best
first. Also we nowhere assert a single VHT flag so make sure we'll not
be stuck with VHT20 when we could do more.

While here add the debugging printfs for VHT160 and VHT80P80 which still
need doing once we deal with a driver at that level.

Reviewed by: adrian, gnn
MFC after: 2 weeks
Sponsored by: Rubicon Communications, LLC (d/b/a "Netgate")
Differential Revision: https://reviews.freebsd.org/D26088

net80211: remove vertical whitespace

No functional changes.

MFC after: 2 weeks
Sponsored by: Rubicon Communications, LLC (d/b/a "Netgate")

80211: consistently order 160 and 80+80

For flags and checks the order goes VHT160 and then VHT80P80 unless
checks are in reverse order ("more comes first") in which case we
deal with VHT80P80 first.
The one reverse order to pick out is where we check channel
prefernences. While it may seem that VHT160 is better, finding
two "free" channels (VHT 80+80) is more likely so we do prefer that.

While dealing with VHT160 and VHT80P80 add extra clauses previously
missing or marked TODO in a few places.

Reviewed by: adrian, gnn
MFC after: 2 weeks
Sponsored by: Rubicon Communications, LLC (d/b/a "Netgate")
Differential Revision: https://reviews.freebsd.org/D26002

[net80211] Add initial U-APSD negotiation support.

U-APSD (unscheduled automatic power save delivery) is a power save method
that's a bit better than legacy PS-POLL - stations can mark frames with
an extra flag that tells the AP to leak out more frames after it sends
its own frames rather than needing to send a PS-POLL to get another frame
from the AP.

Now, this code just handles the negotiation bits; it doesn't actually
implement U-APSD. That's up to drivers, and nothing in the tree yet
implements this. I /may/ implement this for ath(4) if I eventually care
enough but right now I plan on just implementing it for firmware offload
based NICs that handle this in the NIC.

I'll commit the ifconfig bit after this and I may have some follow-up
commits as this gets used more by me in local testing.

This should be a glorious no-op for everyone else. If things change
for anyone that isn't fixed by a complete recompile then please reach out
to me.

[net80211] Migrate short slot time configuration into per-vap and deferred taskqueue updates.

The 11b/11g ERP and slot time update handling are two things which weren't
migrated into the per-VAP state when Sam did the initial VAP work.
That makes sense for a lot of setups where net80211 is driving radio state
and the radio only cares about the shared state.

However, as noted by a now deleted comment, the ERP and slot time updates
aren't EXACTLY correct/accurate - they only take into account the most
RECENTLY created VAP, and the state updates when one creates/destroys
VAPs isn't exactly great.

So:

* track the short slot logic per VAP;
* whenever the slot time configuration changes, just push it into a deferred
task queue update so drivers don't have to serialise it themselves;
* if a driver registers a per-VAP slot time handler then it'll just get the
per VAP one;
* .. if a driver registers a global one then the legacy behaviour is maintained -
a single slot time is calculated and pushed out.

Note that the calculated slot time is better than the existing logic - if ANY
of the VAPs require long slot then it's disabled for all VAPs rather than
whatever the last configured VAP did.

Now, this isn't entirely complete - the rest of ERP tracking around short/long
slot capable station tracking needs to be converted into per-VAP, as well
as the preamble/barker flags. Luckily those also can be done in a similar
fashion - keep per-VAP counters/flags and unify them before doing the driver
update. I'll defer that work until later.

All the existing drivers can keep doing what they're doing with the global
slot time flags as that is maintained. One driver (iwi) used the per-VAP
flags instead of the ic flags, so now that driver will work properly.

This unblocks some ath10k porting work as the firmware takes the slot time
configuration per-VAP rather than globally, and some firmware handles
STA+AP and STA+STA (on same/different channels) configurations where
the firmware will switch slot time as appropriate.

Tested:

* AR9380, STA/AP mode
* AR9880 (ath10k), STA mode

Enhance the comment ieee80211_add_channel() to avoid a
misunderstanding that the function does not work additive
when repeatedly called for diffferent bands.

Reviewed by: avos (a few months ago)
MFC after: 2 weeks

Remove 2GHz channel list copies from wireless drivers.

Wrap ieee80211_add_channel_list_2ghz into another function
which supplies default (1-14) channel list to it and drop
its copies from drivers.

Checked with RTL8188EE, country US / JP / KR / UA.

MFC after: 2 weeks

net80211: resolve ioctl <-> detach race for ieee80211com structure

Since r287197 ieee80211com is a part of drivers softc; as a result,
after detach all pointers to it (iv_ic, ni_ic) are invalid. Most
possible users (tasks, interrupt handlers) are blocked / removed
when device is stopped; however, ioctl handlers were not tracked
and may crash if ieee80211com structure is accessed.

Since ieee80211com pointer access from ieee80211vap structure is not
protected by lock (constant after interface creation) and used in
many other places just use reference counting for ioctl handlers;
on detach set 'detached' flag and wait until reference counter goes to 0.

For HEAD ieee80211vap size was changed (__FreeBSD_version bumped);
however, in stable branches I'm going to split / reuse the last
iv_spare field for KBI stability.

Tested with:
- rsu(4), SIOCSIFCAP (-rxcsum) ioctl;
- rtwn_pci(4), SIOCG80211 / IEEE80211_IOC_HTPROTMODE ioctl.

MFC after: 1 week

net80211: Fix ifdetach w/o ifattach, small whitespace cleanup

As the comment says, ifdetach might be called during the course of driver
detach if initialization failed. This shouldn't be a total failure, though,
we just have nothing to do there.

This has been modified slightly from Augustin's original commit to move the
bail-out slightly earlier since the ic wouldn't have been added to the
ic list in the first place, and a comment has been added describing when
this might be an issue.

Submitted by: Augustin Cavalier <waddlesplash@gmail.com>
Obtained from: Haiku (e6f6c1b4633532a8ad37c803dc7c65601e5b24ba)

sys: general adoption of SPDX licensing ID tags.

Mainly focus on files that use BSD 2-Clause license, however the tool I
was using misidentified many licenses so this was mostly a manual - error
prone - task.

The Software Package Data Exchange (SPDX) group provides a specification
to make it easier for automated tools to detect and summarize well known
opensource licenses. We are gradually adopting the specification, noting
that the tags are considered only advisory and do not, in any way,
superceed or replace the license texts.

No functional change intended.

net80211: fix possible panic when wlan(4) interface is destroyed.

If this is the last running vap wait until device will be powered off
(fixes panic when 'ifconfig wlan0 destroy' is executed for running iwn(4)
interface).

Tested with:
- Intel 6205, STA mode.
- RTL8188EU, STA / IBSS modes.
- RTL8821AU, STA / HOSTAP modes.

[net80211] begin fleshing out per-VAP WME configurations.

As part of (eventual) p2p/tdls/multi-STA support, a lot of global configuration
parameters (WME, ERP (slot, preamble), channel width, HT protmode, etc are the
biggest offenders) should be per-VAP.

For multi-BSS VAP operation they may be linked, but for p2p/TDLS
operation that can be off-channel they can definitely be different
(think: 2GHz STA, 5GHz p2p.)

The global configuration view of these is mostly a "configure the current
non-smart-firmware NIC" view. This should be split up into per-VAP state,
then a global non-smart-firmware-NIC management layer to handle channel
changes and such in software.

This is step one in a loooong road for this. It should be a big non-functional
change for everyone.

* create a per-VAP WME update call.
* call it if its set, and call the global callback if it isn't

This still uses global WME state - it's just preparation for a future change
which will make the WME state per-VAP and fall through to a shared WME
configuration for hostap operation.

Note: this requires a full kernel recompile; the internal net80211 ABI has changed.

Reviewed by: avos
Differential Revision: https://reviews.freebsd.org/D9986

net80211: fix ieee80211_htrateset setup, return EINVAL for an unsupported
ucast/mcast/mgmt HT rate.

- Init global ieee80211_htrateset only once; neither ic_htcaps nor
ic_txstream is changed when device is attached;
- Move global ieee80211_htrateset structure to ieee80211com;
there was a possible data race when more than 1 wireless device is
used simultaneously;
- Discard unsupported rates in ieee80211_ioctl_settxparams(); otherwise,
an unsupported value may break connectivity (actually,
'ifconfig wlan0 ucastrate 8' for RTL8188EU results in immediate
disconnect + infinite 'device timeout's after it).

Tested with:
- Intel 6205, STA mode.
- RTL8821AU, STA mode.

Reviewed by: adrian
Differential Revision: https://reviews.freebsd.org/D9871

net80211: fix flags setup for HT40 5GHz channels.

[net80211] initial, somewhat incomplete VHT channel setup code and attach path.

This sets up:

* vht capabilities in vaps;
* calls vht_announce to announce VHT capabilities if any;
* sets up vht20, vht40 and vht80 channels, assuming the regulatory code
does the right thing with 80MHz available ranges;
* adds support to the ieee80211_add_channel_list_5ghz() code to populate
VHT channels, as this is the API my ath10k driver is using;
* add support for the freq1/freq2 field population and lookup that
VHT channels require.

The VHT80 code assumes that the regulatory domain already has limited VHT80
bands to, well, 80MHz wide chunks.

[net80211] add VHT mediatype initialisation and update helper functions.

[net80211] add syncflags methods for the VHT flags configuration.

I missed this in my last commit. Pointy hat to me.

[net80211] turn the default TX key configuration (for WEP) into a vap callback.

The ath10k firmware supports hardware WEP offload, and in native wifi mode
(or 802.3 ethernet mode, for that matter) the WEP key isn't actually included
in the TX payload from net80211. Instead, a separate firmware command is issued
that sets the default TX key to be the specified key.

However, net80211 doesn't at all inform the driver layer that this is
occuring - it just "expects" to be inserting WEP header information
when doing WEP TX, even with hardware encryption.

So, to better support the newer world order, turn the default TX key assignment
into a VAP method that can be overridden by the driver and ensure its wrapped
in a crypto begin/end set. That way it should be correctly atomic from the
point of view of keychanges (as long as the driver does the right thing.)

It'd be nice if we passed through to the key_set call a flag that says
"also make this the default key" - that's captured here by calling the
deftxkey method after the key_set method. Maybe I can do that later.

Note: this is a net80211 ABI change, and will require a kernel+modules
recompile. Happy Holidays, etc.

Tested:

* ath10k driver port
* rtwn_usb, WEP station

[net80211] sigh, course I would miss a commit from the 11ac prep commit.

[net80211] prepare for 11ac aware NICs that want to know per-vdev channel and centre frequencies.

* ic_freq is the centre of the primary channel, not the centre of the
HT40/HT80/etc channel. Add a method to access that.
* Add a method to access the centre of the primary channel, including
knowing the centre of the 5/10/20/40/80, versus the primary channel.
Ie, it's the centre of the 40, 80, 160MHz channel.
* Add a method to access the centre frequency of the secondary 80MHz
channel - we don't support VHT yet, but when we do.
* Add methods to access the current channel and the per-dev desired
channel. Ideally drivers that do full offload with a per-vap channel
configuration should use the vap channel, NOT ic_curchan.
Non-offload drivers that require net80211 to change the channel should
be accessing ic_curchan.

net80211: fix more compiler warnings.

ieee80211.c:
add_chanlist(): 'error' variable will be uninitialized if
no channels were passed; return '0' instead.
ieee80211_action.c:
ieee80211_send_action_register(): drop 'break' after 'return'.
ieee80211_crypto_none.c:
none_encap(): 'keyid' is not used in non-debug builds; hide it
behind IEEE80211_DEBUG ifdef.
ieee80211_freebsd.c:
Staticize global 'ieee80211_debug' variable (used only in this
file).
ieee80211_hostap.c:
Fix a comment (associatio -> association).
ieee80211_ht.c:
ieee80211_setup_htrates(): initialize 'maxunequalmcs' to 0 to mute
compiler warning.
ieee80211_hwmp.c:
hwmp_recv_preq(): copy 'prep' between conditional blocks to fix
-Wshadow warning.
ieee80211_mesh.c:
mesh_newstate(): remove duplicate 'ni' definition.
mesh_recv_group_data(): fix -Wempty-body warning in non-debug
builds.
ieee80211_phy.c:
ieee80211_compute_duration(): remove 'break' after panic() call.
ieee80211_scan_sta.c:
Hide some TDMA-specific macros under IEEE80211_SUPPORT_TDMA ifdef
adhoc_pick_bss(): remove 'ic' pointer redefinition.
ieee80211_sta.c:
sta_beacon_miss(): remove 'ic' pointer redefinition.
ieee80211_superg.c:
superg_ioctl_set80211(): drop unreachable return.

Tested with clang 3.8.0, gcc 4.6.4 and gcc 5.3.0.

net80211: unbreak 'show all vaps(/a)' ddb command

Replace ifnet list lookup (which is broken since r287197, because
IFT_IEEE80211 type is not used anymore) with iteration on
ieee80211com list.

Reviewed by: adrian
Differential Revision: https://reviews.freebsd.org/D6419

sys/net*: minor spelling fixes.

No functional change.

net80211: provide a set of ieee80211_add_channel*() functions

This change adds few methods for net80211 channel table setup:

- ieee80211_add_channel()
- ieee80211_add_channel_ht40()
(primarily for drivers, that parse EEPROM to get channel list -
they will allow to hide implementation details).

- ieee80211_add_channel_list_2ghz()
- ieee80211_add_channel_list_5ghz()
(mostly as a replacement for ieee80211_init_channels() - they will allow
to specify non-default channel list; may be used in ic_getradiocaps()).

Tested with wpi(4) (add_channel) and rum(4) (add_channel_list_2ghz).

Reviewed by: adrian
Differential Revision: https://reviews.freebsd.org/D6124

net80211: enable promiscuous mode state change for non-monitor/ahdemo modes

- Allow to enable/disable promiscuous mode when:
* interface is not a member of bridge, or;
* request was issued by user (ifconfig wlan0 promisc), or;
* interface is in MONITOR or AHDEMO mode.
- Drop local workarounds in mwl(4) and malo(4).

Tested with:
- Intel 3945BG, STA mode;
- RTL8188CUS, MONITOR mode;

Reviewed by: adrian
Differential Revision: https://reviews.freebsd.org/D5472

net80211: copy MAC address into iv_myaddr[] instead of aliasing it.

Since IF_LLADDR() returns a non-constant pointer to the MAC address
preserve a copy of it in iv_myaddr.

PR: 208505

net80211: remove redundant locking.

All callers of ieee80211_promisc()/ieee80211_allmulti()
(ieee80211_vap_detach(), ieee80211_ioctl(), ap_start() and ap_end())
already hold the com_lock while calling them.

Tested with RTL8188EU, STA mode.

Approved by: adrian (mentor)
Differential Revision: https://reviews.freebsd.org/D5475

net80211: fix 'uma_zalloc_arg: zone "32" with non-sleepable locks held'
when 'sysctl net.wlan.devices' is executed.

PR: 207497
Submitted by: glebius
Approved by: adrian (mentor)

These files were getting sys/malloc.h and vm/uma.h with header pollution
via sys/mbuf.h

net80211: add ieee80211_restart_all() call.

This call may be used when device cannot continue to operate normally
(e.g., throws firmware error, watchdog timer expires)
and need to be restarted.

Approved by: adrian (mentor)
Differential Revision: https://reviews.freebsd.org/D3998

Replay r286410. Change KPI of how device drivers that provide wireless
connectivity interact with the net80211 stack.

Historical background: originally wireless devices created an interface,
just like Ethernet devices do. Name of an interface matched the name of
the driver that created. Later, wlan(4) layer was introduced, and the
wlanX interfaces become the actual interface, leaving original ones as
"a parent interface" of wlanX. Kernelwise, the KPI between net80211 layer
and a driver became a mix of methods that pass a pointer to struct ifnet
as identifier and methods that pass pointer to struct ieee80211com. From
user point of view, the parent interface just hangs on in the ifconfig
list, and user can't do anything useful with it.

Now, the struct ifnet goes away. The struct ieee80211com is the only
KPI between a device driver and net80211. Details:

- The struct ieee80211com is embedded into drivers softc.
- Packets are sent via new ic_transmit method, which is very much like
the previous if_transmit.
- Bringing parent up/down is done via new ic_parent method, which notifies
driver about any changes: number of wlan(4) interfaces, number of them
in promisc or allmulti state.
- Device specific ioctls (if any) are received on new ic_ioctl method.
- Packets/errors accounting are done by the stack. In certain cases, when
driver experiences errors and can not attribute them to any specific
interface, driver updates ic_oerrors or ic_ierrors counters.

Details on interface configuration with new world order:
- A sequence of commands needed to bring up wireless DOESN"T change.
- /etc/rc.conf parameters DON'T change.
- List of devices that can be used to create wlan(4) interfaces is
now provided by net.wlan.devices sysctl.

Most drivers in this change were converted by me, except of wpi(4),
that was done by Andriy Voskoboinyk. Big thanks to Kevin Lo for testing
changes to at least 8 drivers. Thanks to pluknet@, Oliver Hartmann,
Olivier Cochard, gjb@, mmoll@, op@ and lev@, who also participated in
testing.

Reviewed by: adrian
Sponsored by: Netflix
Sponsored by: Nginx, Inc.

Revert the wifi ifnet changes until things are more baked and tested.

* 286410
* 286413
* 286416

The initial commit broke a variety of debug and features that aren't
in the GENERIC kernels but are enabled in other platforms.

Change KPI of how device drivers that provide wireless connectivity interact
with the net80211 stack.

Historical background: originally wireless devices created an interface,
just like Ethernet devices do. Name of an interface matched the name of
the driver that created. Later, wlan(4) layer was introduced, and the
wlanX interfaces become the actual interface, leaving original ones as
"a parent interface" of wlanX. Kernelwise, the KPI between net80211 layer
and a driver became a mix of methods that pass a pointer to struct ifnet
as identifier and methods that pass pointer to struct ieee80211com. From
user point of view, the parent interface just hangs on in the ifconfig
list, and user can't do anything useful with it.

Now, the struct ifnet goes away. The struct ieee80211com is the only
KPI between a device driver and net80211. Details:

- The struct ieee80211com is embedded into drivers softc.
- Packets are sent via new ic_transmit method, which is very much like
the previous if_transmit.
- Bringing parent up/down is done via new ic_parent method, which notifies
driver about any changes: number of wlan(4) interfaces, number of them
in promisc or allmulti state.
- Device specific ioctls (if any) are received on new ic_ioctl method.
- Packets/errors accounting are done by the stack. In certain cases, when
driver experiences errors and can not attribute them to any specific
interface, driver updates ic_oerrors or ic_ierrors counters.

Details on interface configuration with new world order:
- A sequence of commands needed to bring up wireless DOESN"T change.
- /etc/rc.conf parameters DON'T change.
- List of devices that can be used to create wlan(4) interfaces is
now provided by net.wlan.devices sysctl.

Most drivers in this change were converted by me, except of wpi(4),
that was done by Andriy Voskoboinyk. Big thanks to Kevin Lo for testing
changes to at least 8 drivers. Thanks to Olivier Cochard, gjb@, mmoll@,
op@ and lev@, who also participated in testing. Details here:

https://wiki.freebsd.org/projects/ifnet/net80211

Still, drivers: ndis, wtap, mwl, ipw, bwn, wi, upgt, uath were not
tested. Changes to mwl, ipw, bwn, wi, upgt are trivial and chances
of problems are low. The wtap wasn't compilable even before this change.
But the ndis driver is complex, and it is likely to be broken with this
commit. Help with testing and debugging it is appreciated.

Differential Revision: D2655, D2740
Sponsored by: Nginx, Inc.
Sponsored by: Netflix

For now, just default to presenting "found" channels as 11g, not 11b.

The intel 7260 driver under development requires this - the scans come
in as normal frames but with the frequency provided. The correct method
is to have the driver provide flags (so we can determine if it's 11b
or 11g); this will have to do in the meantime.

Without this, the channel found is 11b, and no ERP (ie "11g") bits
are negotiated with the AP.

This allows the 7260 in 2ghz mode to operate in 11bg, rather than
just 11b.

Tested:

* intel 7260 driver, 11bg channels

Provide ieee80211_get_counter() that sums up ieee802com
errors to the errors of this vap interface.

Sponsored by: Netflix
Sponsored by: Nginx, Inc.

Make ieee80211broadcastaddr global, so that drivers or other
code may use it and not paste.

Reduce diff before functional changes:
- Use ic_name instead of if_xname.
- Formatting cleanup.

Cleanup compat shims for FreeBSD versions that predate 10.0-RELEASE.
There are no plans to merge anything save a trivial bugfix to stable/9.

Discussed with: adrian

Change three methods in struct ieee80211com, namely ic_updateslot,
ic_update_mcast and ic_update_promisc, to pass pointer to the ieee80211com,
not to the ifnet.

Sponsored by: Netflix
Sponsored by: Nginx, Inc.

Begin plumbing ieee80211_rx_stats through the receive path.

Smart NICs with firmware (eg wpi, iwn, the new atheros parts, the intel 7260
series, etc) support doing a lot of things in firmware. This includes but
isn't limited to things like scanning, sending probe requests and receiving
probe responses. However, net80211 doesn't know about any of this - it still
drives the whole scan/probe infrastructure itself.

In order to move towards suppoting smart NICs, the receive path needs to
know about the channel/details for each received packet. In at least
the iwn and 7260 firmware (and I believe wpi, but I haven't tried it yet)
it will do the scanning, power-save and off-channel buffering for you -
all you need to do is handle receiving beacons and probe responses on
channels that aren't what you're currently on. However the whole receive
path is peppered with ic->ic_curchan and manual scan/powersave handling.
The beacon parsing code also checks ic->ic_curchan to determine if the
received beacon is on the correct channel or not.[1]

So:

* add freq/ieee values to ieee80211_rx_stats;
* change ieee80211_parse_beacon() to accept the 'current' channel
as an argument;
* modify the iv_input() and iv_recv_mgmt() methods to include the rx_stats;
* add a new method - ieee80211_lookup_channel_rxstats() - that looks up
a channel based on the contents of ieee80211_rx_stats;
* if it exists, use it in the mgmt path to switch the current channel
(which still defaults to ic->ic_curchan) over to something determined
by rx_stats.

This is enough to kick-start scan offload support in the Intel 7260
driver that Rui/I are working on. It also is a good start for scan
offload support for a handful of existing NICs (wpi, iwn, some USB
parts) and it'll very likely dramatically improve stability/performance
there. It's not the whole thing - notably, we don't need to do powersave,
we should not scan all channels, and we should leave probe request sending
to the firmware and not do it ourselves. But, this allows for continued
development on the above features whilst actually having a somewhat
working NIC.

TODO:

* Finish tidying up how the net80211 input path works.
Right now ieee80211_input / ieee80211_input_all act as the top-level
that everything feeds into; it should change so the MIMO input routines
are those and the legacy routines are phased out.

* The band selection should be done by the driver, not by the net80211
layer.

* ieee80211_lookup_channel_rxstats() only determines 11b or 11g channels
for now - this is enough for scanning, but not 100% true in all cases.
If we ever need to handle off-channel scan support for things like
static-40MHz or static-80MHz, or turbo-G, or half/quarter rates,
then we should extend this.

[1] This is a side effect of frequency-hopping and CCK modes - you
can receive beacons when you think you're on a different channel.
In particular, CCK (which is used by the low 11b rates, eg beacons!)
is decodable from adjacent channels - just at a low SNR.
FH is a side effect of having the hardware/firmware do the frequency
hopping - it may pick up beacons transmitted from other FH networks
that are in a different phase of hopping frequencies.

Use name from ieee80211com instead of parent ifnet, in debugging printfs.

Sponsored by: Netflix
Sponsored by: Nginx, Inc.

Global-ify channel_type() - this fixes non-debug net80211 builds.

Replace 'struct route *' if_output() argument with 'struct nhop_info *'.
Leave 'struct route' as is for legacy routing api users.
Remove most of rtalloc_ign*-derived functions.

Mechanically convert to if_inc_counter().

Undo r195846 for now - allow raw frame transmit in monitor mode.

The original commit was supposed to stop the ability to do raw frame
injection in monitor mode to arbitrary channels (whether supported
by regulatory or not) however it doesn't seem to have been followed
by any useful way of doing it.

Apparently AHDEMO is supposed to be that way, but it seems to require
too much fiddly things (disable scanning, set a garbage SSID, etc)
for it to actually be useful for spoofing things.

So for now let's just disable it and instead look to filter transmit
in the output path if the channel isn't allowed by regulatory.
That way monitor RX works fine but TX will be blocked.

I don't plan on MFC'ing this to -10 until the regulatory enforcement
bits are written.

Allow the state of the interface to be "up" if the VAP is in SLEEP state.

Without this, the carrier will drop when the NIC transitions to SLEEP
and nothing will ever transmit.

The r48589 promised to remove implicit inclusion of if_var.h soon. Prepare
to this event, adding if_var.h to files that do need it. Also, include
all includes that now are included due to implicit pollution via if_var.h

Sponsored by: Netflix
Sponsored by: Nginx, Inc.

Replace the homegrown implementation of nitems() with calls to nitems()
(param.h).

Operating systems that don't have nitems() can easily define it on their own
net80211 OS-specific header file.

Discussed with: adrian

Convert net80211 over to using if_transmit for the dispatch from the
upper layer(s).

This eliminates the if_snd queue from net80211. Yay!

This unfortunately has a few side effects:

* It breaks ALTQ to net80211 for now - sorry everyone, but fixing
parallelism and eliminating the if_snd queue is more important
than supporting this broken traffic scheduling model. :-)

* There's no VAP and IC flush methods just yet - I think I'll add
some NULL methods for now just as placeholders.

* It reduces throughput a little because now net80211 will drop packets
rather than buffer them if the driver doesn't do its own buffering.
This will be addressed in the future as I implement per-node software
queues.

Tested:

* ath(4) and iwn(4) in STA operation

Allow net80211 to compile on stable/9 and stable/8.

Add const qualifier to the dst parameter of the ifnet if_output method.

Bring over my initial work from the net80211 TX locking branch.

This patchset implements a new TX lock, covering both the per-VAP (and
thus per-node) TX locking and the serialisation through to the underlying
physical device.

This implements the hard requirement that frames to the underlying physical
device are scheduled to the underlying device in the same order that they
are processed at the VAP layer. This includes adding extra encapsulation
state (such as sequence numbers and CCMP IV numbers.) Any order mismatch
here will result in dropped packets at the receiver.

There are multiple transmit contexts from the upper protocol layers as well
as the "raw" interface via the management and BPF transmit paths.
All of these need to be correctly serialised or bad behaviour will result
under load.

The specifics:

* add a new TX IC lock - it will eventually just be used for serialisation
to the underlying physical device but for now it's used for both the
VAP encapsulation/serialisation and the physical device dispatch.

This lock is specifically non-recursive.

* Methodize the parent transmit, vap transmit and ic_raw_xmit function
pointers; use lock assertions in the parent/vap transmit routines.

* Add a lock assertion in ieee80211_encap() - the TX lock must be held
here to guarantee sensible behaviour.

* Refactor out the packet sending code from ieee80211_start() - now
ieee80211_start() is just a loop over the ifnet queue and it dispatches
each VAP packet send through ieee80211_start_pkt().

Yes, I will likely rename ieee80211_start_pkt() to something that
better reflects its status as a VAP packet transmit path. More on
that later.

* Add locking around the management and BAR TX sending - to ensure that
encapsulation and TX are done hand-in-hand.

* Add locking in the mesh code - again, to ensure that encapsulation
and mesh transmit are done hand-in-hand.

* Add locking around the power save queue and ageq handling, when
dispatching to the parent interface.

* Add locking around the WDS handoff.

* Add a note in the mesh dispatch code that the TX path needs to be
re-thought-out - right now it's doing a direct parent device transmit
rather than going via the vap layer. It may "work", but it's likely
incorrect (as it bypasses any possible per-node power save and
aggregation handling.)

Why not a per-VAP or per-node lock?

Because in order to ensure per-VAP ordering, we'd have to hold the
VAP lock across parent->if_transmit(). There are a few problems
with this:

* There's some state being setup during each driver transmit - specifically,
the encryption encap / CCMP IV setup. That should eventually be dragged
back into the encapsulation phase but for now it lives in the driver TX path.
This should be locked.

* Two drivers (ath, iwn) re-use the node->ni_txseqs array in order to
allocate sequence numbers when doing transmit aggregation. This should
also be locked.

* Drivers may have multiple frames queued already - so when one calls
if_transmit(), it may end up dispatching multiple frames for different
VAPs/nodes, each needing a different lock when handling that particular
end destination.

So to be "correct" locking-wise, we'd end up needing to grab a VAP or
node lock inside the driver TX path when setting up crypto / AMPDU sequence
numbers, and we may already _have_ a TX lock held - mostly for the same
destination vap/node, but sometimes it'll be for others. That could lead
to LORs and thus deadlocks.

So for now, I'm sticking with an IC TX lock. It has the advantage of
papering over the above and it also has the added advantage that I can
assert that it's being held when doing a parent device transmit.
I'll look at splitting the locks out a bit more later on.

General outstanding net80211 TX path issues / TODO:

* Look into separating out the VAP serialisation and the IC handoff.
It's going to be tricky as parent->if_transmit() doesn't give me the
opportunity to split queuing from driver dispatch. See above.

* Work with monthadar to fix up the mesh transmit path so it doesn't go via
the parent interface when retransmitting frames.

* Push the encryption handling back into the driver, if it's at all
architectually sane to do so. I know it's possible - it's what mac80211
in Linux does.

* Make ieee80211_raw_xmit() queue a frame into VAP or parent queue rather
than doing a short-cut direct into the driver. There are QoS issues
here - you do want your management frames to be encapsulated and pushed
onto the stack sooner than the (large, bursty) amount of data frames
that are queued. But there has to be a saner way to do this.

* Fragments are still broken - drivers need to be upgraded to an if_transmit()
implementation and then fragmentation handling needs to be properly fixed.

Tested:

* STA - AR5416, AR9280, Intel 5300 abgn wifi
* Hostap - AR5416, AR9160, AR9280
* Mesh - some testing by monthadar@, more to come.

Fix up some initial issues with creation and deletion of hotplugged
net80211 devices and vaps.

* vnet sets vnet0 during kldload and device probe/attach, but not for
the hotplug event. Thus, plugging in a NIC causes things to panic.
So, add a CURVNET_SET(vnet0) for now during the attach phase, until
the hotplug code is taught to set CURVNET_SET(vnet0).

* there's also no implied detach vnet context - so teach the detach
path about ifp->if_vnet.

* When creating/deleting vaps, also set the vnet context appropriately.
These can be done at any time.

Now, the problems!

* ieee80211.c is supposed to be OS-portable code, with no OS-specific stuff
like vnet. That should be fixed.

* When the device hotplug code gets taught about CURVNET_SET(vnet0), the
device vnet set can go away; but the VAP vnet set still needs to be there.

* .. and there still is the question about potentially adding an implied
CURVNET_SET(ifp->if_vnet) on if_free(), since any/all devices may end up
being detached by a hotplug event in today's world. That's going to be
a topic of a subsequent commit.

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

Mark the taskqueue as the _net80211_ taskqueue.

This makes it much easier to determine whether an event occurs in the
net80211 taskqueue (which was called "ath0 taskq") or the ath driver
taskqueue (which is also called "ath0 taskq".)

Fix some net80211 enum nits:
- ic_vap_create() uses an ieee80211_opmode argument
- ieee80211_rate2media() takes an ieee80211_phymode argument
- ieee80211_plcp2rate() takes an ieee80211_phytype argument
- cast to enum ieee80211_protmode and ieee80211_roamingmode to silence
compiler warnings

Submitted by: arundel@

While determining the maxrate for ieee80211_media_setup() honor
the device capabilities.

First step on removing the harcoded RX/TX stream and MCS0-15 assumptions.

Initialize ic_rxstream/ic_txstream with 2, for compatibility reasons.
Introduce 4 new HTC flags, which are used in addition to ic_rxstream
and ic_txstream to compute the hc_mcsset content and also for initializing
ni_htrates. The number of spatial streams is enough to determine support
for MCS0-31 but not for MCS32-76 as well as some TX parameters in the
hc_mcsset field.

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.

Instead of using the AMRR ratectl algo as default for drivers which have
the IEEE80211_C_RATECTL flag set, default to NONE for all drivers. Only if
a driver calls ieee80211_ratectl_init() check if the NONE algo is still
selected and try to use AMRR in that case. Drivers are still free to use
any other algo by calling ieee80211_ratectl_set() prior to the
ieee80211_ratectl_init() call.

After this change it is now safe to assume that a ratectl algo is always
available and selected, which renders the IEEE80211_C_RATECTL flag pretty
much useless. Therefore revert r211314 and 211546.

Reviewed by: rpaulo
MFC after: 2 weeks

A new jail(8) with a configuration file, to replace the work currently done
by /etc/rc.d/jail.

Introduce IEEE80211_C_RATECTL, drivers which use the ratectl framework
should set this capability.

MFC after: 2 weeks

MFC r202612

Use the iflladdr_event event to keep the mac address on the vap in sync with
the parent wirless interface. If the user passed in a mac address or it was
autogenerated then flag this to avoid trashing it on update.

This will fix wlan+lagg in a post vap world.

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

net80211 ratectl framework.

Add new tunable 'net.link.ifqmaxlen' to set default send interface
queue length. The default value for this parameter is 50, which is
quite low for many of today's uses and the only way to modify this
parameter right now is to edit if_var.h file. Also add read-only
sysctl with the same name, so that it's possible to retrieve the
current value.

MFC after: 1 month

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

Add a new field for extended HT capabilities.

Submitted by: Alexander Egorenkov <egorenar at gmail.com>
MFC after: 2 weeks
Sponsored by: iXsystems, inc.

Use the iflladdr_event event to keep the mac address on the vap in sync with
the parent wirless interface. If the user passed in a mac address or it was
autogenerated then flag this to avoid trashing it on update.

This will fix wlan+lagg in a post vap world.

Take a step towards removing if_watchdog/if_timer. Don't explicitly set
if_watchdog/if_timer to NULL/0 when initializing an ifnet. if_alloc()
sets those members to NULL/0 already.

MFC r196159:
Drain link state event changes posted during vap destroy. This is a
band-aid for the general problem that if_link_state_change can be
called between if_detach and if_free leaving a task queued that has
been free'd.

Reviewed by: rwatson
Approved by: re (rwatson)

Drain link state event changes posted during vap destroy. This is a
band-aid for the general problem that if_link_state_change can be
called between if_detach and if_free leaving a task queued that has
been free'd.

Spotted by: thompsa
Reviewed by: rwatson
Approved by: re (rwatson)

Filter setting IFF_PROMISC on tdma vaps; we don't want the underyling device
to be in promiscuous mode as we have a h/w bssid.

Approved by: re (kib)

correct handling of IFF_PROMISC; this should not be pushed to the parent
device except for monitor and ahdemo mode vaps

Reviewed by: rpaulo
Approved by: re (kensmith)

monitor mode vaps are meant to be read-only so they can operate on any
frequency w/o regulatory issues, do this by hooking if_transmit and
if_output with routines that discard all transmits

Reviewed by: thompsa, cbzimmer (intent)
Approved by: re (kensmith)

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

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)

Modify most routines returning 'struct ifaddr *' to return references
rather than pointers, requiring callers to properly dispose of those
references. The following routines now return references:

ifaddr_byindex
ifa_ifwithaddr
ifa_ifwithbroadaddr
ifa_ifwithdstaddr
ifa_ifwithnet
ifaof_ifpforaddr
ifa_ifwithroute
ifa_ifwithroute_fib
rt_getifa
rt_getifa_fib
IFP_TO_IA
ip_rtaddr
in6_ifawithifp
in6ifa_ifpforlinklocal
in6ifa_ifpwithaddr
in6_ifadd
carp_iamatch6
ip6_getdstifaddr

Remove unused macro which didn't have required referencing:

IFP_TO_IA6

This closes many small races in which changes to interface
or address lists while an ifaddr was in use could lead to use of freed
memory (etc). In a few cases, add missing if_addr_list locking
required to safely acquire references.

Because of a lack of deep copying support, we accept a race in which
an in6_ifaddr pointed to by mbuf tags and extracted with
ip6_getdstifaddr() doesn't hold a reference while in transmit. Once
we have mbuf tag deep copy support, this can be fixed.

Reviewed by: bz
Obtained from: Apple, Inc. (portions)
MFC after: 6 weeks (portions)

add missing calls to ieee80211_dfs_attach/detach

iv_flags_ext is full, make room by moving HT-related flags to a new
iv_flags_ht word

partially fix mode setting; this no longer returns an error but still
needs to handle the case where the vap is up+running

Noticed by: "Paul B. Mahol" <onemda@gmail.com>

move if_detach to the top of ieee80211_ifdetach to close various races

Reviewed by: jhb

Remove hack used to deal with ifnet teardown now that if_detach and the
bridge do a better job.
o move ether_ifdetach to the top of ieee80211_detach
o do not clear if_softc at the top of ieee80211_detach; we no longer need
this because we are safeguarded against calls coming back through if_ioctl
o simplify the bpf tracker now that we don't null if_softc

This also fixes an issue where having a bpf consumer active when a vap
is destroyed would cause a crash because bpf referenced free'd memory.

Reviewed by: imp

Fix monitor mode vaps to work as intended:
o track # bpf taps on monitor mode vaps instead of # monitor mode vaps
o spam monitor mode taps on tx/rx
o fix ieee80211_radiotap_rx_all to dispatch frames only if the vap is up
o while here print radiotap (and superg) state in show com

Overhaul monitor mode handling:
o replace DLT_IEEE802_11 support in net80211 with DLT_IEEE802_11_RADIO
and remove explicit bpf support from wireless drivers; drivers now
use ieee80211_radiotap_attach to setup shared data structures that
hold the radiotap header for each packet tx/rx
o remove rx timestamp from the rx path; it was used only by the tdma support
for debugging and was mostly useless due to it being 32-bits and mostly
unavailable
o track DLT_IEEE80211_RADIO bpf attachments and maintain per-vap and
per-com state when there are active taps
o track the number of monitor mode vaps
o use bpf tap and monitor mode vap state to decide when to collect radiotap
state and dispatch frames; drivers no longer explicitly directly check
bpf state or use bpf calls to tap frames
o handle radiotap state updates on channel change in net80211; drivers
should not do this (unless they bypass net80211 which is almost always
a mistake)
o update various drivers to be more consistent/correct in handling radiotap
o update ral to include TSF in radiotap'd frames
o add promisc mode callback to wi

Reviewed by: cbzimmer, rpaulo, thompsa

Create a taskqueue for each wireless interface which provides a serialised
sleepable context for net80211 driver callbacks. This removes the need for USB
and firmware based drivers to roll their own code to defer the chip programming
for state changes, scan requests, channel changes and mcast/promisc updates.
When a driver callback completes the hardware state is now guaranteed to have
been updated and is in sync with net80211 layer.

This nukes around 1300 lines of code from the wireless device drivers making
them more readable and less race prone.

The net80211 layer has been updated as follows
- all state/channel changes are serialised on the taskqueue.
- ieee80211_new_state() always queues and can now be called from any context
- scanning runs from a single taskq function and executes to completion. driver
callbacks are synchronous so the channel, phy mode and rx filters are
guaranteed to be set in hardware before probe request frames are
transmitted.

Help and contributions from Sam Leffler.

Reviewed by: sam

Change if_output to take a struct route as its fourth argument in order
to allow passing a cached struct llentry * down to L2

Reviewed by: rwatson

o add ic_rt to track the rate table for the current channel; this enables
calculation of packet transmit times to do things like check txop limits
o remove equivalent driver code and convert to use net80211 state

Eliminate ic_myaddr so changing the mac address of a device works correctly:
o remove ic_myaddr from ieee80211com
o change ieee80211_ifattach to take the mac address of the physical device
and use that to setup the lladdr.
o replace all references to ic_myaddr in drivers by IF_LLADDR
o related cleanups (e.g. kill dead code)

PR: kern/133178
Reviewed by: thompsa, rpaulo

split Atheros SuperG support out into it's own file that's included only
with a new IEEE80211_SUPPORT_SUPERG option

Add modes for 1/2 and 1/4-width channels so we have separate roaming
and xmit parameters. This makes it possible to use tdma on fractional
channels.
o add IEEE80211_MODE_HALF and IEEE80211_MODE_QUARTER; note these are
band-agnostic (may need revisiting)
o setup all default rates in ic_sup_rates instead of doing it only
for active modes; we need these to calculate the default tx parameters
which are not recalculated after a regulatory update (can't just
recalculate after installing a new channel list because we might
clobber user settings)
o remove special case code in ieee80211_get_suprates; this is now
a candidate for an inline or removal
o add various entries for new modes (roaming+tx params, wme, rate
mapping, scan set setup, country ie construction, tdma, basic rates)

Note these modes are intentionally not visible through if_media.

check ptr against NULL

instead of special casing lookups for the 11na/g legacy rate set, just
install the rates once when creating the com structure

remove ic_stats; it was intended to accumulate stats from vaps as they
were reaped but was never used and is inaccessible

Add a ieee80211_waitfor_parent() function that will wait for all deferred
parent interface tasks to complete. This had been added to the ioctl path but
it is also need elsewhere like detach so its safe to teardown.

Reported by: Hans Petter Selasky
Submitted by: sam

When crafting a media setting w/ an auto (non-fixed) rate mask out the
turbo option in addition to the mode bits; otherwise if the current
channel is a turbo mode channel we'll form an invalid media setting
and the ifmedia_set operation in vap_attach will panic.

While here use C99-style initialization for an array indexed by mode;
this makes it consistent w/ other usage and avoids breakage if we
should ever change the set of modes.

setup default rate set for static turbo mode

fill in ieee channel #'s and max tx power for drivers that work exclusively
with frequencies; this mimics how ieee80211_setregdomain works

TDMA support for long distance point-to-point links using ath devices:
o add net80211 support for a tdma vap that is built on top of the
existing adhoc-demo support
o add tdma scheduling of frame transmission to the ath driver; it's
conceivable other devices might be capable of this too in which case
they can make use of the 802.11 protocol additions etc.
o add minor bits to user tools that need to know: ifconfig to setup and
configure, new statistics in athstats, and new debug mask bits

While the architecture can support >2 slots in a TDMA BSS the current
design is intended (and tested) for only 2 slots.

Sponsored by: Intel

Fix definition of IEEE80211_CHAN_MAX; it was defined as 255 but
really was meant to be 256. Adjust usage accordingly and replace
bogus usage of this value in checking IEEE channel #'s.

NB: this causes an ABI change; ifconfig must be recompiled

honor IEEE80211_CLONE_NOBEACONS for type of vap, not just a sta mode vap

o add support for ifconfig wlanX mode foo
o yank useless code for setting fixed rate through media opts: this
mechanism didn't scale to HT rates and couldn't handle multiple bands;
fixed tx rates are set with the IEEE80211_IOC_TXPARAMS ioctl

- Import the HEAD csup code which is the basis for the cvsmode work.

Replace a line matching /^ $/ with one matching /^$/.

Obtained from: //depot/projects/vimage-commit2/...

free ifp allocated at ieee80211_vap_setup.

Reviewed by: sam, thompsa

Revise lock name handling:
o construct a name for the com lock as done for other locks
o pass the device name to IEEE80211_LOCK_INIT so the mtx name
is constructed as foo_com_lock
o introduce *_LOCK_OBJ macro's to hide the lock contents and
minimize redundant code

Minor cleanup of vap create work:
o add IEEE80211_C_STA capability to indicate sta mode is supported
(was previously assumed) and mark drivers as capable
o add ieee80211_opcap array to map an opmode to the equivalent capability bit
o move IEEE80211_C_OPMODE definition to where capabilities are defined so it's
clear it should be kept in sync (on future additions)
o check device capabilities in clone create before trying to create a vap;
this makes driver checks unneeded
o make error codes return on failed clone request unique
o temporarily add console printfs on clone request failures to aid in
debugging; these will move under DIAGNOSTIC or similar before release

use c99-style initialization for ieee80211_phymode_name

add DFS capability bit and use it to auto-enable DFS support

re-enable WME by default; after a full day of testing on iwi I see no
issues and the only way we'll identify them is for people to use it

disable default enabling of WME until we resolve driver regressions

hookup the parent device's if_input and if_output to stub routines
to catch unintended use (one might argue about if_output but it's
behaviour is ill-defined without vap context)

Noticed by: Paul B. Mahol

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 padding for anticipated functionality
- vimage
- TOE
- multiq
- host rtentry caching

Rename spare used by 80211 to if_llsoftc

Reviewed by: rwatson, gnn
MFC after: 1 day

add ieee80211_find_channel_byieee to lookup a channel by ieee channel #

Reviewed by: thompsa
MFC after: 1 week

invalidate ic_prevchan when constructing a new channel list

Approved by: re (blanket wireless)

skip IEEE80211_MODE_AUTO in announcing supported rates in ieee80211_announce;
there won't be any

Approved by: re (blanket wireless)

o add IEEE80211_RATE_MCS to use instead of naked constant (for marking MCS)
o correct ieee80211_rate2media handling of MCS
o correct rate HT announcements for 11n devices

Approved by: re (blanket wireless)

remove IFM_IEEE80211_HT40PLUS and IFM_IEEE80211_HT40MINUS; they
never got used so nuke 'em before we branch

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.

copyright updates:
o update to include 2007
o switch back to a 2-clause bsd-only license

Reviewed by: onoe

change ic_modecaps to a bit vector and use setbit, et. al.

change ieee80211_mhz2ieee to use the PSB mapping when the frequency
falls in the proper place, not when we're handed a 1/2 or 1/4-rate channel

MFC after: 2 weeks

Add initial support for 900MHz cards like the Ubiquiti SR9:
o add channel flag to enable freq <-> ieee channel # mapping (can
go away in the future when ieee number is precomputed)
o add mapping between 900mhz freq's and channel #'s that gives a
unique channel # for each half/quarter/full width channel
o remove assumptions that half/quarter rate channels on happen in 11a
o remove assumptions that all 11g channels are full width
o ensure ic_curchan is reset on mode change so changing the channel
list (e.g. on countrycode change) doesn't leave curchan set to an
invalid channel

There is still an issue with switching rate sets; to be fixed separately.

MFC after: 1 month

Fix compile error.

o unbreak rate set defaulting
o mark 11g mode support on finding 11g or pure 11g (OFDM-only)
channels; was requiring pure 11g which caused some contortions
in drivers that manually setup their channel lists

First cut at half/quarter-rate 11a channel support (e.g. for use
in the Public Safety Band):
o add channel flags to identify half/quarter-rate operation
o add rate sets (need to check spec on 4Mb/s in 1/4 rate)
o add if_media definitions for new rates
o split net80211 channel setup out into ieee80211_chan_init
o fixup ieee80211_mhz2ieee and ieee80211_ieee2mhz to understand half/quarter
rate channels: note we temporarily use a nonstandard/hack numbering that
avoids overlap with 2.4G channels because we don't (yet) have enough
state to identify and/or map overlapping channel sets
o fixup ieee80211_ifmedia_init so it can be called post attach and will
recalculate the channel list and associated state; this enables changing
channel-related state like the regulatory domain after attach (will be
needed for 802.11d support too)
o add ieee80211_get_suprates to return a reference to the supported rate
set for a given channel
o add 3, 4.5, and 27 MB/s tx rates to rate <-> media conversion routines
o const-poison channel arg to ieee80211_chan2mode

Default the rate sets for 802.11 operating modes so drivers aren't
required to. Note this only happens when drivers don't set them
up before calling ieee80211_ifattach so this change is backwards
compatible.

MFC after: 1 month

add support for 802.11 packet injection via bpf

Together with: Andrea Bittau <a.bittau@cs.ucl.ac.uk>
Reviewed by: arch@
MFC after: 1 month

back out public safety-specific channel number mapping; we can't do
it until we know it should be applied as otherwise we can map 11a
channels into the 2.4G range and choose the wrong item from the
chanenl array

o make driver override of net80211 parameter state consistent
with methods: instead of honoring non-zero values expect drivers
to write their own values on return from ieee80211_ifattach
o add a define for the default h/w bmiss count

MFC after: 2 weeks

switch beacon miss threshold from a time to the number of beacon
frames; the time value was implicitly based on the beacon interval
but never being updated so wrong when the negotiated beacon interval
was not 100 TU

correct checking for turbo channels: rev 1.24 fixed static turbo channels
but broke handling of the turboG channel; since we aren't ready to revamp
the channel list just check for turboA channels for now so channel 6 is
considered in auto mode

Noticed by: gibbs

make packet bursting configurable (default to on if device is capable)

o correct auto mode logic for avoiding turbo channels
o correct assumption that a static turbo channel is also
usable in 11a; the opposite is true

MFC after: 1 week

Update ieee80211_mhz2ieee to understand public safety bands and spectrum
that can potentially be mapped to negative ieee #'s.

NB: before operation on the latter can be supported we need to cleanup
various code that assumes ieee channel #'s are >= 0

Clarify/fix handling of the current channel:
o add ic_curchan and use it uniformly for specifying the current
channel instead of overloading ic->ic_bss->ni_chan (or in some
drivers ic_ibss_chan)
o add ieee80211_scanparams structure to encapsulate scanning-related
state captured for rx frames
o move rx beacon+probe response frame handling into separate routines
o change beacon+probe response handling to treat the scan table
more like a scan cache--look for an existing entry before adding
a new one; this combined with ic_curchan use corrects handling of
stations that were previously found at a different channel
o move adhoc neighbor discovery by beacon+probe response frames to
a new ieee80211_add_neighbor routine

Reviewed by: avatar
Tested by: avatar, Michal Mertl
MFC after: 2 weeks

Cleanup beacon/listen interval handling:
o separate configured beacon interval from listen interval; this
avoids potential use of one value for the other (e.g. setting
powersavesleep to 0 clobbers the beacon interval used in hostap
or ibss mode)
o bounds check the beacon interval received in probe response and
beacon frames and drop frames with bogus settings; not clear
if we should instead clamp the value as any alteration would
result in mismatched sta+ap configuration and probably be more
confusing (don't want to log to the console but perhaps ok with
rate limiting)
o while here up max beacon interval to reflect WiFi standard

Noticed by: Martin <nakal@nurfuerspam.de>
MFC after: 1 week

diff reduction against p4: define IEEE80211_FIXED_RATE_NONE and use
it instead of -1

supply a default ic_reset method for drivers; the ioctl code expect this
method to always be setup

Submitted by: Tai-hwa Liang

statically allocate the station/neighbor node table; the deferred
allocation scheme introduced a race condition during device state
transitions

bump copyright for 2005

disable default use of wme until we can sort out interoperability issues;
users that want it can explicitly enable it

expose ieee80211_phymode_name for use in debug msgs

Update 802.11 support; too much new functionality to fully describe
here but it includes completed 802.11g, WPA, 802.11i, 802.1x, WME/WMM,
AP-side power-save, crypto plugin framework, authenticator plugin framework,
and access control plugin frameowrk.

Add some missing <sys/module.h> includes which are masked by the
one on death-row in <sys/kernel.h>

Link state change notification of ethernet media to the routing socket.

o The ieee80211_media_status() function updates the ifi_link_state field
and calls rt_ifmsg() to notify listeners on the routing socket.

Approved by: sam

diff reduction against madwifi/p4

Add explicit dependency on "ether", since we use ether_ifattach().

Add support for FH phy, which will be used by awi driver.
Also some if_media constants to indicate operational mode are changed
to bitmasks to reduce diffs from NetBSD.

short preamble capability is not just for 11g; mark IEEE80211_F_SHPREAMBLE
regardless of the operating mode

Obtained from: MADWIFI

Delay creating ic_bss until after the super-class has a chance
to override the method pointers for manipulating nodes; this fixes
a problem where the ic_bss node was not being created properly
for the ath driver causing the driver to scribble on random memory.

Noticed by: David Young <dyoung@pobox.com>

add monitor mode

o change ieee80211_new_state handling to use a proper method that drivers
override in their sub-class; this eliminates the hack of interpreting the
EINPROGRESS return value to mean "don't do any of the normal work"
o correct active scanning so the first channel is only scanned once and so
per-channel passive mode is properly honored
o expose 802.11 FSM state names so every driver doesn't keep a private copy
o eliminate node parameter to ieee80211_begin_scan; it was not being used

add safeguard against (bogus) null channel parameter

revise copyright notices per discussion with Atsushi Onoe <onoe@sm.sony.co.jp>

fix typo

Submitted by: "Norman Diamond \(ITS\)" <n_diamond@its.jp>

new 802.11 layer:

o code reorg (relative to old netbsd-derived code) for future growth
o drivers now specify available channels and rates and 802.11 layer handles
almost all ifmedia actions
o multi-mode support for 11a/b/g devices
o 11g protocol additions (incomplete)
o new element id additions (for other than 11g)
o node/station table redone for proper locking and to eliminate driver
incestuousness
o split device flags and capabilities to reduce confusion and provide room
for expansion
o incomplete power management infrastructure (need to revisit)
o incomplete hooks for software retry
o more...