[PATCH 2/2 - linux-stable-4.4] ath10k: rebuild crypto header in rx data frames
Rx data frames notified through HTT_T2H_MSG_TYPE_RX_IND and
HTT_T2H_MSG_TYPE_RX_FRAG_IND expect PN/TSC check to be done
on host (mac80211) rather than firmware. Rebuild cipher header
in every received data frames (that are notified through those
HTT interfaces) from the rx_hdr_status tlv available in the
rx descriptor of the first msdu. Skip setting RX_FLAG_IV_STRIPPED
flag for the packets which requires mac80211 PN/TSC check support
and set appropriate RX_FLAG for stripped crypto tail. Hw QCA988X,
and QCA99X0 currently need the rebuilding of cipher header to
perform PN/TSC check for replay attack.
[Upstream Commit : 7eccb738fce57cbe53ed903ccf43f9ab257b15b3]
Signed-off-by: Vasanthakumar Thiagarajan
Signed-off-by: Sriram R
---
drivers/net/wireless/ath/ath10k/htt_rx.c | 98 ++--
1 file changed, 82 insertions(+), 16 deletions(-)
diff --git a/drivers/net/wireless/ath/ath10k/htt_rx.c
b/drivers/net/wireless/ath/ath10k/htt_rx.c
index 8d20ecc..d26cb37 100644
--- a/drivers/net/wireless/ath/ath10k/htt_rx.c
+++ b/drivers/net/wireless/ath/ath10k/htt_rx.c
@@ -1076,7 +1076,21 @@ static void ath10k_htt_rx_h_undecap_raw(struct ath10k
*ar,
hdr = (void *)msdu->data;
/* Tail */
- skb_trim(msdu, msdu->len - ath10k_htt_rx_crypto_tail_len(ar, enctype));
+ if (status->flag & RX_FLAG_IV_STRIPPED) {
+ skb_trim(msdu, msdu->len -
+ath10k_htt_rx_crypto_tail_len(ar, enctype));
+ } else {
+ /* MIC */
+ if ((status->flag & RX_FLAG_MIC_STRIPPED) &&
+ enctype == HTT_RX_MPDU_ENCRYPT_AES_CCM_WPA2)
+ skb_trim(msdu, msdu->len - 8);
+
+ /* ICV */
+ if (status->flag & RX_FLAG_ICV_STRIPPED &&
+ enctype != HTT_RX_MPDU_ENCRYPT_AES_CCM_WPA2)
+ skb_trim(msdu, msdu->len -
+ath10k_htt_rx_crypto_tail_len(ar, enctype));
+ }
/* MMIC */
if (!ieee80211_has_morefrags(hdr->frame_control) &&
@@ -1095,12 +1109,14 @@ static void ath10k_htt_rx_h_undecap_raw(struct ath10k
*ar,
static void ath10k_htt_rx_h_undecap_nwifi(struct ath10k *ar,
struct sk_buff *msdu,
struct ieee80211_rx_status *status,
- const u8 first_hdr[64])
+ const u8 first_hdr[64],
+ enum htt_rx_mpdu_encrypt_type enctype)
{
struct ieee80211_hdr *hdr;
size_t hdr_len;
u8 da[ETH_ALEN];
u8 sa[ETH_ALEN];
+ int bytes_aligned = ar->hw_params.decap_align_bytes;
/* Delivered decapped frame:
* [nwifi 802.11 header] <-- replaced with 802.11 hdr
@@ -1123,6 +1139,14 @@ static void ath10k_htt_rx_h_undecap_nwifi(struct ath10k
*ar,
/* push original 802.11 header */
hdr = (struct ieee80211_hdr *)first_hdr;
hdr_len = ieee80211_hdrlen(hdr->frame_control);
+
+ if (!(status->flag & RX_FLAG_IV_STRIPPED)) {
+ memcpy(skb_push(msdu,
+ ath10k_htt_rx_crypto_param_len(ar, enctype)),
+ (void *)hdr + round_up(hdr_len, bytes_aligned),
+ ath10k_htt_rx_crypto_param_len(ar, enctype));
+ }
+
memcpy(skb_push(msdu, hdr_len), hdr, hdr_len);
/* original 802.11 header has a different DA and in
@@ -1180,6 +1204,7 @@ static void ath10k_htt_rx_h_undecap_eth(struct ath10k *ar,
void *rfc1042;
u8 da[ETH_ALEN];
u8 sa[ETH_ALEN];
+ int bytes_aligned = ar->hw_params.decap_align_bytes;
/* Delivered decapped frame:
* [eth header] <-- replaced with 802.11 hdr & rfc1042/llc
@@ -1203,6 +1228,14 @@ static void ath10k_htt_rx_h_undecap_eth(struct ath10k
*ar,
/* push original 802.11 header */
hdr = (struct ieee80211_hdr *)first_hdr;
hdr_len = ieee80211_hdrlen(hdr->frame_control);
+
+ if (!(status->flag & RX_FLAG_IV_STRIPPED)) {
+ memcpy(skb_push(msdu,
+ ath10k_htt_rx_crypto_param_len(ar, enctype)),
+ (void *)hdr + round_up(hdr_len, bytes_aligned),
+ ath10k_htt_rx_crypto_param_len(ar, enctype));
+ }
+
memcpy(skb_push(msdu, hdr_len), hdr, hdr_len);
/* original 802.11 header has a different DA and in
@@ -1216,10 +1249,12 @@ static void ath10k_htt_rx_h_undecap_eth(struct ath10k
*ar,
static void ath10k_htt_rx_h_undecap_snap(struct ath10k *ar,
struct sk_buff *msdu,
struct ieee80211_rx_status *status,
-const u8 first_hdr[64])
+const u8 first_hdr[64],
+enum htt_rx_mpdu_encrypt_type en
[PATCH 0/2 linux-stable-4.4] ath10k: rebuild crypto header in rx data frames
ath10k has a replay detection issue which was fixed in v4.14 and we would like to get this security fix also to linux-stable-4.4.But for that it depends on 3 mac80211 patches so the below mac80211 commits needs to be picked first in the same order and then apply this patchset. f980ebc058c2 : mac80211: allow not sending MIC up from driver for HW crypto f631a77ba920 : mac80211: allow same PN for AMSDU sub-frames cef0acd4d7d4 : mac80211: Add RX flag to indicate ICV stripped These patches should be applied in that order(commit f980ebc058c2 first) and they should apply cleanly with 3-way merge. Sriram R (2): ath10k: Add new hw param to identify alignment for different chipsets ath10k: rebuild crypto header in rx data frames drivers/net/wireless/ath/ath10k/core.c| 8 +++ drivers/net/wireless/ath/ath10k/core.h| 4 ++ drivers/net/wireless/ath/ath10k/htt_rx.c | 108 +- drivers/net/wireless/ath/ath10k/rx_desc.h | 3 + 4 files changed, 107 insertions(+), 16 deletions(-) -- 2.7.4
[PATCH 1/2 linux-stable-4.4] ath10k: Add new hw param to identify alignment for different chipsets
Chipset QCA99X0 doesnot have rx_hdr_status padded to
align in 4-byte boundary.Hence define a new hw_params
field to handle different alignment behaviour between
different chipsets.
[Upstream commit : 2f38c3c01de945234d23dd163e3528ccb413066d]
Signed-off-by: Vasanthkumar Thiagarajan
Signed-off-by: Sriram R
---
drivers/net/wireless/ath/ath10k/core.c | 8
drivers/net/wireless/ath/ath10k/core.h | 4
2 files changed, 12 insertions(+)
diff --git a/drivers/net/wireless/ath/ath10k/core.c
b/drivers/net/wireless/ath/ath10k/core.c
index ee638cb..0c23768 100644
--- a/drivers/net/wireless/ath/ath10k/core.c
+++ b/drivers/net/wireless/ath/ath10k/core.c
@@ -67,6 +67,7 @@ static const struct ath10k_hw_params ath10k_hw_params_list[]
= {
.board_size = QCA988X_BOARD_DATA_SZ,
.board_ext_size = QCA988X_BOARD_EXT_DATA_SZ,
},
+ .decap_align_bytes = 4,
},
{
.id = QCA6174_HW_2_1_VERSION,
@@ -85,6 +86,7 @@ static const struct ath10k_hw_params ath10k_hw_params_list[]
= {
.board_size = QCA6174_BOARD_DATA_SZ,
.board_ext_size = QCA6174_BOARD_EXT_DATA_SZ,
},
+ .decap_align_bytes = 4,
},
{
.id = QCA6174_HW_2_1_VERSION,
@@ -103,6 +105,7 @@ static const struct ath10k_hw_params
ath10k_hw_params_list[] = {
.board_size = QCA6174_BOARD_DATA_SZ,
.board_ext_size = QCA6174_BOARD_EXT_DATA_SZ,
},
+ .decap_align_bytes = 4,
},
{
.id = QCA6174_HW_3_0_VERSION,
@@ -121,6 +124,7 @@ static const struct ath10k_hw_params
ath10k_hw_params_list[] = {
.board_size = QCA6174_BOARD_DATA_SZ,
.board_ext_size = QCA6174_BOARD_EXT_DATA_SZ,
},
+ .decap_align_bytes = 4,
},
{
.id = QCA6174_HW_3_2_VERSION,
@@ -140,6 +144,7 @@ static const struct ath10k_hw_params
ath10k_hw_params_list[] = {
.board_size = QCA6174_BOARD_DATA_SZ,
.board_ext_size = QCA6174_BOARD_EXT_DATA_SZ,
},
+ .decap_align_bytes = 4,
},
{
.id = QCA99X0_HW_2_0_DEV_VERSION,
@@ -159,6 +164,7 @@ static const struct ath10k_hw_params
ath10k_hw_params_list[] = {
.board_size = QCA99X0_BOARD_DATA_SZ,
.board_ext_size = QCA99X0_BOARD_EXT_DATA_SZ,
},
+ .decap_align_bytes = 1,
},
{
.id = QCA9377_HW_1_0_DEV_VERSION,
@@ -177,6 +183,7 @@ static const struct ath10k_hw_params
ath10k_hw_params_list[] = {
.board_size = QCA9377_BOARD_DATA_SZ,
.board_ext_size = QCA9377_BOARD_EXT_DATA_SZ,
},
+ .decap_align_bytes = 4,
},
{
.id = QCA9377_HW_1_1_DEV_VERSION,
@@ -195,6 +202,7 @@ static const struct ath10k_hw_params
ath10k_hw_params_list[] = {
.board_size = QCA9377_BOARD_DATA_SZ,
.board_ext_size = QCA9377_BOARD_EXT_DATA_SZ,
},
+ .decap_align_bytes = 4,
},
};
diff --git a/drivers/net/wireless/ath/ath10k/core.h
b/drivers/net/wireless/ath/ath10k/core.h
index 858d75f..e4e3b41 100644
--- a/drivers/net/wireless/ath/ath10k/core.h
+++ b/drivers/net/wireless/ath/ath10k/core.h
@@ -670,6 +670,10 @@ struct ath10k {
size_t board_size;
size_t board_ext_size;
} fw;
+
+ /* Number of bytes used for alignment in rx_hdr_status */
+ int decap_align_bytes;
+
} hw_params;
const struct firmware *board;
--
2.7.4
RE: [PATCH v3 00/19] rtlwifi: halmac: Add new module halmac
> -Original Message- > From: Barry Day [mailto:brise...@gmail.com] > Sent: Saturday, April 28, 2018 6:42 AM > To: Pkshih > Cc: Kalle Valo; larry.fin...@lwfinger.net; linux-wireless@vger.kernel.org > Subject: Re: [PATCH v3 00/19] rtlwifi: halmac: Add new module halmac > > On Fri, Apr 27, 2018 at 05:44:16AM +, Pkshih wrote: > > > > The registers reside in driver causes error frequently, because MAC register > > is maintained by Realtek's MAC team so they create this module to avoid > > mistakes. > > Another benefit is to make it possible to become a thin driver, because many > > common functions are provided, so duplicate code will be reduced. > > How is it possible to create a thin driver by adding lots more code and layers > of indirection ??? and writing it in a way that it won't compile without the > code for every type of bus interface even though most modules only use one ? > As I mentioned in first paragraph "(I use 'driver' in this mail indicates part of rtlwifi excluded from this module.)". If this module was seen as a 'lib', rtl8822be would be a "thin driver". For bus interface code, I need to add a way to compile type of bus interface according to selected chip. > It's a horrible pile of garbage slapped together by an inexperienced > programmer. Its a major deterrent for anyone looking at working on one of > the latest realtek drivers. > This module is designed to support multiple OS including Windows and Linux, and many products have used this module and worked well. We hope Linux user can also use Realtek's WiFi without additional installation if driver was built. In order to submit this module to kernel upstream, we take a lot of effort to fit Linux coding conventions (e.g. coding style), and explicit suggestions will be helpful for us to continuously improve this module. Thanks PK
[PATCH v5] ath10k: fix crash in recent 3.5.3 9984 firmware due wrong handling of peer_bw_rxnss_override parameter
From: Sebastian Gottschall
current handling of peer_bw_rxnss_override parameter is based on guessing the
VHT160/8080 capability by rx rate. this is wrong and may lead
to a non initialized peer_bw_rxnss_override parameter which is required since
VHT160 operation mode only supports 2x2 chainmasks in addition the original code
initialized the parameter with wrong masked values.
This patch uses the peer phymode and peer nss information for correct
initialisation of the peer_bw_rxnss_override parameter.
if this peer information is not available, we initialize the parameter by
minimum nss which is suggested by QCA as temporary workaround according
to the QCA sourcecodes.
Signed-off-by: Sebastian Gottschall
v2: remove debug messages
v3: apply some cosmetics, update documentation
v4: fix compile warning and truncate nss to maximum of 2x2 since current
chipsets only support 2x2 at vht160
v5: handle maximum nss for chipsets supportig vht160 with 1x1 only
---
drivers/net/wireless/ath/ath10k/mac.c | 48 ++-
drivers/net/wireless/ath/ath10k/wmi.c | 7 +---
drivers/net/wireless/ath/ath10k/wmi.h | 14 +++-
3 files changed, 47 insertions(+), 22 deletions(-)
diff --git a/drivers/net/wireless/ath/ath10k/mac.c
b/drivers/net/wireless/ath/ath10k/mac.c
index 5be6386ede8f..a95a32102ef3 100644
--- a/drivers/net/wireless/ath/ath10k/mac.c
+++ b/drivers/net/wireless/ath/ath10k/mac.c
@@ -2528,23 +2528,41 @@ static void ath10k_peer_assoc_h_vht(struct ath10k *ar,
__le16_to_cpu(vht_cap->vht_mcs.tx_highest);
arg->peer_vht_rates.tx_mcs_set = ath10k_peer_assoc_h_vht_limit(
__le16_to_cpu(vht_cap->vht_mcs.tx_mcs_map), vht_mcs_mask);
+ arg->peer_bw_rxnss_override = 0;
+
+ if (arg->peer_num_spatial_streams &&
ar->hw_params.vht160_mcs_rx_highest) {
+ int nss160 = arg->peer_num_spatial_streams;
+ /* truncate vht160 nss value to 2x2 since all known chipsets do
not support more than 2x2 in vht160 modes */
+ if (nss160 > 2) {
+ if (ar->hw_params.vht160_mcs_rx_highest == 1560)
+ nss160 = 2;
+ else
+ nss160 = 1;
+ }
+ /* in case if peer is connected with vht160 or vht80+80, we
need to properly adjust rxnss parameters */
+ switch(arg->peer_phymode) {
+ case MODE_11AC_VHT80_80:
+ arg->peer_bw_rxnss_override =
BW_NSS_FWCONF_80_80(nss160);
+ /* fall through */
+ case MODE_11AC_VHT160:
+ arg->peer_bw_rxnss_override |=
BW_NSS_FWCONF_160(nss160);
+ break;
+ default:
+ break;
+ }
+ }
- ath10k_dbg(ar, ATH10K_DBG_MAC, "mac vht peer %pM max_mpdu %d flags
0x%x\n",
- sta->addr, arg->peer_max_mpdu, arg->peer_flags);
+ /* in case peer has no nss properties for some reasons, we set local
nss to minimum (1x1) to avoid a
+* firmware assert / crash. this applies only to VHT160 or VHT80+80 and
is a WAR for clients breaking
+* the spec.
+*/
- if (arg->peer_vht_rates.rx_max_rate &&
- (sta->vht_cap.cap & IEEE80211_VHT_CAP_SUPP_CHAN_WIDTH_MASK)) {
- switch (arg->peer_vht_rates.rx_max_rate) {
- case 1560:
- /* Must be 2x2 at 160Mhz is all it can do. */
- arg->peer_bw_rxnss_override = 2;
- break;
- case 780:
- /* Can only do 1x1 at 160Mhz (Long Guard Interval) */
- arg->peer_bw_rxnss_override = 1;
- break;
- }
+ if (!(arg->peer_num_spatial_streams ||
!ar->hw_params.vht160_mcs_rx_highest) && (arg->peer_phymode ==
MODE_11AC_VHT80_80 || arg->peer_phymode == MODE_11AC_VHT160)) {
+ arg->peer_bw_rxnss_override = BW_NSS_FWCONF_MAP_ENABLE;
}
+
+ ath10k_dbg(ar, ATH10K_DBG_MAC, "mac vht peer %pM max_mpdu %d flags
0x%x\n",
+ sta->addr, arg->peer_max_mpdu, arg->peer_flags);
}
static void ath10k_peer_assoc_h_qos(struct ath10k *ar,
@@ -2696,9 +2714,9 @@ static int ath10k_peer_assoc_prepare(struct ath10k *ar,
ath10k_peer_assoc_h_crypto(ar, vif, sta, arg);
ath10k_peer_assoc_h_rates(ar, vif, sta, arg);
ath10k_peer_assoc_h_ht(ar, vif, sta, arg);
+ ath10k_peer_assoc_h_phymode(ar, vif, sta, arg);
ath10k_peer_assoc_h_vht(ar, vif, sta, arg);
ath10k_peer_assoc_h_qos(ar, vif, sta, arg);
- ath10k_peer_assoc_h_phymode(ar, vif, sta, arg);
return 0;
}
diff --git a/drivers/net/wireless/ath/ath10k/wmi.c
b/drivers/net/wireless/ath/ath10k/wmi.c
index 2c36256a441d..3797dca317ff 100644
--- a/drivers/net/wireless/ath/ath10k/wmi.c
+++ b/drivers/net/wireless/ath/ath10k/wmi.c
@@ -7211,12 +7211,7 @@ ath10k_wm
Re: [PATCH v4] ath10k: fix crash in recent 3.5.3 9984 firmware due wrong handling of peer_bw_rxnss_override parameter
btw 4019 doesnt support vht160 in ath10k see vht160_mcs_rx_highest in
core params
if it does support vht160, ath10k must be adjusted here
Am 28.04.2018 um 17:37 schrieb Ben Greear:
On 04/28/2018 08:26 AM, Sebastian Gottschall wrote:
Am 28.04.2018 um 17:01 schrieb Ben Greear:
On 04/27/2018 05:47 PM, s.gottsch...@dd-wrt.com wrote:
From: Sebastian Gottschall
current handling of peer_bw_rxnss_override parameter is based on
guessing the VHT160/8080 capability by rx rate. this is wrong and
may lead
to a non initialized peer_bw_rxnss_override parameter which is
required since VHT160 operation mode only supports 2x2 chainmasks
in addition the original code
initialized the parameter with wrong masked values.
This patch uses the peer phymode and peer nss information for
correct initialisation of the peer_bw_rxnss_override parameter.
if this peer information is not available, we initialize the
parameter by minimum nss which is suggested by QCA as temporary
workaround according
to the QCA sourcecodes.
Signed-off-by: Sebastian Gottschall
v2: remove debug messages
v3: apply some cosmetics, update documentation
v4: fix compile warning and truncate nss to maximum of 2x2 since
current chipsets only support 2x2 at vht160
---
drivers/net/wireless/ath/ath10k/mac.c | 44
++-
drivers/net/wireless/ath/ath10k/wmi.c | 7 +
drivers/net/wireless/ath/ath10k/wmi.h | 14 -
3 files changed, 43 insertions(+), 22 deletions(-)
diff --git a/drivers/net/wireless/ath/ath10k/mac.c
b/drivers/net/wireless/ath/ath10k/mac.c
index 5be6386ede8f..de8a099c9f5a 100644
--- a/drivers/net/wireless/ath/ath10k/mac.c
+++ b/drivers/net/wireless/ath/ath10k/mac.c
@@ -2528,23 +2528,37 @@ static void ath10k_peer_assoc_h_vht(struct
ath10k *ar,
__le16_to_cpu(vht_cap->vht_mcs.tx_highest);
arg->peer_vht_rates.tx_mcs_set = ath10k_peer_assoc_h_vht_limit(
__le16_to_cpu(vht_cap->vht_mcs.tx_mcs_map), vht_mcs_mask);
+ arg->peer_bw_rxnss_override = 0;
+
+ if (arg->peer_num_spatial_streams) {
Check for the 80+80 or 160 instead of num-spatial-streams, if if
something has
nss == 0, then act like it is 1 instead since it is obviously
configured incorrect.
this check is bellow. see the switch statement for the VHT160, 80_80
case.
if nss 0, it must fail here since we cannot handle nss = 0, in that
case just bit 31 is masked
+ int nss160 = arg->peer_num_spatial_streams;
I think this line should be:
int nss160 = arg->peer_num_spatial_streams / 2;
no. makes no sense. 2 would get 1 and 1 turns to zero. makes no sense
read the macro BW_NSS_FWCONF_160 first. it already does nss160-1
this would lead to -1 if spatial_streams is 1
Well, nss160 should be the number of streams we can use at 160 Mhz.
The macro
can convert to zero-based api that the firmware wants. A 9984 will
have nss == 4,
but you want nss160 to be 2. A 4019 will have nss == 2, but nss160
should be 1.
if (nss160 == 0) { nss160 = 1; } /* deal with
mis-configured nss */
no
if peer_num_spatial_stream is 0 (so nss160 too), the code is not
triggered. but another code. same as above
If NSS was 1, and you do 1/2, you get zero.
if (!arg->peer_num_spatial_streams && (arg->peer_phymode ==
MODE_11AC_VHT80_80 || arg->peer_phymode == MODE_11AC_VHT160)) {
arg->peer_bw_rxnss_override = BW_NSS_FWCONF_MAP_ENABLE;
}
If you have a 4019 client, it will have
arg->peer_num_spatial_streams == 2, but
it can only do 1x1 at 160Mhz.
peer_num_spatial_streams is calculated from mcs rate set. so why
should 4019 announce 2x2 if it just can to 1x1.
have you checked the mcs set at assoc management frame?
You are confused about nss vs the 160nss. They are different. I do
not know how to explain
this better. Dig through the firmware source and look at how they are
used. Basically, if
rate-ctrl decides 80Mhz is best, it can send at the normal 80Mhz NSS
(so, 4 for 9984, 2 for 4019),
but if rate-ctrl uses 160, it uses the different nss max (2 for 9984,
one for 4019).
+ /* truncate vht160 nss value to 2x2 since all known
chipsets do not support more than 2x2 in vht160 modes */
+ if (nss160 > 2)
+ nss160 = 2;
+ /* in case if peer is connected with vht160 or vht80+80,
we need to properly adjust rxnss parameters */
+ switch(arg->peer_phymode) {
+ case MODE_11AC_VHT80_80:
+ arg->peer_bw_rxnss_override =
BW_NSS_FWCONF_80_80(nss160);
+ /* fall through */
+ case MODE_11AC_VHT160:
+ arg->peer_bw_rxnss_override |= BW_NSS_FWCONF_160(nss160);
From looking at firmware, it will just ignore the bits it does not
need, so you do not need
to special case adding the 80_80 fields, you can do more like my
patch and just always add
those bits.
i'm following the reference code. in case 80_80 only is configure
vht160 nd 80_80 must be masked. for everything else vht160 only must
be masked.
thats the
Re: [PATCH] nl80211: Reject disconnect commands except from conn_owner
On 28 April 2018 at 15:07, Kalle Valo wrote: > Andrew Zaborowski writes: >> Reject NL80211_CMD_DISCONNECT, NL80211_CMD_DISASSOCIATE, >> NL80211_CMD_DEAUTHENTICATE and NL80211_CMD_ASSOCIATE commands >> from clients other than the connection owner set in the connect, >> authenticate or associate commands, if it was set. >> >> The main point of this check is to prevent chaos when two processes >> try to use nl80211 at the same time, it's not a security measure. >> The same thing should possibly be done for JOIN_IBSS/LEAVE_IBSS and >> START_AP/STOP_AP. > > s-o-b missing. True, thanks. Also I was going to send this as an RFC. Best regards
