Several tracepoints are using STA_PR_FMT where STA_PR_ARG should be
used, resulting in messages like "phy0 sta:ARG TYPE NOT FIELD BUT 1".
Change these to STA_PR_ARG.
Signed-off-by: NSeth Forshee <seth.forshee@canonical.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

Since mesh powersaving was added, pending bcast/mcast frames may go out the
CAB queue now.  Unfortunately, the queue was only set up for AP mode, so we
would try to tx on the IEEE80211_INVAL_HW_QUEUE.  Allow cab_queue for mesh
interfaces as well.

Fixes the following warning (or crash without MAC80211_VERBOSE_DEBUG):

WARNING: at net/mac80211/tx.c:1223 __ieee80211_tx+0x162/0x35f [mac80211]()
Modules linked in: mac80211_hwsim mac80211 cfg80211 [...]
Pid: 3085, comm: avahi-daemon Tainted: G        W    3.8.0-rc1+ #377
Call Trace:
 [<ffffffff81045c20>] warn_slowpath_common+0x83/0x9c
 [<ffffffff81045c53>] warn_slowpath_null+0x1a/0x1c
 [<ffffffffa083aef0>] __ieee80211_tx+0x162/0x35f [mac80211]
 [<ffffffffa083cb1d>] ieee80211_tx+0xd3/0xf9 [mac80211]
 [<ffffffffa083cc0f>] ieee80211_xmit+0xcc/0xd5 [mac80211]
 [<ffffffffa083db59>] ieee80211_subif_start_xmit+0xc53/0xcd8 [mac80211]
 [<ffffffff81319acd>] dev_hard_start_xmit+0x259/0x3ce
 [<ffffffff81333d6b>] sch_direct_xmit+0x74/0x17d
 [<ffffffff8131a0b1>] dev_queue_xmit+0x230/0x414
 [<ffffffff8134877a>] ip_finish_output2+0x348/0x3aa
 [<ffffffff81349029>] ip_finish_output+0x6c/0x71
 [<ffffffff81349046>] NF_HOOK_COND.constprop.44+0x18/0x58
 [<ffffffff8134a03a>] ip_mc_output+0x134/0x13c
 [<ffffffff8134835a>] dst_output+0x18/0x1c
 [<ffffffff81349a24>] ip_local_out+0x20/0x24
 [<ffffffff8134a8cf>] ip_send_skb+0x16/0x3c
 [<ffffffff8136bfba>] udp_send_skb+0x254/0x2b9
 [<ffffffff8136c85e>] udp_sendmsg+0x5a8/0x7d4
Signed-off-by: NBob Copeland <bob@cozybit.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

There's various code with strange indentation,
questionable loop and locking constructs, etc.

The bigger change is moving the "sdata" argument
to the first argument of all functions, like all
other mac80211 functions that have one.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

Even when connecting to an AP that doesn't support VHT,
and even when the local device doesn't support it either,
the downgrade message gets printed. Suppress the message
if HT and/or VHT is disabled.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

Adding the flag to mac80211 already without testing was
clearly a mistake, one that we now pay for by having to
reserve bit 13 forever. The problem is cfg80211 doesn't
allow capability/rate changes for station entries that
were added unassociated, so the station entries cannot
be set up properly when marked associated.

Change the NL80211_FEATURE_FULL_AP_CLIENT_STATE value
to make it clear to userspace implementations that all
current kernels don't actually support it, even though
the previous bit is set, and of course also remove the
flag from mac80211 until we test and fix the issues.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

The information of the peer's capabilities is required for the driver
to perform TDLS Peer UAPSD operations. This information of the peer is
passed by the supplicant using NL80211_CMD_SET_STATION command. This
commit enhances the function nl80211_set_station to pass this
information of the peer to the driver in case this command is used
with the TDLS peer STA.

In addition, make the HT/VHT capability configuration handled more
consistently for other STA cases (reject both instead of just HT).
Signed-off-by: NJouni Malinen <jouni@qca.qualcomm.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

Use the new extended capabilities advertising to advertise
the fact that operating mode notification is supported.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

Instead of modifying the HT SMPS capability field
for stations, track the SMPS mode explicitly in a
new field in the station struct and use it in the
drivers that care about it. This simplifies the
code using it.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

Mesh interfaces will now respond to any broadcast (or
matching directed mesh) probe requests with a probe
response.
Signed-off-by: NThomas Pedersen <thomas@cozybit.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

Previously, the entire mesh beacon would be generated each
time the beacon timer fired. Instead generate a beacon
head and tail (so the TIM can easily be inserted when mesh
power save is on) when starting a mesh or the MBSS
parameters change.

Also add a mutex for protecting beacon updates and
preventing leaks.
Signed-off-by: NThomas Pedersen <thomas@cozybit.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

Make all the parsed IE pointers const, and propagate
the change to all the users etc.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

A while ago, I made the mac80211 station code never change
the channel type after association. This solved a number of
issues but is ultimately wrong, we should react if the AP
changes the HT operation IE and switches bandwidth. One of
the issues is that we associate as HT40 capable, but if the
AP ever switches to 40 MHz we won't be able to receive such
frames because we never set our channel to 40 MHz.

This addresses this and VHT operation changes. If there's a
change that is incompatible with our setup, e.g. if the AP
decides to change the channel entirely (and for some reason
we still hear the beacon) we'll just disconnect.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

The next patch will need it further up in the file, so
move it unchanged now.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

For HT and VHT the current bandwidth can change,
add the function ieee80211_vif_change_bandwidth()
to take care of this. It returns a failure if the
new bandwidth isn't compatible with the existing
channel context, the caller has to handle that.
When it happens, also inform the driver that the
bandwidth changed for this virtual interface (no
drivers would actually care today though.)

Changing to/from HT/VHT isn't allowed though.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

The channel use is confusing, some uses the channel
context and some the bss_conf.chandef. The latter is
fine, so get rid of the channel context part.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

Having HT/VHT operation IEs but not capability IEs
leads to a strange situation where we configure the
channel to an HT or VHT bandwidth and then can't
actually use it. Prevent this by checking that the
HT and VHT capability IEs are present as well as
the operation IEs; if not, disable HT and/or VHT.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

In beacons and association response frames an AP may include an
operating mode notification element to advertise changes in the
number of spatial streams it can receive. Handle this using the
existing function that handles the action frame, but only handle
NSS changes, not bandwidth changes which aren't allowed here.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

This should be called ieee80211_change_chanctx() since
it changes the channel context, not a chandef.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

The code to disable HT and VHT if VHT was advertised
without VHT is wrong -- it accidentally uses the wrong
flags. Fix that.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

In case of connection, the station data is initialised from
the beacon/probe response first and then updated from the
association response. If the latter is different we update
the rate control algorithm and driver. Instead of doing it
this way, set the station data properly with data from the
association response before initializing rate control.

Also simplify the code by passing the station pointer.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

Handle the operating mode notification action frame.
When the supported streams or the bandwidth change
let the driver and rate control algorithm know.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

With VHT, a station can change the number of spatial
streams it can receive on the fly, not unlike spatial
multiplexing in HT. Prepare for that by tracking the
maximum number of spatial streams it can receive when
the connection is established.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

For VHT, many more bandwidth changes are possible. As a first
step, stop toggling the IEEE80211_HT_CAP_SUP_WIDTH_20_40 flag
in the HT capabilities and instead introduce a bandwidth field
indicating the currently usable bandwidth to transmit to the
station. Of course, make all drivers use it.

To achieve this, make ieee80211_ht_cap_ie_to_sta_ht_cap() get
the station as an argument, rather than the new capabilities,
so it can set up the new bandwidth field.

If the station is a VHT station and VHT bandwidth is in use,
also set the bandwidth accordingly.

Doing this allows us to get rid of the supports_40mhz flag as
the HT capabilities now reflect the true capability instead of
the current setting.

While at it, also fix ieee80211_ht_cap_ie_to_sta_ht_cap() to not
ignore HT cap overrides when MCS TX isn't supported (not that it
really happens...)
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

Like with HT, make things a bit simpler in future patches by
passing the station to ieee80211_vht_cap_ie_to_sta_vht_cap()
instead of the vht_cap pointer. Also disable VHT here if HT
isn't supported.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

Since no driver calls the TKIP functions from interrupt
context, there's no need to use spin_lock_irqsave().
Just use spin_lock_bh() (and spin_lock() in the TX path
where we're in a BH or they're already disabled.)
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

There's no need to use _irqsave() as the lock
is never used in interrupt context.

This also fixes a problem in the iwlwifi MVM
driver that calls spin_unlock_bh() within its
set_tim() callback.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

There's no use for it, WPA is entirely handled in
wpa_supplicant in userspace, so don't pick the IE.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

In some cases when disconnecting after (or during?) CSA
the queues might not recover, and then the only way to
recover is reloading the module.

Fix this by always unblocking the queue CSA reason when
disconnecting.

Cc: stable@vger.kernel.org
Reported-by: NJan-Michael Brummer <jan.brummer@tabos.org>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

Since the idle decision rework, mac80211 started calling
bss_info_changed() for the driver's monitor interface,
which causes a crash for iwlwifi, but drivers generally
don't expect this to happen. Therefore, avoid it.

While at it, also prevent calling it in such cases and
only print a warning. For the P2P Device interface the
idle will no longer be called (no channel context), so
also prevent that and warn on it.
Reported-by: NChaitanya <chaitanya.mgit@gmail.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

In my commit 1672c0e3
("mac80211: start auth/assoc timeout on frame status")
I broke auth/assoc timeout handling: in case we wait
for the TX status, it now leaves the timeout field set
to 0, which is a valid time and can compare as being
before now ("jiffies"). Thus, if the work struct runs
for some other reason, the auth/assoc is treated as
having timed out.

Fix this by introducing a separate "timeout_started"
variable that tracks whether the timeout has started
and is checked before timing out.

Additionally, for proper TX status handling the change
requires that the skb->dev pointer is set up for all
the frames, so set it up for all frames in mac80211.
Reported-by: NWojciech Dubowik <Wojciech.Dubowik@neratec.com>
Tested-by: NWojciech Dubowik <Wojciech.Dubowik@neratec.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

Function ieee80211_sta_reset_conn_monitor has been
resetting probe_send_count too early and nullfunc
check was never called after succesfull ack.
Reported-by: NMagnus Cederlöf <mcider@gmail.com>
Tested-by: NMagnus Cederlöf <mcider@gmail.com>
Signed-off-by: NWojciech Dubowik <Wojciech.Dubowik@neratec.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

A few mesh utility functions will call
ieee80211_bss_info_change_notify(), and then the caller
might notify the driver of the same change again. Avoid
this redundancy by propagating the BSS changes and
generally calling bss_info_change_notify() once per
change.
Signed-off-by: NThomas Pedersen <thomas@cozybit.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

When sending a broadcast while at least on of the connected stations is
sleeping, it gets queued and send after a DTIM beacon is sent.
If the packet was to be sent on a vlan interface, the vif used for dequeing
from the per-bss queue does not hold the per-vlan sdata. The correct sdata is
required to use the correct per-vlan broadcast/multicast key.

This patch fixes this by restoring the per-vlan sdata using the skb->dev entry.
Signed-off-by: NMichael Braun <michael-dev@fami-braun.de>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

When the vlan device is removed, ps->bc_buf processing can no longer
send its frames.
Signed-off-by: NMichael Braun <michael-dev@fami-braun.de>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

Add command to trigger radar detection in the driver/FW.
Once radar detection is started it should continuously
monitor for radars as long as the channel active.
If radar is detected usermode notified with 'radar
detected' event.

Scanning and remain on channel functionality must be disabled
while doing radar detection/scanning, and vice versa.

Based on original patch by Victor Goldenshtein <victorg@ti.com>
Signed-off-by: NSimon Wunderlich <siwu@hrz.tu-chemnitz.de>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

When MCS rates start to get bad in 2.4 GHz because of long range or
strong interference, CCK rates can be a lot more robust.

This patch adds a pseudo MCS group containing CCK rates (long preamble
in the lower 4 slots, short preamble in the upper slots).
Signed-off-by: NFelix Fietkau <nbd@openwrt.org>
[make minstrel_ht_get_stats static]
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

Bail out if no update is made to the SMPS state. This
allows the driver to avoid duplicating the state.
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

We've got a couple of races when enabling powersave with an AP for
off-channel operation. The first is fairly simple. If we go off-channel
before the nullfunc frame to enable PS is transmitted then it may not be
received by the AP. Add a flush after enabling off-channel PS to prevent
this from happening.

The second race is a bit more subtle. If the driver supports QoS and has
frames queued when the nullfunc frame is queued, those frames may get
transmitted after the nullfunc frame. If PM is not set then the AP is
being told that we've exited PS before we go off-channel and may try to
deliver frames. To prevent this, add a flush after stopping the queues
but before passing the nullfunc frame to the driver.
Signed-off-by: NSeth Forshee <seth.forshee@canonical.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

Scans currently work by stopping the netdev tx queues but leaving the
mac80211 queues active. This stops the flow of incoming packets while
still allowing mac80211 to transmit nullfunc and probe request frames to
facilitate scanning. However, the driver may try to wake the mac80211
queues while in this state, which will also wake the netdev queues.

To prevent this, add a new queue stop reason,
IEEE80211_QUEUE_STOP_REASON_OFFCHANNEL, to be used when stopping the tx
queues for off-channel operation. This prevents the netdev queues from
waking when a driver wakes the mac80211 queues.

This also stops all frames from being transmitted, even those meant to
be sent off-channel. Add a new tx control flag,
IEEE80211_TX_CTL_OFFCHAN_TX_OK, which allows frames to be transmitted
when the queues are stopped only for the off-channel stop reason. Update
all locations transmitting off-channel frames to use this flag.
Signed-off-by: NSeth Forshee <seth.forshee@canonical.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

It's more of an unnecessary micro-optimization and it prevents switching
from long-GI to short-GI in HT20/single-stream for the lowest rate
Signed-off-by: NFelix Fietkau <nbd@openwrt.org>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>