I forgot to send the new Look Up Table to the firmware and
I also forgot to free the command which is kzalloc'ed.
This code is relevant for 7265 device only.
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
mimo_delim was always set to 0 instead of pointing to
the first SISO entry after MIMO rates.
This can cause keep transmitting in MIMO even when we shouldn't.
For example when the peer is requesting static SMPS.
Cc: <stable@vger.kernel.org> [3.14]
Signed-off-by: Eyal Shapira <eyalx.shapira@intel.com>
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
If we have no beacon data before association, delay smart FIFO
enablement until after we have this data.
Not doing so can cause association failures in extremely silent
environments (usually only a shielded box/room) as beacon RX is
not sent to the host immediately, and then the association time
event ends without the host receiving any beacon even though it
was on the air - it's just stuck on the FIFO.
Cc: <stable@vger.kernel.org> [3.14]
Fixes: 1f3b0ff8ec ("iwlwifi: mvm: Add Smart FIFO support")
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
In order to support the driver behaviour introduced by:
commit d0575a5a703978c43e25128421158c78534ba100
Author: Daniel Kim <dekim@broadcom.com>
Date: Wed Mar 12 18:12:14 2014 -0700
brcmfmac: Enable 40MHz bandwidth in 2GHz band and OBSS scanning
in devices that do not support bwcap firmware command a fallback
is added.
Reviewed-by: Daniel (Deognyoun) Kim <dekim@broadcom.com>
Reviewed-by: Pieter-Paul Giesberts <pieterpg@broadcom.com>
Signed-off-by: Arend van Spriel <arend@broadcom.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
In the function brcmf_sdiod_request_data() an error message is logged,
but the calling function retries it. This patch will only log an error
message when retry limit is reached. The low-level error is still
logged by a SDIO debug message.
Reviewed-by: Daniel (Deognyoun) Kim <dekim@broadcom.com>
Reviewed-by: Pieter-Paul Giesberts <pieterpg@broadcom.com>
Signed-off-by: Arend van Spriel <arend@broadcom.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
The watchdog thread waits on completion that is set from a timer. As
the completion is count based this could mean that on a busy system
the watchdog is handled multiple times with a very short interval.
This is not the intended behaviour. After handling the watchdog it
should wait for the next timer expiry. This is accomplished by
reinitializing the completion.
Reviewed-by: Hante Meuleman <meuleman@broadcom.com>
Reviewed-by: Pieter-Paul Giesberts <pieterpg@broadcom.com>
Signed-off-by: Arend van Spriel <arend@broadcom.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
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>
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 de74a1d903
"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 "7cbf9d017dbb5e3276de7d527925d42d4c11e732"
"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: 7cbf9d017d ("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>
Emmanuel Grumbach
Oren Givon
Eyal Shapira
Johannes Berg
Arend van Spriel
Daniel Kim
John W. Linville
Marcel Holtmann
Johan Hedberg
Zhao, Gang
Eliad Peller
Alexander Bondar
Michael Braun