According to 802.11-2012 9.3.2.10, paragraph 4, QoS
data frames with a group address in the Address 1 field
have sequence numbers allocated from the same counter
as non-QoS data and management frames.  Without this
flag, some drivers may not assign sequence numbers, and
in rare cases frames might get dropped.  Set the control
flag accordingly.
Signed-off-by: NBob Copeland <bob@cozybit.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

Previously, the mesh STA responds to probe request from legacy STA
but now it will only respond to legacy STA if the legacy STA does include
the specific mesh ID or wildcard mesh ID in the probe request.

The iw patch "iw: scan using meshid" can be used either by legacy STA
or by mesh STA to do active scanning by inserting the mesh ID in the
probe request frame.
Signed-off-by: NChun-Yeow Yeoh <yeohchunyeow@cozybit.com>
Acked-by: NThomas Pedersen <thomas@cozybit.com>
Acked-by: NJavier Cardona <javier@cozybit.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

mac80211 currently sets WIPHY_FLAG_SUPPORTS_SCHED_SCAN based on whether
the start_sched_scan operation is supported or not, but that will not
be correct for all drivers, we're adding scheduled scan to the iwlmvm
driver but it depends on firmware support.

Therefore, move setting WIPHY_FLAG_SUPPORTS_SCHED_SCAN into the drivers
so that they can control it regardless of implementing the operation.

This currently only affects the TI drivers since they're the only ones
implementing scheduled scan (in a mac80211 driver.)
Acked-by: NLuciano Coelho <luca@coelho.fi>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

Sujith reports that my commit af61a165
("mac80211: add control port protocol TX control flag") broke ath9k
(aggregation). The reason is that I made minstrel_ht use the flag in
the TX status path, where it can have been overwritten by the driver.
Since we have no more space in info->flags, revert that part of the
change for now, until we can reshuffle the flags or so.
Reported-by: NSujith Manoharan <c_manoha@qca.qualcomm.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

In order to be able to (securely) keep connections alive after
the system was suspended for WoWLAN, we need some additional
APIs. We already have API (ieee80211_gtk_rekey_notify) to tell
wpa_supplicant about the new replay counter if GTK rekeying
was done by the device while the host was asleep, but that's
not sufficient.

If GTK rekeying wasn't done, we need to tell the host about
sequence counters for the GTK (and PTK regardless of rekeying)
that was used while asleep, add ieee80211_set_key_rx_seq() for
that.

If GTK rekeying was done, then we need to be able to disable
the old keys (with ieee80211_remove_key()) and allocate the
new GTK key(s) in mac80211 (with ieee80211_gtk_rekey_add()).

If protocol offload (e.g. ARP) is implemented, then also the
TX sequence counter for the PTK must be updated, using the new
ieee80211_set_key_tx_seq() function.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

Channel Switch will later require to generate beacons without setting
them immediately. Therefore split the presp generation in an own
function. Splitting the original very long function might be a good idea
anyway.
Signed-off-by: NSimon Wunderlich <siwu@hrz.tu-chemnitz.de>
Signed-off-by: NMathias Kretschmer <mathias.kretschmer@fokus.fraunhofer.de>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

This patch decouples the power save processing from the frame decryption
by running the decrypt rx handler after sta_process. In the case where
the decryption failed for some reason, the stack used to not process
the PM and MOREDATA bits for that frame. The stack now always performs
power save processing regardless of the decryption result. That means that
encrypted data frames and NULLFUNC frames are now handled in the same way
regarding power save processing, making the stack more robust.
Signed-off-by: NJohan Almbladh <ja@anyfi.net>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

Function regulator_enable() may return an error that has to be checked.
This patch changes function rfkill_regulator_set_block() so that it checks
for the return code.  Also, rfkill_data->reg_enabled is set to 'true' only
if there is no error.

This fixes the following compilation warning:

net/rfkill/rfkill-regulator.c:43:20: warning: ignoring return value of 'regulator_enable', declared with attribute warn_unused_result [-Wunused-result]
Signed-off-by: NLuis Henriques <luis.henriques@canonical.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

In some cases mac80211 will scan before creating an IBSS
even if bssid and frequency have been forced by the user.
This is not needed and leads only to a delay in the IBSS
establishment phase.

Immediately create the cell if both bssid and frequency
(and fixed_freq is set) have been specified.
Signed-off-by: NAntonio Quartulli <antonio@open-mesh.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

Pass the wdev from cfg80211 on to the driver as the vif
if given and it's valid for the driver.
Signed-off-by: NDavid Spinadel <david.spinadel@intel.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

To allow drivers to implement per-interface testmode operations
more easily, pass a wdev pointer if any identification for one
was given from userspace. Clean up the code a bit while at it.
Signed-off-by: NDavid Spinadel <david.spinadel@intel.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

A lot of drivers check the frame protocol for ETH_P_PAE,
for various reasons (like making those more reliable).
Add a new flags bitmap to the TX control info and a new
flag indicating the control port protocol is in use to
let all drivers also apply such logic to other control
port protocols, should they be configured.

Also use the new flag in the iwlwifi drivers.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

Clean up the CQM settings code a bit and while at it
enforce that when setting the threshold to 0 (disable)
the hysteresis is also set to 0 to avoid confusion.
As we haven't enforce it, simply override userspace.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

Signed-off-by: NSimon Wunderlich <siwu@hrz.tu-chemnitz.de>
Signed-off-by: NMathias Kretschmer <mathias.kretschmer@fokus.fraunhofer.de>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

Allow lowest basic rate to be used for unicast management frame in
mesh. Otherwise, the lowest supported rate is used for unicast
management frame, such as 1Mbps for 2.4GHz and 6Mbps for 5GHz. Rename
the rc_send_low_broadcast to re_send_low_basicrate since now it is
also applied to unicast management frame in mesh.
Signed-off-by: NChun-Yeow Yeoh <yeohchunyeow@cozybit.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

A few places in the code (mac80211 and iwlmvm) use the same
TU_TO_JIFFIES() macro and could use TU_TO_EXP_TIME() that
mac80211 has. Make these available to everyone and use them.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

The count field in CSA must be decremented with each beacon
transmitted. This patch implements the functionality for drivers
using ieee80211_beacon_get(). Other drivers must call back manually
after reaching count == 0.

This patch also contains the handling and finish worker for the channel
switch command, and mac80211/chanctx code to allow to change a channel
definition of an active channel context.
Signed-off-by: NSimon Wunderlich <siwu@hrz.tu-chemnitz.de>
Signed-off-by: NMathias Kretschmer <mathias.kretschmer@fokus.fraunhofer.de>
[small cleanups, catch identical chandef]
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

To allow channel switch announcements within beacons, add
the channel switch command to nl80211/cfg80211. This is
implementation is intended for AP and (later) IBSS mode.
Signed-off-by: NSimon Wunderlich <siwu@hrz.tu-chemnitz.de>
Signed-off-by: NMathias Kretschmer <mathias.kretschmer@fokus.fraunhofer.de>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

Add a per-station debugfs file indicating the TIDs (as
a bitmap) that the driver has data buffered on.
Reviewed-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

The radiotap VHT info is 12 bytes (required to be aligned on 2) :
u16 known - IEEE80211_RADIOTAP_VHT_KNOWN_*
u8 flags - IEEE80211_RADIOTAP_VHT_FLAG_*
u8 bandwidth
u8 mcs_nss[4]
u8 coding
u8 group_id
u16 partial_aid

ATM mac80211 can handle IEEE80211_RADIOTAP_VHT_KNOWN_{GI,BANDWIDTH} and
mcs_nss[0] (i.e single user) in simple cases.
This is more a placeholder to let sniffers give more clues for VHT,
since we don't have yet the proper infrastructure/conventions
in mac80211 for complete feedback (e.g consider dynamic BW).
Signed-off-by: NKarl Beldan <karl.beldan@rivierawaves.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

Add element IDs for Extended BSS Load, VHT TX
Power Envelope, AID, and Quiet Channel.
Signed-off-by: NFred Zhou <fred.zy@gmail.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

IEEE802.11u interworking support is advertised via extended
capabilities IE bit 31. This is 7th bit of 4th byte of extended
capabilities.
Signed-off-by: NAvinash Patil <patila@marvell.com>
Signed-off-by: NBing Zhao <bzhao@marvell.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

A station which is not authorized has to be purged earlier
to give it a chance to re-try to establish an IBSS/RSN
session soon. Set the timeout to 10 seconds.

Some refactoring has also been done to allow the IBSS
submodule to have its own expiring function.
Reported-by: NSimon Wunderlich <siwu@hrz.tu-chemnitz.de>
Signed-off-by: NAntonio Quartulli <antonio@open-mesh.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

Change mac80211 LED trigger code to use the generic
led_trigger_blink_oneshot() API for transmit and receive activity
indication.

This gives a better feedback to the user, as with the new API each
activity event results in a visible blink, while a constant traffic
results in a continuous blink at constant rate.
Signed-off-by: NFabio Baltieri <fabio.baltieri@gmail.com>
[fix LED disabled build error]
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

When a driver (like hwsim) uses HW queue control an
active monitor vif needs to be used for the queues,
make the code do that. Otherwise we'd bail out and
drop the frames.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

It seems to actually work this way already, so we
may need to do some work to make monitor interfaces
be _not_ active in hwsim instead.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

Since mac80211 does everything, we can just claim it.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

These are only strange error cases, so it's not really
all that important, but the driver really should use
ieee80211_free_txskb() instead of just dev_kfree_skb().
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

Set the Forwarding bit in Mesh Capability Info according
to dot11MeshForwarding as defined in IEEE 802.11-2012
section 8.4.2.100.8.
Signed-off-by: NChun-Yeow Yeoh <yeohchunyeow@gmail.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

There is an off-by-one error in the beacon generation for the ibss mode,
falsely a rate the extended supported rates which was already added to
supported rates, messing up the beacon. This was introduced by commit
"mac80211: select and adjust bitrates according to channel mode".
Signed-off-by: NSimon Wunderlich <siwu@hrz.tu-chemnitz.de>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

There appear to be two regressions in ibss.c when calling
ieee80211_sta_def_wmm_params():
 * the second argument should be a rate length, not a rate array. This
   was introduced by my commit "mac80211: select and adjust bitrates
   according to channel mode"
 * the third argument is not initialized (anymore), making further
   checks within this function useless.

Since ieee80211_sta_def_wmm_params() is only used by ibss anyway,
remove the function entirely and handle the operating mode decision
immediately.
Signed-off-by: NSimon Wunderlich <siwu@hrz.tu-chemnitz.de>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

Whether the wiphy supports it or not is already checked, so what is left
is to enable these channel types.
Signed-off-by: NSimon Wunderlich <siwu@hrz.tu-chemnitz.de>
Signed-off-by: NMathias Kretschmer <mathias.kretschmer@fokus.fraunhofer.de>
Signed-off-by: NJohannes Berg <johannes@sipsolutions.net>

This was originally designed to fail when a 40+/40- mode can not be
used, but basic modes (such as 5/10/20 MHz) must be handled
with an error.
Signed-off-by: NSimon Wunderlich <siwu@hrz.tu-chemnitz.de>
Signed-off-by: NJohannes Berg <johannes@sipsolutions.net>

Use a chandef instead of just the channel for scanning, and enable
5/10 Mhz scanning for IBSS mode. Also reporting is changed to the new
inform_bss functions.
Signed-off-by: NSimon Wunderlich <siwu@hrz.tu-chemnitz.de>
Signed-off-by: NMathias Kretschmer <mathias.kretschmer@fokus.fraunhofer.de>
Signed-off-by: NJohannes Berg <johannes@sipsolutions.net>

Some regulations (like germany, but also FCC) express their transmission
power limit in dBm/MHz or mW/MHz. To cope with that and be on the safe
side, reduce the maximum power to half (10 MHz) or quarter (5 MHz)
when operating on these reduced bandwidth channels.
Signed-off-by: NSimon Wunderlich <siwu@hrz.tu-chemnitz.de>
Signed-off-by: NMathias Kretschmer <mathias.kretschmer@fokus.fraunhofer.de>
Signed-off-by: NJohannes Berg <johannes@sipsolutions.net>

Mandatory rates for 5 and 10 MHz are different from the rates used for
20 MHz in 2.4 GHz mode, as they use OFDM only.
Signed-off-by: NSimon Wunderlich <siwu@hrz.tu-chemnitz.de>
Signed-off-by: NMathias Kretschmer <mathias.kretschmer@fokus.fraunhofer.de>
Signed-off-by: NJohannes Berg <johannes@sipsolutions.net>

The various components accessing the bitrates table must use consider
the used channel bandwidth to select only available rates or calculate
the bitrate correctly.

There are some rates in reduced bandwidth modes which can't be
represented as multiples of 500kbps, like 2.25 MBit/s in 5 MHz mode. The
standard suggests to round up to the next multiple of 500kbps, just do
that in mac80211 as well.
Signed-off-by: NSimon Wunderlich <siwu@hrz.tu-chemnitz.de>
Signed-off-by: NMathias Kretschmer <mathias.kretschmer@fokus.fraunhofer.de>
[make rate unsigned in ieee80211_add_tx_radiotap_header(), squash fix]
Signed-off-by: NJohannes Berg <johannes@sipsolutions.net>

Wireshark already defines radiotap channel flags for 5 and 10 MHz, so
just use them in Linux radiotap too. Furthermore, add rx status flags to
allow drivers to report when they received data on 5 or 10 MHz channels.
Signed-off-by: NSimon Wunderlich <siwu@hrz.tu-chemnitz.de>
Signed-off-by: NMathias Kretschmer <mathias.kretschmer@fokus.fraunhofer.de>
Signed-off-by: NJohannes Berg <johannes@sipsolutions.net>

according to IEEE 802.11-2012 section 18, various timings change
when using 5 MHz and 10 MHz. Reflect this by using a "shift" when
calculating durations.
Signed-off-by: NSimon Wunderlich <siwu@hrz.tu-chemnitz.de>
Signed-off-by: NMathias Kretschmer <mathias.kretschmer@fokus.fraunhofer.de>
Signed-off-by: NJohannes Berg <johannes@sipsolutions.net>

5 and 10 MHz support needs to know the current operating channel width,
add the chandef to the rate control API.
Signed-off-by: NSimon Wunderlich <siwu@hrz.tu-chemnitz.de>
Signed-off-by: NMathias Kretschmer <mathias.kretschmer@fokus.fraunhofer.de>
Signed-off-by: NJohannes Berg <johannes@sipsolutions.net>