This patch enables 40MHz bandwidth in 2GHz band after checking whether
cfg80211 allows it or not, and enables OBSS scanning operations to
to support 20/40 BSS coexistence.
Reviewed-by: Arend Van Spriel <arend@broadcom.com>
Reviewed-by: Hante Meuleman <meuleman@broadcom.com>
Reviewed-by: Pieter-Paul Giesberts <pieterpg@broadcom.com>
Signed-off-by: Daniel Kim <dekim@broadcom.com>
Signed-off-by: Arend van Spriel <arend@broadcom.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

Merge branch 'for-upstream' of git://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth-next

In Secure Connections Only mode, it is required that Secure Connections
is used for pairing and that the link key is encrypted with AES-CCM using
a P-256 authenticated combination key. If this is not the case, then new
connection shall be refused or existing connections shall be dropped.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>

It is possible that pairing fails after we've already received remote
identity information. One example of such a situation is when
re-encryption using the LTK fails. In this case the hci_conn object has
already been updated with the identity address but user space does not
yet know about it (since we didn't notify it of the new IRK yet).

To ensure user space doesn't get a Pair Device command response with an
unknown address always use the same address in the response as was used
for the original command.
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>

When performing SMP pairing with MITM protection one side needs to
enter the passkey while the other side displays to the user what needs
to be entered. Nowhere in the SMP specification does it say that the
displaying side needs to any kind of confirmation of the passkey, even
though a code comment in smp.c implies this.

This patch removes the misleading comment and converts the code to use
the passkey notification mgmt event instead of the passkey confirmation
mgmt event.
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>

In some cases the current 250ms delay is not enough for the remote to
receive the keys, as can be witnessed by the following log:

> ACL Data RX: Handle 64 flags 0x02 dlen 21               [hci1] 231.414217
      SMP: Signing Information (0x0a) len 16
        Signature key: 555bb66b7ab3abc9d5c287c97fe6eb29
< ACL Data TX: Handle 64 flags 0x00 dlen 21               [hci1] 231.414414
      SMP: Encryption Information (0x06) len 16
        Long term key: 2a7cdc233c9a4b1f3ed31dd9843fea29
< ACL Data TX: Handle 64 flags 0x00 dlen 15               [hci1] 231.414466
      SMP: Master Identification (0x07) len 10
        EDIV: 0xeccc
        Rand: 0x322e0ef50bd9308a
< ACL Data TX: Handle 64 flags 0x00 dlen 21               [hci1] 231.414505
      SMP: Signing Information (0x0a) len 16
        Signature key: bbda1b2076e2325aa66fbcdd5388f745
> HCI Event: Number of Completed Packets (0x13) plen 5    [hci1] 231.483130
        Num handles: 1
        Handle: 64
        Count: 2
< HCI Command: LE Start Encryption (0x08|0x0019) plen 28  [hci1] 231.664211
        Handle: 64
        Random number: 0x5052ad2b75fed54b
        Encrypted diversifier: 0xb7c2
        Long term key: a336ede66711b49a84bde9b41426692e
> HCI Event: Command Status (0x0f) plen 4                 [hci1] 231.666937
      LE Start Encryption (0x08|0x0019) ncmd 1
        Status: Success (0x00)
> HCI Event: Number of Completed Packets (0x13) plen 5    [hci1] 231.712646
        Num handles: 1
        Handle: 64
        Count: 1
> HCI Event: Disconnect Complete (0x05) plen 4            [hci1] 232.562587
        Status: Success (0x00)
        Handle: 64
        Reason: Remote User Terminated Connection (0x13)

As can be seen, the last key (Signing Information) is sent at 231.414505
but the completed packets event for it comes only at 231.712646,
i.e. roughly 298ms later.

To have a better margin of error this patch increases the delay to
500ms.
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>

This is a trivial coding style simplification by instead of having an
extra early return to instead revert the if condition and do the single
needed queue_work() call there.
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>

Macro ASSERT_RDEV_LOCK(rdev) is equal to ASSERT_RTNL(), so replace it
with ASSERT_RTNL() and remove it.
Signed-off-by: Zhao, Gang <gamerh2o@gmail.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>

RCU pointer bss->pub.beacon_ies is checked before in previous
statement:

if (rcu_access_pointer(bss->pub.beacon_ies))
	continue;

There is no need to check it twice(and in the wrong way :) ).
Signed-off-by: Zhao, Gang <gamerh2o@gmail.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>

Add a bit in rx_status.vht_flags to let the low level driver
notify mac80211 about a beamformed packet. Propagate this
to the radiotap header.
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>

On 2.4Ghz band, the channels overlap since the delta
between different channels is 5Mhz while the width of the
receiver is 20Mhz (at least).

This means that we can hear beacons or probe responses from
adjacent channels. These frames will have a significant
lower RSSI which will feed all kinds of logic with inaccurate
data. An obvious example is the roaming algorithm that will
think our AP is getting weak and will try to move to another
AP.

In order to avoid this, update the signal only if the frame
has been heard on the same channel as the one advertised by
the AP in its DS / HT IEs.
We refrain from updating the values only if the AP is
already in the BSS list so that we will still have a valid
(but inaccurate) value if the AP was heard on an adjacent
channel only.

To achieve this, stop taking the channel from DS / HT IEs
in mac80211. The DS / HT IEs is taken into account to
discard the frame if it was received on a disabled channel.
This can happen due to the same phenomenon: the frame is
sent on channel 12, but heard on channel 11 while channel
12 can be disabled on certain devices. Since this check
is done in cfg80211, stop even checking this in mac80211.
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
[remove unused rx_freq variable]
Signed-off-by: Johannes Berg <johannes.berg@intel.com>

Function __cfg80211_join_ibss() is only used in net/wireless/ibss.c,
so make it static.
Signed-off-by: Zhao, Gang <gamerh2o@gmail.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>

Drivers might want to have private data in addition
to all other ieee80211_tx_info.status fields.

The current ieee80211_tx_info.rate_driver_data overlaps
with some of the non-rate data (e.g. ampdu_ack_len), so
it might not be good enough.

Since we already know how much free bytes remained,
simply use this size to define (void *) array.

While on it, change ack_signal type from int to the more
explicit s32 type.
Signed-off-by: Eliad Peller <eliadx.peller@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>

Assuming sched_scan_stop operation is synchronous the driver may not
necessary call ieee80211_sched_scan_stopped_work. Since this work is
the only place where sched_scan_sdata is released we can possibly run
into situation when it is never released. Fix this by releasing it
just after calling drv_sched_scan_stop.
Signed-off-by: Alexander Bondar <alexander.bondar@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>

commit de74a1d9
  "mac80211: fix WPA with VLAN on AP side with ps-sta"
fixed an issue where queued multicast packets would
be sent out encrypted with the key of an other bss.

commit "7cbf9d01"
  "mac80211: fix oops on mesh PS broadcast forwarding"
essentially reverted it, because vif.type cannot be AP_VLAN
due to the check to vif.type in ieee80211_get_buffered_bc before.

As the later commit intended to fix the MESH case, fix it
by checking for IFTYPE_AP instead of IFTYPE_AP_VLAN.

Cc: stable@vger.kernel.org
Fixes: 7cbf9d01 ("mac80211: fix oops on mesh PS broadcast forwarding")
Signed-off-by: Michael Braun <michael-dev@fami-braun.de>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>

In the 802.11ad, aka DMG (Dynamic Multi-Gigabit), aka 60Ghz
spec, maximum MSDU size extended to 7920 bytes.
add #define for this.
Signed-off-by: Vladimir Kondratiev <qca_vkondrat@qca.qualcomm.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>

Since Stanislaw's patch removing the quiescing code, mac80211 had
a race regarding suspend vs. authentication: as cfg80211 doesn't
track authentication attempts, it can't abort them. Therefore the
attempts may be kept running while suspending, which can lead to
all kinds of issues, in at least some cases causing an error in
iwlmvm firmware.

Fix this by aborting the authentication attempt when suspending.

Cc: stable@vger.kernel.org
Fixes: 12e7f517 ("mac80211: cleanup generic suspend/resume procedures")
Signed-off-by: Johannes Berg <johannes.berg@intel.com>

When still authenticating the mac80211 code handling a deauthentication
requests from userspace doesn't verify that the request is valid in any
way, fix that. Additionally, it never returns an error, even if there's
no connection or authentication attempt, fix that as well.

While at it, move the message to not print a message in the error case
and to distinguish between the two cases.

Also simplify the code by duplicating the cfg80211 call.
Reviewed-by: Luciano Coelho <luciano.coelho@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>

The bss struct might be freed in ieee80211_rx_bss_put(),
so we shouldn't use it afterwards.

Cc: stable@vger.kernel.org (3.10+)
Fixes: 817cee76 ("mac80211: track AP's beacon rate and give it to the driver")
Signed-off-by: Johannes Berg <johannes.berg@intel.com>

To set AP in 1X1 or 2X2 mode through hostapd, we need to set
RX-STBC* in hostapd.conf file. Depending upon RX-STBC bit in
ht_cap IE received from hostapd, we need to update mcs set in
bss_cfg appropriately before starting AP.
Signed-off-by: Maithili Hinge <maithili@marvell.com>
Signed-off-by: Bing Zhao <bzhao@marvell.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

This patch adds support to read sleep cookie for command
response before accessing buffer.
Signed-off-by: Avinash Patil <patila@marvell.com>
Signed-off-by: Bing Zhao <bzhao@marvell.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

Stations associated to mwifiex AP would not be able to ping AP
after scan was issued on AP interface. This happened because
there was no handling of extended scan event in AP. This patch
adds this handling and fixes ping failure issue.
Signed-off-by: Avinash Patil <patila@marvell.com>
Signed-off-by: Amitkumar Karwar <akarwar@marvell.com>
Signed-off-by: Bing Zhao <bzhao@marvell.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

Emit a prefix for the rsi_dbg messages.

Fix the format and argument mismatch and add
__printf(2, 3) to try to avoid more.
Signed-off-by: Joe Perches <joe@perches.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

The ERP configuration is now done outside RF code in both rtl8180
and rtl8187 drivers.

The conf_erp callback in common RF ops struct is now useless.
Remove it.
Signed-off-by: Andrea Merello <andrea.merello@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

This fixes the build for powerpc:

After merging the final tree, today's linux-next build (powerpc allyesconfig)
failed like this:

drivers/net/wireless/iwlwifi/mvm/debugfs.c: In function 'iwl_dbgfs_fw_error_dump_release':
drivers/net/wireless/iwlwifi/mvm/debugfs.c:161:2: error: implicit declaration of function 'vfree' [-Werror=implicit-function-declaration]
  vfree(file->private_data);
  ^
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>

This is to address reports of this:

In file included from drivers/net/wireless/rsi/rsi_mgmt.h:22:0,
                 from drivers/net/wireless/rsi/rsi_91x_core.c:17:
drivers/net/wireless/rsi/rsi_91x_core.c: In function 'rsi_dbg':
drivers/net/wireless/rsi/rsi_main.h:44:20: error: function 'rsi_dbg' can never be inlined because it uses variable argument lists
 static inline void rsi_dbg(u32 zone, const char *fmt, ...)
Signed-off-by: John W. Linville <linville@tuxdriver.com>

The current firmware advertises support for uAPSD, but
critical bugs force us to disable the feature.
When a fixed firmware will be available, we will be able to
re-enable uAPSD.

Cc: <stable@vger.kernel.org> [3.13+]
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>

If the low-latency update is called but there's no change then
ignore the update instead of triggering all the required work.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>

Remove a spurious blank line in the quota code.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>

mvmsta could have been NULL / ERR.
Reviewed-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>

In case of system low latency configure passive scan to be fragmented.
Set the following scan parameters for both immediate and scheduled scan:
 - passive scan fragment duration = 20ms
 - out-of-channel time = 70ms
 - suspend time = 105ms
Restructure channel's active/passive dwell time configuration to better
suit the above change.

The idea is that under low latency traffic passive scan is fragmented,
i.e. that dwell on a particular channel will be fragmented. Each
fragment dwell time is 20ms and fragments period is 105ms. Skipping to
next channel will be delayed by the same period (105ms). So suspend_time
parameter describing both fragments and channels skipping periods is set
to 105ms. This value is chosen so that overall passive scan duration
will not be too long. Max_out_time in this case is set to 70ms, so for
active scanning operating channel will be left for 70ms while for
passive still for 20ms (fragment dwell).
Signed-off-by: Alexander Bondar <alexander.bondar@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>

Some scan parameters should be dependent on traffic conditions.
Centralize conditions verification in one function and obtain
scan max out-of-channel and suspend time in that new function.
Rely on bound interfaces indication instead of association state
to calculate scan parameters. If no bound interfaces use default
values for out-of-channel and suspend time parameters.

Additionally, get rid of NL80211_SCAN_FLAG_LOW_PRIORITY checks
since no use case for this exists so far.
Signed-off-by: Alexander Bondar <alexander.bondar@intel.com>
[reword commit log a bit]
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>

The firmware decided to not implement this API in this way,
so for now remove setting the field completely. This will
allow the firmware to change how to use this field later.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>

In order to debug the firmware, we need to be able to set
the BT priority of WiFi packets. This priority is set based
on the type of the packet (control frames, EAPOL etc...).
For debugging purposes, allow to override this priority by
a debugfs controlled value.
Enable this feature that needs this priority to be able to
test it.
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>

When the firmware asserts, the driver will dump the firmware
state to an internal buffer. This buffer is kept aside until
it is dumped through debugfs. Once an external application
fetched the data, the buffer is freed and a new buffer can
be allocated in case another assert occurs.

A udev event is sent to trigger an external application.

A simple rule like:
DRIVER=="iwlwifi", ACTION=="change", RUN+="/sbin/dump_sram.sh"

can fetch the data from debugfs.

Here is my dump_sram.sh:

phyname=$(basename ${DEVPATH})
date=$(date +%F_%H_%M)
filename=/var/log/iwl-sram-${phyname}-${date}.bin
cat /sys/kernel/debug/ieee80211/${phyname}/iwlwifi/iwlmvm/fw_error_dump > ${filename}

The current SRAM size is 80KB so, currently:
$ ls -lh iwl-sram-phy0-2014-03-16_13_14.bin
-rw-r--r-- 1 emmanuel emmanuel 81K Mar 16 13:15 iwl-sram-phy0-2014-03-16_13_14.bin

and after compression:
$ ls -lh iwl-sram-phy0-2014-03-16_13_14.bin.xz
-rw-r--r-- 1 emmanuel emmanuel 13K Mar 16 13:15 iwl-sram-phy0-2014-03-16_13_14.bin.xz
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>

The pairing process initiated through mgmt sets the conn->auth_type
value regardless of BR/EDR or LE pairing. This value will contain the
MITM flag if the local IO capability allows it. When sending the SMP
pairing request we should check the value and ensure that the MITM bit
gets correctly set in the bonding flags.
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>

The SMP specification is written with the assumption that both key
information, plaintextData and encryptedData follow the same little
endian byte ordering as the rest of SMP.

Since the kernel crypto routines expect big endian data the code has had
to do various byte swapping tricks to make the behavior as expected,
however the swapping has been scattered all around the place.

This patch centralizes the byte order swapping into the smp_e function
by making its public interface match what the other SMP functions expect
as per specification. The benefit is vastly simplified calls to smp_e.
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>