2019-09-19 14:25:46 +00:00
|
|
|
// SPDX-License-Identifier: GPL-2.0-only
|
|
|
|
/*
|
2021-09-13 15:01:56 +02:00
|
|
|
* Data receiving implementation.
|
2019-09-19 14:25:46 +00:00
|
|
|
*
|
2020-10-07 12:19:41 +02:00
|
|
|
* Copyright (c) 2017-2020, Silicon Laboratories, Inc.
|
2019-09-19 14:25:46 +00:00
|
|
|
* Copyright (c) 2010, ST-Ericsson
|
|
|
|
*/
|
2021-03-09 15:51:56 +01:00
|
|
|
#include <linux/etherdevice.h>
|
|
|
|
#include <net/mac80211.h>
|
|
|
|
|
2019-09-19 14:25:46 +00:00
|
|
|
#include "data_rx.h"
|
|
|
|
#include "wfx.h"
|
2021-03-09 15:51:56 +01:00
|
|
|
#include "bh.h"
|
|
|
|
#include "sta.h"
|
2019-09-19 14:25:46 +00:00
|
|
|
|
staging: wfx: fix CCMP/TKIP replay protection
To enable the TKIP/CCMP replay protection, the frames has to be
processed in the right order. However, the device is not able to
re-order the frames during BlockAck sessions.
Mac80211 is able to reorder the frames, but it need the information
about the BlockAck sessions start and stop. Unfortunately, since the
BlockAck is fully handled by the hardware, these frames were not
forwarded to the host. So, if the driver ask to mac80211 to apply the
replay protection, it drop all misordered frames.
So, until now, the driver explicitly asked to mac80211 to not apply
the CCMP/TKIP replay protection.
The situation has changed with the API 3.4 of the device firmware. The
firmware forward the BlockAck information. Mac80211 is now able to
correctly reorder the frames. There is no more reasons to drop
cryptographic data.
This patch also impact the older firmwares. There will be a performance
impact on these firmware (since the misordered frames will dropped).
However, we can't keep the replay protection disabled.
Signed-off-by: Jérôme Pouiller <jerome.pouiller@silabs.com>
Link: https://lore.kernel.org/r/20200701150707.222985-12-Jerome.Pouiller@silabs.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-07-01 17:07:05 +02:00
|
|
|
static void wfx_rx_handle_ba(struct wfx_vif *wvif, struct ieee80211_mgmt *mgmt)
|
|
|
|
{
|
2022-05-06 13:00:46 -04:00
|
|
|
struct ieee80211_vif *vif = wvif_to_vif(wvif);
|
staging: wfx: fix CCMP/TKIP replay protection
To enable the TKIP/CCMP replay protection, the frames has to be
processed in the right order. However, the device is not able to
re-order the frames during BlockAck sessions.
Mac80211 is able to reorder the frames, but it need the information
about the BlockAck sessions start and stop. Unfortunately, since the
BlockAck is fully handled by the hardware, these frames were not
forwarded to the host. So, if the driver ask to mac80211 to apply the
replay protection, it drop all misordered frames.
So, until now, the driver explicitly asked to mac80211 to not apply
the CCMP/TKIP replay protection.
The situation has changed with the API 3.4 of the device firmware. The
firmware forward the BlockAck information. Mac80211 is now able to
correctly reorder the frames. There is no more reasons to drop
cryptographic data.
This patch also impact the older firmwares. There will be a performance
impact on these firmware (since the misordered frames will dropped).
However, we can't keep the replay protection disabled.
Signed-off-by: Jérôme Pouiller <jerome.pouiller@silabs.com>
Link: https://lore.kernel.org/r/20200701150707.222985-12-Jerome.Pouiller@silabs.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-07-01 17:07:05 +02:00
|
|
|
int params, tid;
|
2020-10-07 12:19:39 +02:00
|
|
|
|
|
|
|
if (wfx_api_older_than(wvif->wdev, 3, 6))
|
|
|
|
return;
|
staging: wfx: fix CCMP/TKIP replay protection
To enable the TKIP/CCMP replay protection, the frames has to be
processed in the right order. However, the device is not able to
re-order the frames during BlockAck sessions.
Mac80211 is able to reorder the frames, but it need the information
about the BlockAck sessions start and stop. Unfortunately, since the
BlockAck is fully handled by the hardware, these frames were not
forwarded to the host. So, if the driver ask to mac80211 to apply the
replay protection, it drop all misordered frames.
So, until now, the driver explicitly asked to mac80211 to not apply
the CCMP/TKIP replay protection.
The situation has changed with the API 3.4 of the device firmware. The
firmware forward the BlockAck information. Mac80211 is now able to
correctly reorder the frames. There is no more reasons to drop
cryptographic data.
This patch also impact the older firmwares. There will be a performance
impact on these firmware (since the misordered frames will dropped).
However, we can't keep the replay protection disabled.
Signed-off-by: Jérôme Pouiller <jerome.pouiller@silabs.com>
Link: https://lore.kernel.org/r/20200701150707.222985-12-Jerome.Pouiller@silabs.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-07-01 17:07:05 +02:00
|
|
|
|
|
|
|
switch (mgmt->u.action.u.addba_req.action_code) {
|
|
|
|
case WLAN_ACTION_ADDBA_REQ:
|
|
|
|
params = le16_to_cpu(mgmt->u.action.u.addba_req.capab);
|
|
|
|
tid = (params & IEEE80211_ADDBA_PARAM_TID_MASK) >> 2;
|
2022-05-06 13:00:46 -04:00
|
|
|
ieee80211_start_rx_ba_session_offl(vif, mgmt->sa, tid);
|
staging: wfx: fix CCMP/TKIP replay protection
To enable the TKIP/CCMP replay protection, the frames has to be
processed in the right order. However, the device is not able to
re-order the frames during BlockAck sessions.
Mac80211 is able to reorder the frames, but it need the information
about the BlockAck sessions start and stop. Unfortunately, since the
BlockAck is fully handled by the hardware, these frames were not
forwarded to the host. So, if the driver ask to mac80211 to apply the
replay protection, it drop all misordered frames.
So, until now, the driver explicitly asked to mac80211 to not apply
the CCMP/TKIP replay protection.
The situation has changed with the API 3.4 of the device firmware. The
firmware forward the BlockAck information. Mac80211 is now able to
correctly reorder the frames. There is no more reasons to drop
cryptographic data.
This patch also impact the older firmwares. There will be a performance
impact on these firmware (since the misordered frames will dropped).
However, we can't keep the replay protection disabled.
Signed-off-by: Jérôme Pouiller <jerome.pouiller@silabs.com>
Link: https://lore.kernel.org/r/20200701150707.222985-12-Jerome.Pouiller@silabs.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-07-01 17:07:05 +02:00
|
|
|
break;
|
|
|
|
case WLAN_ACTION_DELBA:
|
|
|
|
params = le16_to_cpu(mgmt->u.action.u.delba.params);
|
|
|
|
tid = (params & IEEE80211_DELBA_PARAM_TID_MASK) >> 12;
|
2022-05-06 13:00:46 -04:00
|
|
|
ieee80211_stop_rx_ba_session_offl(vif, mgmt->sa, tid);
|
staging: wfx: fix CCMP/TKIP replay protection
To enable the TKIP/CCMP replay protection, the frames has to be
processed in the right order. However, the device is not able to
re-order the frames during BlockAck sessions.
Mac80211 is able to reorder the frames, but it need the information
about the BlockAck sessions start and stop. Unfortunately, since the
BlockAck is fully handled by the hardware, these frames were not
forwarded to the host. So, if the driver ask to mac80211 to apply the
replay protection, it drop all misordered frames.
So, until now, the driver explicitly asked to mac80211 to not apply
the CCMP/TKIP replay protection.
The situation has changed with the API 3.4 of the device firmware. The
firmware forward the BlockAck information. Mac80211 is now able to
correctly reorder the frames. There is no more reasons to drop
cryptographic data.
This patch also impact the older firmwares. There will be a performance
impact on these firmware (since the misordered frames will dropped).
However, we can't keep the replay protection disabled.
Signed-off-by: Jérôme Pouiller <jerome.pouiller@silabs.com>
Link: https://lore.kernel.org/r/20200701150707.222985-12-Jerome.Pouiller@silabs.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-07-01 17:07:05 +02:00
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2022-01-13 09:55:13 +01:00
|
|
|
void wfx_rx_cb(struct wfx_vif *wvif, const struct wfx_hif_ind_rx *arg, struct sk_buff *skb)
|
2019-09-19 14:25:46 +00:00
|
|
|
{
|
|
|
|
struct ieee80211_rx_status *hdr = IEEE80211_SKB_RXCB(skb);
|
2019-10-19 15:07:15 +01:00
|
|
|
struct ieee80211_hdr *frame = (struct ieee80211_hdr *)skb->data;
|
|
|
|
struct ieee80211_mgmt *mgmt = (struct ieee80211_mgmt *)skb->data;
|
2019-09-19 14:25:46 +00:00
|
|
|
|
|
|
|
memset(hdr, 0, sizeof(*hdr));
|
|
|
|
|
2020-05-12 17:04:11 +02:00
|
|
|
if (arg->status == HIF_STATUS_RX_FAIL_MIC)
|
2020-10-07 12:19:37 +02:00
|
|
|
hdr->flag |= RX_FLAG_MMIC_ERROR | RX_FLAG_IV_STRIPPED;
|
2019-09-19 14:25:46 +00:00
|
|
|
else if (arg->status)
|
|
|
|
goto drop;
|
|
|
|
|
|
|
|
if (skb->len < sizeof(struct ieee80211_pspoll)) {
|
|
|
|
dev_warn(wvif->wdev->dev, "malformed SDU received\n");
|
|
|
|
goto drop;
|
|
|
|
}
|
|
|
|
|
|
|
|
hdr->band = NL80211_BAND_2GHZ;
|
2022-01-13 09:55:13 +01:00
|
|
|
hdr->freq = ieee80211_channel_to_frequency(arg->channel_number, hdr->band);
|
2019-09-19 14:25:46 +00:00
|
|
|
|
|
|
|
if (arg->rxed_rate >= 14) {
|
|
|
|
hdr->encoding = RX_ENC_HT;
|
|
|
|
hdr->rate_idx = arg->rxed_rate - 14;
|
|
|
|
} else if (arg->rxed_rate >= 4) {
|
|
|
|
hdr->rate_idx = arg->rxed_rate - 2;
|
|
|
|
} else {
|
|
|
|
hdr->rate_idx = arg->rxed_rate;
|
|
|
|
}
|
|
|
|
|
2020-07-01 17:07:03 +02:00
|
|
|
if (!arg->rcpi_rssi) {
|
|
|
|
hdr->flag |= RX_FLAG_NO_SIGNAL_VAL;
|
|
|
|
dev_info(wvif->wdev->dev, "received frame without RSSI data\n");
|
|
|
|
}
|
2019-09-19 14:25:46 +00:00
|
|
|
hdr->signal = arg->rcpi_rssi / 2 - 110;
|
|
|
|
hdr->antenna = 0;
|
|
|
|
|
2020-09-07 12:15:07 +02:00
|
|
|
if (arg->encryp)
|
staging: wfx: fix CCMP/TKIP replay protection
To enable the TKIP/CCMP replay protection, the frames has to be
processed in the right order. However, the device is not able to
re-order the frames during BlockAck sessions.
Mac80211 is able to reorder the frames, but it need the information
about the BlockAck sessions start and stop. Unfortunately, since the
BlockAck is fully handled by the hardware, these frames were not
forwarded to the host. So, if the driver ask to mac80211 to apply the
replay protection, it drop all misordered frames.
So, until now, the driver explicitly asked to mac80211 to not apply
the CCMP/TKIP replay protection.
The situation has changed with the API 3.4 of the device firmware. The
firmware forward the BlockAck information. Mac80211 is now able to
correctly reorder the frames. There is no more reasons to drop
cryptographic data.
This patch also impact the older firmwares. There will be a performance
impact on these firmware (since the misordered frames will dropped).
However, we can't keep the replay protection disabled.
Signed-off-by: Jérôme Pouiller <jerome.pouiller@silabs.com>
Link: https://lore.kernel.org/r/20200701150707.222985-12-Jerome.Pouiller@silabs.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-07-01 17:07:05 +02:00
|
|
|
hdr->flag |= RX_FLAG_DECRYPTED;
|
2019-09-19 14:25:46 +00:00
|
|
|
|
2022-01-13 09:55:14 +01:00
|
|
|
/* Block ack negotiation is offloaded by the firmware. However, re-ordering must be done by
|
|
|
|
* the mac80211.
|
2021-09-13 15:01:58 +02:00
|
|
|
*/
|
2019-10-19 15:07:17 +01:00
|
|
|
if (ieee80211_is_action(frame->frame_control) &&
|
staging: wfx: fix CCMP/TKIP replay protection
To enable the TKIP/CCMP replay protection, the frames has to be
processed in the right order. However, the device is not able to
re-order the frames during BlockAck sessions.
Mac80211 is able to reorder the frames, but it need the information
about the BlockAck sessions start and stop. Unfortunately, since the
BlockAck is fully handled by the hardware, these frames were not
forwarded to the host. So, if the driver ask to mac80211 to apply the
replay protection, it drop all misordered frames.
So, until now, the driver explicitly asked to mac80211 to not apply
the CCMP/TKIP replay protection.
The situation has changed with the API 3.4 of the device firmware. The
firmware forward the BlockAck information. Mac80211 is now able to
correctly reorder the frames. There is no more reasons to drop
cryptographic data.
This patch also impact the older firmwares. There will be a performance
impact on these firmware (since the misordered frames will dropped).
However, we can't keep the replay protection disabled.
Signed-off-by: Jérôme Pouiller <jerome.pouiller@silabs.com>
Link: https://lore.kernel.org/r/20200701150707.222985-12-Jerome.Pouiller@silabs.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-07-01 17:07:05 +02:00
|
|
|
mgmt->u.action.category == WLAN_CATEGORY_BACK &&
|
|
|
|
skb->len > IEEE80211_MIN_ACTION_SIZE) {
|
|
|
|
wfx_rx_handle_ba(wvif, mgmt);
|
2019-09-19 14:25:46 +00:00
|
|
|
goto drop;
|
staging: wfx: fix CCMP/TKIP replay protection
To enable the TKIP/CCMP replay protection, the frames has to be
processed in the right order. However, the device is not able to
re-order the frames during BlockAck sessions.
Mac80211 is able to reorder the frames, but it need the information
about the BlockAck sessions start and stop. Unfortunately, since the
BlockAck is fully handled by the hardware, these frames were not
forwarded to the host. So, if the driver ask to mac80211 to apply the
replay protection, it drop all misordered frames.
So, until now, the driver explicitly asked to mac80211 to not apply
the CCMP/TKIP replay protection.
The situation has changed with the API 3.4 of the device firmware. The
firmware forward the BlockAck information. Mac80211 is now able to
correctly reorder the frames. There is no more reasons to drop
cryptographic data.
This patch also impact the older firmwares. There will be a performance
impact on these firmware (since the misordered frames will dropped).
However, we can't keep the replay protection disabled.
Signed-off-by: Jérôme Pouiller <jerome.pouiller@silabs.com>
Link: https://lore.kernel.org/r/20200701150707.222985-12-Jerome.Pouiller@silabs.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-07-01 17:07:05 +02:00
|
|
|
}
|
2019-09-19 14:25:46 +00:00
|
|
|
|
staging: wfx: fix CCMP/TKIP replay protection
To enable the TKIP/CCMP replay protection, the frames has to be
processed in the right order. However, the device is not able to
re-order the frames during BlockAck sessions.
Mac80211 is able to reorder the frames, but it need the information
about the BlockAck sessions start and stop. Unfortunately, since the
BlockAck is fully handled by the hardware, these frames were not
forwarded to the host. So, if the driver ask to mac80211 to apply the
replay protection, it drop all misordered frames.
So, until now, the driver explicitly asked to mac80211 to not apply
the CCMP/TKIP replay protection.
The situation has changed with the API 3.4 of the device firmware. The
firmware forward the BlockAck information. Mac80211 is now able to
correctly reorder the frames. There is no more reasons to drop
cryptographic data.
This patch also impact the older firmwares. There will be a performance
impact on these firmware (since the misordered frames will dropped).
However, we can't keep the replay protection disabled.
Signed-off-by: Jérôme Pouiller <jerome.pouiller@silabs.com>
Link: https://lore.kernel.org/r/20200701150707.222985-12-Jerome.Pouiller@silabs.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-07-01 17:07:05 +02:00
|
|
|
ieee80211_rx_irqsafe(wvif->wdev->hw, skb);
|
2019-09-19 14:25:46 +00:00
|
|
|
return;
|
|
|
|
|
|
|
|
drop:
|
|
|
|
dev_kfree_skb(skb);
|
|
|
|
}
|