Signed-off-by: Tomislav Po?ega <[email protected]>
---
drivers/net/wireless/ralink/rt2x00/rt2800usb.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/wireless/ralink/rt2x00/rt2800usb.c b/drivers/net/wireless/ralink/rt2x00/rt2800usb.c
index 19eabf1..091a607 100644
--- a/drivers/net/wireless/ralink/rt2x00/rt2800usb.c
+++ b/drivers/net/wireless/ralink/rt2x00/rt2800usb.c
@@ -562,13 +562,13 @@ static void rt2800usb_fill_rxdone(struct queue_entry *entry,
* stripped it from the frame. Signal this to mac80211.
*/
rxdesc->flags |= RX_FLAG_MMIC_STRIPPED;
-
+
if (rxdesc->cipher_status == RX_CRYPTO_SUCCESS) {
rxdesc->flags |= RX_FLAG_DECRYPTED;
} else if (rxdesc->cipher_status == RX_CRYPTO_FAIL_MIC) {
/*
* In order to check the Michael Mic, the packet must have
- * been decrypted. Mac80211 doesnt check the MMIC failure
+ * been decrypted. Mac80211 doesnt check the MMIC failure
* flag to initiate MMIC countermeasures if the decoded flag
* has not been set.
*/
--
1.7.0.4
MFP can work with enabled HW crypt engine, but in this case
available bandwidth is reduced at least when connecting to
Archer C7 (QCA9558). Enable the feature for known to work chipsets-
MT7620, RT3070 and RT5390. Userspace setting for ieee80211w should
default to 0 in order to prevent unintentional bandwidth drop.
Signed-off-by: Tomislav Po?ega <[email protected]>
---
drivers/net/wireless/ralink/rt2x00/rt2800lib.c | 11 +++++++----
1 files changed, 7 insertions(+), 4 deletions(-)
diff --git a/drivers/net/wireless/ralink/rt2x00/rt2800lib.c b/drivers/net/wireless/ralink/rt2x00/rt2800lib.c
index a03b528..bb8204d 100644
--- a/drivers/net/wireless/ralink/rt2x00/rt2800lib.c
+++ b/drivers/net/wireless/ralink/rt2x00/rt2800lib.c
@@ -9326,6 +9326,13 @@ static int rt2800_probe_hw_mode(struct rt2x00_dev *rt2x00dev)
ieee80211_hw_set(rt2x00dev->hw, SIGNAL_DBM);
ieee80211_hw_set(rt2x00dev->hw, SUPPORTS_PS);
+ /* Experimental: Set MFP with HW crypto enabled. */
+ if (rt2x00_rt(rt2x00dev, RT3070) || rt2x00_rt(rt2x00dev, RT5390) ||
+ rt2x00_rt(rt2x00dev, RT6352))
+ ieee80211_hw_set(rt2x00dev->hw, MFP_CAPABLE);
+ else /* Set MFP if HW crypto is disabled. */
+ if (rt2800_hwcrypt_disabled(rt2x00dev))
+ ieee80211_hw_set(rt2x00dev->hw, MFP_CAPABLE);
/*
* Don't set IEEE80211_HW_HOST_BROADCAST_PS_BUFFERING for USB devices
* unless we are capable of sending the buffered frames out after the
@@ -9336,10 +9343,6 @@ static int rt2800_probe_hw_mode(struct rt2x00_dev *rt2x00dev)
if (!rt2x00_is_usb(rt2x00dev))
ieee80211_hw_set(rt2x00dev->hw, HOST_BROADCAST_PS_BUFFERING);
- /* Set MFP if HW crypto is disabled. */
- if (rt2800_hwcrypt_disabled(rt2x00dev))
- ieee80211_hw_set(rt2x00dev->hw, MFP_CAPABLE);
-
SET_IEEE80211_DEV(rt2x00dev->hw, rt2x00dev->dev);
SET_IEEE80211_PERM_ADDR(rt2x00dev->hw,
rt2800_eeprom_addr(rt2x00dev,
--
1.7.0.4
On Tue, Mar 12, 2019 at 08:11:42PM +0100, Tomislav Požega wrote:
> MFP can work with enabled HW crypt engine, but in this case
> available bandwidth is reduced at least when connecting to
> Archer C7 (QCA9558). Enable the feature for known to work chipsets-
> MT7620, RT3070 and RT5390. Userspace setting for ieee80211w should
> default to 0 in order to prevent unintentional bandwidth drop.
>
> Signed-off-by: Tomislav Po?ega <[email protected]>
> ---
> drivers/net/wireless/ralink/rt2x00/rt2800lib.c | 11 +++++++----
> 1 files changed, 7 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/net/wireless/ralink/rt2x00/rt2800lib.c b/drivers/net/wireless/ralink/rt2x00/rt2800lib.c
> index a03b528..bb8204d 100644
> --- a/drivers/net/wireless/ralink/rt2x00/rt2800lib.c
> +++ b/drivers/net/wireless/ralink/rt2x00/rt2800lib.c
> @@ -9326,6 +9326,13 @@ static int rt2800_probe_hw_mode(struct rt2x00_dev *rt2x00dev)
> ieee80211_hw_set(rt2x00dev->hw, SIGNAL_DBM);
> ieee80211_hw_set(rt2x00dev->hw, SUPPORTS_PS);
>
> + /* Experimental: Set MFP with HW crypto enabled. */
> + if (rt2x00_rt(rt2x00dev, RT3070) || rt2x00_rt(rt2x00dev, RT5390) ||
> + rt2x00_rt(rt2x00dev, RT6352))
> + ieee80211_hw_set(rt2x00dev->hw, MFP_CAPABLE);
Is not that we support MFP in hardware. We just return -EOPNOTSUPP
in rt2x00mac_set_key() when mac80211 will try to set MFP ciphers
(since rt2x00crypto_key_to_cipher() will return CIPHER_NONE) and
we fallback to software encryption.
Please repost patch that enable MFP unconditionally with
'Cc: [email protected]' tag.
Stanislaw
On 13/03/2019, Stanislaw Gruszka <[email protected]> wrote:
> On Tue, Mar 12, 2019 at 08:11:42PM +0100, Tomislav Požega wrote:
>> MFP can work with enabled HW crypt engine, but in this case
>> available bandwidth is reduced at least when connecting to
>> Archer C7 (QCA9558). Enable the feature for known to work chipsets-
>> MT7620, RT3070 and RT5390. Userspace setting for ieee80211w should
>> default to 0 in order to prevent unintentional bandwidth drop.
>>
>> Signed-off-by: Tomislav Po?ega <[email protected]>
>> ---
>> drivers/net/wireless/ralink/rt2x00/rt2800lib.c | 11 +++++++----
>> 1 files changed, 7 insertions(+), 4 deletions(-)
>>
>> diff --git a/drivers/net/wireless/ralink/rt2x00/rt2800lib.c
>> b/drivers/net/wireless/ralink/rt2x00/rt2800lib.c
>> index a03b528..bb8204d 100644
>> --- a/drivers/net/wireless/ralink/rt2x00/rt2800lib.c
>> +++ b/drivers/net/wireless/ralink/rt2x00/rt2800lib.c
>> @@ -9326,6 +9326,13 @@ static int rt2800_probe_hw_mode(struct rt2x00_dev
>> *rt2x00dev)
>> ieee80211_hw_set(rt2x00dev->hw, SIGNAL_DBM);
>> ieee80211_hw_set(rt2x00dev->hw, SUPPORTS_PS);
>>
>> + /* Experimental: Set MFP with HW crypto enabled. */
>> + if (rt2x00_rt(rt2x00dev, RT3070) || rt2x00_rt(rt2x00dev, RT5390) ||
>> + rt2x00_rt(rt2x00dev, RT6352))
>> + ieee80211_hw_set(rt2x00dev->hw, MFP_CAPABLE);
>
> Is not that we support MFP in hardware. We just return -EOPNOTSUPP
> in rt2x00mac_set_key() when mac80211 will try to set MFP ciphers
> (since rt2x00crypto_key_to_cipher() will return CIPHER_NONE) and
> we fallback to software encryption.
>
> Please repost patch that enable MFP unconditionally with
> 'Cc: [email protected]' tag.
>
> Stanislaw
>
No, I have not test any other chipsets besides the ones I enabled it
for. It is possible this would cause problems on other devices, so
just enable it for the known to work ones.
On Wed, Mar 13, 2019 at 02:02:32PM +0100, Tom Psyborg wrote:
> On 13/03/2019, Stanislaw Gruszka <[email protected]> wrote:
> > On Tue, Mar 12, 2019 at 08:11:42PM +0100, Tomislav Požega wrote:
> >> MFP can work with enabled HW crypt engine, but in this case
> >> available bandwidth is reduced at least when connecting to
> >> Archer C7 (QCA9558). Enable the feature for known to work chipsets-
> >> MT7620, RT3070 and RT5390. Userspace setting for ieee80211w should
> >> default to 0 in order to prevent unintentional bandwidth drop.
> >>
> >> Signed-off-by: Tomislav Po?ega <[email protected]>
> >> ---
> >> drivers/net/wireless/ralink/rt2x00/rt2800lib.c | 11 +++++++----
> >> 1 files changed, 7 insertions(+), 4 deletions(-)
> >>
> >> diff --git a/drivers/net/wireless/ralink/rt2x00/rt2800lib.c
> >> b/drivers/net/wireless/ralink/rt2x00/rt2800lib.c
> >> index a03b528..bb8204d 100644
> >> --- a/drivers/net/wireless/ralink/rt2x00/rt2800lib.c
> >> +++ b/drivers/net/wireless/ralink/rt2x00/rt2800lib.c
> >> @@ -9326,6 +9326,13 @@ static int rt2800_probe_hw_mode(struct rt2x00_dev
> >> *rt2x00dev)
> >> ieee80211_hw_set(rt2x00dev->hw, SIGNAL_DBM);
> >> ieee80211_hw_set(rt2x00dev->hw, SUPPORTS_PS);
> >>
> >> + /* Experimental: Set MFP with HW crypto enabled. */
> >> + if (rt2x00_rt(rt2x00dev, RT3070) || rt2x00_rt(rt2x00dev, RT5390) ||
> >> + rt2x00_rt(rt2x00dev, RT6352))
> >> + ieee80211_hw_set(rt2x00dev->hw, MFP_CAPABLE);
> >
> > Is not that we support MFP in hardware. We just return -EOPNOTSUPP
> > in rt2x00mac_set_key() when mac80211 will try to set MFP ciphers
> > (since rt2x00crypto_key_to_cipher() will return CIPHER_NONE) and
> > we fallback to software encryption.
> >
> > Please repost patch that enable MFP unconditionally with
> > 'Cc: [email protected]' tag.
> >
> > Stanislaw
> >
>
> No, I have not test any other chipsets besides the ones I enabled it
> for. It is possible this would cause problems on other devices, so
> just enable it for the known to work ones.
It's just matter of sending already encrypted frames. All chipsets
handle that.
Stanislaw
On 13/03/2019, Stanislaw Gruszka <[email protected]> wrote:
> On Wed, Mar 13, 2019 at 02:02:32PM +0100, Tom Psyborg wrote:
>> On 13/03/2019, Stanislaw Gruszka <[email protected]> wrote:
>> > On Tue, Mar 12, 2019 at 08:11:42PM +0100, Tomislav Požega wrote:
>> >> MFP can work with enabled HW crypt engine, but in this case
>> >> available bandwidth is reduced at least when connecting to
>> >> Archer C7 (QCA9558). Enable the feature for known to work chipsets-
>> >> MT7620, RT3070 and RT5390. Userspace setting for ieee80211w should
>> >> default to 0 in order to prevent unintentional bandwidth drop.
>> >>
>> >> Signed-off-by: Tomislav Po?ega <[email protected]>
>> >> ---
>> >> drivers/net/wireless/ralink/rt2x00/rt2800lib.c | 11 +++++++----
>> >> 1 files changed, 7 insertions(+), 4 deletions(-)
>> >>
>> >> diff --git a/drivers/net/wireless/ralink/rt2x00/rt2800lib.c
>> >> b/drivers/net/wireless/ralink/rt2x00/rt2800lib.c
>> >> index a03b528..bb8204d 100644
>> >> --- a/drivers/net/wireless/ralink/rt2x00/rt2800lib.c
>> >> +++ b/drivers/net/wireless/ralink/rt2x00/rt2800lib.c
>> >> @@ -9326,6 +9326,13 @@ static int rt2800_probe_hw_mode(struct
>> >> rt2x00_dev
>> >> *rt2x00dev)
>> >> ieee80211_hw_set(rt2x00dev->hw, SIGNAL_DBM);
>> >> ieee80211_hw_set(rt2x00dev->hw, SUPPORTS_PS);
>> >>
>> >> + /* Experimental: Set MFP with HW crypto enabled. */
>> >> + if (rt2x00_rt(rt2x00dev, RT3070) || rt2x00_rt(rt2x00dev, RT5390) ||
>> >> + rt2x00_rt(rt2x00dev, RT6352))
>> >> + ieee80211_hw_set(rt2x00dev->hw, MFP_CAPABLE);
>> >
>> > Is not that we support MFP in hardware. We just return -EOPNOTSUPP
>> > in rt2x00mac_set_key() when mac80211 will try to set MFP ciphers
>> > (since rt2x00crypto_key_to_cipher() will return CIPHER_NONE) and
>> > we fallback to software encryption.
>> >
>> > Please repost patch that enable MFP unconditionally with
>> > 'Cc: [email protected]' tag.
>> >
>> > Stanislaw
>> >
>>
>> No, I have not test any other chipsets besides the ones I enabled it
>> for. It is possible this would cause problems on other devices, so
>> just enable it for the known to work ones.
>
> It's just matter of sending already encrypted frames. All chipsets
> handle that.
>
> Stanislaw
>
The question is how well all chipsets handle that. I've seen some lags
too with MFP enabled connection. While being about 40-50% lower,
throughput would still occasionally drop to very low values, like
800Kbps.
On Wed, Mar 13, 2019 at 02:48:01PM +0100, Tom Psyborg wrote:
> On 13/03/2019, Stanislaw Gruszka <[email protected]> wrote:
> > On Wed, Mar 13, 2019 at 02:02:32PM +0100, Tom Psyborg wrote:
> >> On 13/03/2019, Stanislaw Gruszka <[email protected]> wrote:
> >> > On Tue, Mar 12, 2019 at 08:11:42PM +0100, Tomislav Požega wrote:
> >> >> MFP can work with enabled HW crypt engine, but in this case
> >> >> available bandwidth is reduced at least when connecting to
> >> >> Archer C7 (QCA9558). Enable the feature for known to work chipsets-
> >> >> MT7620, RT3070 and RT5390. Userspace setting for ieee80211w should
> >> >> default to 0 in order to prevent unintentional bandwidth drop.
> >> >>
> >> >> Signed-off-by: Tomislav Po?ega <[email protected]>
> >> >> ---
> >> >> drivers/net/wireless/ralink/rt2x00/rt2800lib.c | 11 +++++++----
> >> >> 1 files changed, 7 insertions(+), 4 deletions(-)
> >> >>
> >> >> diff --git a/drivers/net/wireless/ralink/rt2x00/rt2800lib.c
> >> >> b/drivers/net/wireless/ralink/rt2x00/rt2800lib.c
> >> >> index a03b528..bb8204d 100644
> >> >> --- a/drivers/net/wireless/ralink/rt2x00/rt2800lib.c
> >> >> +++ b/drivers/net/wireless/ralink/rt2x00/rt2800lib.c
> >> >> @@ -9326,6 +9326,13 @@ static int rt2800_probe_hw_mode(struct
> >> >> rt2x00_dev
> >> >> *rt2x00dev)
> >> >> ieee80211_hw_set(rt2x00dev->hw, SIGNAL_DBM);
> >> >> ieee80211_hw_set(rt2x00dev->hw, SUPPORTS_PS);
> >> >>
> >> >> + /* Experimental: Set MFP with HW crypto enabled. */
> >> >> + if (rt2x00_rt(rt2x00dev, RT3070) || rt2x00_rt(rt2x00dev, RT5390) ||
> >> >> + rt2x00_rt(rt2x00dev, RT6352))
> >> >> + ieee80211_hw_set(rt2x00dev->hw, MFP_CAPABLE);
> >> >
> >> > Is not that we support MFP in hardware. We just return -EOPNOTSUPP
> >> > in rt2x00mac_set_key() when mac80211 will try to set MFP ciphers
> >> > (since rt2x00crypto_key_to_cipher() will return CIPHER_NONE) and
> >> > we fallback to software encryption.
> >> >
> >> > Please repost patch that enable MFP unconditionally with
> >> > 'Cc: [email protected]' tag.
> >> >
> >> > Stanislaw
> >> >
> >>
> >> No, I have not test any other chipsets besides the ones I enabled it
> >> for. It is possible this would cause problems on other devices, so
> >> just enable it for the known to work ones.
> >
> > It's just matter of sending already encrypted frames. All chipsets
> > handle that.
> >
> > Stanislaw
> >
>
> The question is how well all chipsets handle that. I've seen some lags
> too with MFP enabled connection. While being about 40-50% lower,
> throughput would still occasionally drop to very low values, like
> 800Kbps.
The only reason I can image that might have impact on throughput
in this case is limited CPU power since encryption is done in
software. Would be good to compare with PA2 with nohwcrypte, if
there are similar lags. However MFP can require more CPU power.
Stanislaw
On 13/03/2019, Stanislaw Gruszka <[email protected]> wrote:
> On Wed, Mar 13, 2019 at 02:48:01PM +0100, Tom Psyborg wrote:
>> On 13/03/2019, Stanislaw Gruszka <[email protected]> wrote:
>> > On Wed, Mar 13, 2019 at 02:02:32PM +0100, Tom Psyborg wrote:
>> >> On 13/03/2019, Stanislaw Gruszka <[email protected]> wrote:
>> >> > On Tue, Mar 12, 2019 at 08:11:42PM +0100, Tomislav Požega wrote:
>> >> >> MFP can work with enabled HW crypt engine, but in this case
>> >> >> available bandwidth is reduced at least when connecting to
>> >> >> Archer C7 (QCA9558). Enable the feature for known to work chipsets-
>> >> >> MT7620, RT3070 and RT5390. Userspace setting for ieee80211w should
>> >> >> default to 0 in order to prevent unintentional bandwidth drop.
>> >> >>
>> >> >> Signed-off-by: Tomislav Po?ega <[email protected]>
>> >> >> ---
>> >> >> drivers/net/wireless/ralink/rt2x00/rt2800lib.c | 11 +++++++----
>> >> >> 1 files changed, 7 insertions(+), 4 deletions(-)
>> >> >>
>> >> >> diff --git a/drivers/net/wireless/ralink/rt2x00/rt2800lib.c
>> >> >> b/drivers/net/wireless/ralink/rt2x00/rt2800lib.c
>> >> >> index a03b528..bb8204d 100644
>> >> >> --- a/drivers/net/wireless/ralink/rt2x00/rt2800lib.c
>> >> >> +++ b/drivers/net/wireless/ralink/rt2x00/rt2800lib.c
>> >> >> @@ -9326,6 +9326,13 @@ static int rt2800_probe_hw_mode(struct
>> >> >> rt2x00_dev
>> >> >> *rt2x00dev)
>> >> >> ieee80211_hw_set(rt2x00dev->hw, SIGNAL_DBM);
>> >> >> ieee80211_hw_set(rt2x00dev->hw, SUPPORTS_PS);
>> >> >>
>> >> >> + /* Experimental: Set MFP with HW crypto enabled. */
>> >> >> + if (rt2x00_rt(rt2x00dev, RT3070) || rt2x00_rt(rt2x00dev, RT5390)
>> >> >> ||
>> >> >> + rt2x00_rt(rt2x00dev, RT6352))
>> >> >> + ieee80211_hw_set(rt2x00dev->hw, MFP_CAPABLE);
>> >> >
>> >> > Is not that we support MFP in hardware. We just return -EOPNOTSUPP
>> >> > in rt2x00mac_set_key() when mac80211 will try to set MFP ciphers
>> >> > (since rt2x00crypto_key_to_cipher() will return CIPHER_NONE) and
>> >> > we fallback to software encryption.
>> >> >
>> >> > Please repost patch that enable MFP unconditionally with
>> >> > 'Cc: [email protected]' tag.
>> >> >
>> >> > Stanislaw
>> >> >
>> >>
>> >> No, I have not test any other chipsets besides the ones I enabled it
>> >> for. It is possible this would cause problems on other devices, so
>> >> just enable it for the known to work ones.
>> >
>> > It's just matter of sending already encrypted frames. All chipsets
>> > handle that.
>> >
>> > Stanislaw
>> >
>>
>> The question is how well all chipsets handle that. I've seen some lags
>> too with MFP enabled connection. While being about 40-50% lower,
>> throughput would still occasionally drop to very low values, like
>> 800Kbps.
>
> The only reason I can image that might have impact on throughput
> in this case is limited CPU power since encryption is done in
> software. Would be good to compare with PA2 with nohwcrypte, if
> there are similar lags. However MFP can require more CPU power.
>
> Stanislaw
>
nohwcrypt=y mfp=require: there was no throughput drop, no lag,
measured about 80-85Mbps but the connection frozen after a minute or
two. might be related to rekeying.
CPU power cannot be the problem since I run it on laptop (2x2.20GHz)
hwcrypt enabled results are low, some lag but connection remained stable:
root@OpenWrt:~# iperf -c 192.168.1.2 -i 1 -t 20 -P 4
------------------------------------------------------------
Client connecting to 192.168.1.2, TCP port 5001
TCP window size: 43.8 KByte (default)
------------------------------------------------------------
[ 4] local 192.168.1.1 port 36274 connected with 192.168.1.2 port 5001
[ 5] local 192.168.1.1 port 36276 connected with 192.168.1.2 port 5001
[ 3] local 192.168.1.1 port 36272 connected with 192.168.1.2 port 5001
[ 6] local 192.168.1.1 port 36278 connected with 192.168.1.2 port 5001
[ ID] Interval Transfer Bandwidth
[ 4] 0.0- 1.0 sec 1.00 MBytes 8.39 Mbits/sec
[ 5] 0.0- 1.0 sec 1.00 MBytes 8.39 Mbits/sec
[ 3] 0.0- 1.0 sec 1.00 MBytes 8.39 Mbits/sec
[ 6] 0.0- 1.0 sec 1.00 MBytes 8.39 Mbits/sec
[SUM] 0.0- 1.0 sec 4.00 MBytes 33.6 Mbits/sec
[ 4] 1.0- 2.0 sec 896 KBytes 7.34 Mbits/sec
[ 3] 1.0- 2.0 sec 896 KBytes 7.34 Mbits/sec
[ 5] 1.0- 2.0 sec 896 KBytes 7.34 Mbits/sec
[ 6] 1.0- 2.0 sec 896 KBytes 7.34 Mbits/sec
[SUM] 1.0- 2.0 sec 3.50 MBytes 29.4 Mbits/sec
[ 5] 2.0- 3.0 sec 896 KBytes 7.34 Mbits/sec
[ 4] 2.0- 3.0 sec 896 KBytes 7.34 Mbits/sec
[ 3] 2.0- 3.0 sec 896 KBytes 7.34 Mbits/sec
[ 6] 2.0- 3.0 sec 896 KBytes 7.34 Mbits/sec
[SUM] 2.0- 3.0 sec 3.50 MBytes 29.4 Mbits/sec
[ 4] 3.0- 4.0 sec 896 KBytes 7.34 Mbits/sec
[ 5] 3.0- 4.0 sec 896 KBytes 7.34 Mbits/sec
[ 3] 3.0- 4.0 sec 896 KBytes 7.34 Mbits/sec
[ 6] 3.0- 4.0 sec 896 KBytes 7.34 Mbits/sec
[SUM] 3.0- 4.0 sec 3.50 MBytes 29.4 Mbits/sec
[ 4] 4.0- 5.0 sec 896 KBytes 7.34 Mbits/sec
[ 5] 4.0- 5.0 sec 896 KBytes 7.34 Mbits/sec
[ 3] 4.0- 5.0 sec 896 KBytes 7.34 Mbits/sec
[ 6] 4.0- 5.0 sec 896 KBytes 7.34 Mbits/sec
[SUM] 4.0- 5.0 sec 3.50 MBytes 29.4 Mbits/sec
[ 4] 5.0- 6.0 sec 896 KBytes 7.34 Mbits/sec
[ 6] 5.0- 6.0 sec 896 KBytes 7.34 Mbits/sec
[ 5] 5.0- 6.0 sec 896 KBytes 7.34 Mbits/sec
[ 3] 5.0- 6.0 sec 896 KBytes 7.34 Mbits/sec
[SUM] 5.0- 6.0 sec 3.50 MBytes 29.4 Mbits/sec
[ 4] 6.0- 7.0 sec 896 KBytes 7.34 Mbits/sec
[ 5] 6.0- 7.0 sec 896 KBytes 7.34 Mbits/sec
[ 3] 6.0- 7.0 sec 896 KBytes 7.34 Mbits/sec
[ 6] 6.0- 7.0 sec 896 KBytes 7.34 Mbits/sec
[SUM] 6.0- 7.0 sec 3.50 MBytes 29.4 Mbits/sec
[ 4] 7.0- 8.0 sec 896 KBytes 7.34 Mbits/sec
[ 5] 7.0- 8.0 sec 896 KBytes 7.34 Mbits/sec
[ 3] 7.0- 8.0 sec 896 KBytes 7.34 Mbits/sec
[ 6] 7.0- 8.0 sec 896 KBytes 7.34 Mbits/sec
[SUM] 7.0- 8.0 sec 3.50 MBytes 29.4 Mbits/sec
[ 6] 8.0- 9.0 sec 896 KBytes 7.34 Mbits/sec
[ 4] 8.0- 9.0 sec 1.00 MBytes 8.39 Mbits/sec
[ 5] 8.0- 9.0 sec 1.00 MBytes 8.39 Mbits/sec
[ 3] 8.0- 9.0 sec 1.00 MBytes 8.39 Mbits/sec
[SUM] 8.0- 9.0 sec 3.88 MBytes 32.5 Mbits/sec
[ 4] 9.0-10.0 sec 896 KBytes 7.34 Mbits/sec
[ 5] 9.0-10.0 sec 896 KBytes 7.34 Mbits/sec
[ 6] 9.0-10.0 sec 1.00 MBytes 8.39 Mbits/sec
[ 3] 9.0-10.0 sec 896 KBytes 7.34 Mbits/sec
[SUM] 9.0-10.0 sec 3.62 MBytes 30.4 Mbits/sec
[ 4] 10.0-11.0 sec 896 KBytes 7.34 Mbits/sec
[ 3] 10.0-11.0 sec 896 KBytes 7.34 Mbits/sec
[ 6] 10.0-11.0 sec 896 KBytes 7.34 Mbits/sec
[ 5] 10.0-11.0 sec 896 KBytes 7.34 Mbits/sec
[SUM] 10.0-11.0 sec 3.50 MBytes 29.4 Mbits/sec
[ 4] 11.0-12.0 sec 777 KBytes 6.36 Mbits/sec
[ 5] 11.0-12.0 sec 797 KBytes 6.53 Mbits/sec
[ 3] 11.0-12.0 sec 780 KBytes 6.39 Mbits/sec
[ 6] 11.0-12.0 sec 785 KBytes 6.43 Mbits/sec
[SUM] 11.0-12.0 sec 3.06 MBytes 25.7 Mbits/sec
[ 3] 12.0-13.0 sec 137 KBytes 1.12 Mbits/sec
[ 4] 12.0-13.0 sec 148 KBytes 1.21 Mbits/sec
[ 5] 12.0-13.0 sec 128 KBytes 1.05 Mbits/sec
[ 6] 12.0-13.0 sec 128 KBytes 1.05 Mbits/sec
[SUM] 12.0-13.0 sec 541 KBytes 4.43 Mbits/sec
[ 4] 13.0-14.0 sec 853 KBytes 6.99 Mbits/sec
[ 5] 13.0-14.0 sec 853 KBytes 6.99 Mbits/sec
[ 3] 13.0-14.0 sec 853 KBytes 6.99 Mbits/sec
[ 6] 13.0-14.0 sec 852 KBytes 6.98 Mbits/sec
[SUM] 13.0-14.0 sec 3.33 MBytes 27.9 Mbits/sec
[ 6] 14.0-15.0 sec 144 KBytes 1.18 Mbits/sec
[ 4] 14.0-15.0 sec 145 KBytes 1.19 Mbits/sec
[ 5] 14.0-15.0 sec 142 KBytes 1.17 Mbits/sec
[ 3] 14.0-15.0 sec 147 KBytes 1.20 Mbits/sec
[SUM] 14.0-15.0 sec 578 KBytes 4.73 Mbits/sec
[ 6] 15.0-16.0 sec 768 KBytes 6.29 Mbits/sec
[ 4] 15.0-16.0 sec 768 KBytes 6.29 Mbits/sec
[ 5] 15.0-16.0 sec 768 KBytes 6.29 Mbits/sec
[ 3] 15.0-16.0 sec 768 KBytes 6.29 Mbits/sec
[SUM] 15.0-16.0 sec 3.00 MBytes 25.2 Mbits/sec
[ 4] 16.0-17.0 sec 896 KBytes 7.34 Mbits/sec
[ 5] 16.0-17.0 sec 896 KBytes 7.34 Mbits/sec
[ 6] 16.0-17.0 sec 896 KBytes 7.34 Mbits/sec
[ 3] 16.0-17.0 sec 896 KBytes 7.34 Mbits/sec
[SUM] 16.0-17.0 sec 3.50 MBytes 29.4 Mbits/sec
[ 5] 17.0-18.0 sec 896 KBytes 7.34 Mbits/sec
[ 6] 17.0-18.0 sec 896 KBytes 7.34 Mbits/sec
[ 4] 17.0-18.0 sec 896 KBytes 7.34 Mbits/sec
[ 3] 17.0-18.0 sec 896 KBytes 7.34 Mbits/sec
[SUM] 17.0-18.0 sec 3.50 MBytes 29.4 Mbits/sec
[ 4] 18.0-19.0 sec 896 KBytes 7.34 Mbits/sec
[ 5] 18.0-19.0 sec 896 KBytes 7.34 Mbits/sec
[ 6] 18.0-19.0 sec 896 KBytes 7.34 Mbits/sec
[ 3] 18.0-19.0 sec 1.00 MBytes 8.39 Mbits/sec
[SUM] 18.0-19.0 sec 3.62 MBytes 30.4 Mbits/sec
[ 6] 19.0-20.0 sec 1.00 MBytes 8.39 Mbits/sec
[ 6] 0.0-20.1 sec 16.1 MBytes 6.73 Mbits/sec
[ 5] 19.0-20.0 sec 1.00 MBytes 8.39 Mbits/sec
[ 5] 0.0-20.1 sec 16.1 MBytes 6.73 Mbits/sec
[ 4] 19.0-20.0 sec 1.00 MBytes 8.39 Mbits/sec
[ 4] 0.0-20.1 sec 16.1 MBytes 6.73 Mbits/sec
[ 3] 19.0-20.0 sec 896 KBytes 7.34 Mbits/sec
[SUM] 19.0-20.0 sec 3.88 MBytes 32.5 Mbits/sec
[ 3] 0.0-20.1 sec 16.1 MBytes 6.73 Mbits/sec
[SUM] 0.0-20.1 sec 64.5 MBytes 26.9 Mbits/sec
ubuntu@ubuntu:~$ iperf -c 192.168.1.1 -i 1 -t 20 -P 4
------------------------------------------------------------
Client connecting to 192.168.1.1, TCP port 5001
TCP window size: 85.0 KByte (default)
------------------------------------------------------------
[ 3] local 192.168.1.2 port 48396 connected with 192.168.1.1 port 5001
[ 4] local 192.168.1.2 port 48398 connected with 192.168.1.1 port 5001
[ 5] local 192.168.1.2 port 48400 connected with 192.168.1.1 port 5001
[ 6] local 192.168.1.2 port 48402 connected with 192.168.1.1 port 5001
[ ID] Interval Transfer Bandwidth
[ 3] 0.0- 1.0 sec 896 KBytes 7.34 Mbits/sec
[ 5] 0.0- 1.0 sec 896 KBytes 7.34 Mbits/sec
[ 4] 0.0- 1.0 sec 896 KBytes 7.34 Mbits/sec
[ 6] 0.0- 1.0 sec 896 KBytes 7.34 Mbits/sec
[SUM] 0.0- 1.0 sec 3.50 MBytes 29.4 Mbits/sec
[ 4] 1.0- 2.0 sec 384 KBytes 3.15 Mbits/sec
[ 5] 1.0- 2.0 sec 384 KBytes 3.15 Mbits/sec
[ 3] 1.0- 2.0 sec 384 KBytes 3.15 Mbits/sec
[ 6] 1.0- 2.0 sec 384 KBytes 3.15 Mbits/sec
[SUM] 1.0- 2.0 sec 1.50 MBytes 12.6 Mbits/sec
[ 5] 2.0- 3.0 sec 768 KBytes 6.29 Mbits/sec
[ 6] 2.0- 3.0 sec 768 KBytes 6.29 Mbits/sec
[ 4] 2.0- 3.0 sec 768 KBytes 6.29 Mbits/sec
[ 3] 2.0- 3.0 sec 896 KBytes 7.34 Mbits/sec
[SUM] 2.0- 3.0 sec 3.12 MBytes 26.2 Mbits/sec
[ 5] 3.0- 4.0 sec 384 KBytes 3.15 Mbits/sec
[ 3] 3.0- 4.0 sec 256 KBytes 2.10 Mbits/sec
[ 4] 3.0- 4.0 sec 384 KBytes 3.15 Mbits/sec
[ 6] 3.0- 4.0 sec 384 KBytes 3.15 Mbits/sec
[SUM] 3.0- 4.0 sec 1.38 MBytes 11.5 Mbits/sec
[ 3] 4.0- 5.0 sec 768 KBytes 6.29 Mbits/sec
[ 4] 4.0- 5.0 sec 640 KBytes 5.24 Mbits/sec
[ 6] 4.0- 5.0 sec 640 KBytes 5.24 Mbits/sec
[ 5] 4.0- 5.0 sec 768 KBytes 6.29 Mbits/sec
[SUM] 4.0- 5.0 sec 2.75 MBytes 23.1 Mbits/sec
[ 3] 5.0- 6.0 sec 1.12 MBytes 9.44 Mbits/sec
[ 6] 5.0- 6.0 sec 1.38 MBytes 11.5 Mbits/sec
[ 5] 5.0- 6.0 sec 1.25 MBytes 10.5 Mbits/sec
[ 4] 5.0- 6.0 sec 1.38 MBytes 11.5 Mbits/sec
[SUM] 5.0- 6.0 sec 5.12 MBytes 43.0 Mbits/sec
[ 4] 6.0- 7.0 sec 1.25 MBytes 10.5 Mbits/sec
[ 5] 6.0- 7.0 sec 1.12 MBytes 9.44 Mbits/sec
[ 3] 6.0- 7.0 sec 1.25 MBytes 10.5 Mbits/sec
[ 6] 6.0- 7.0 sec 1.38 MBytes 11.5 Mbits/sec
[SUM] 6.0- 7.0 sec 5.00 MBytes 41.9 Mbits/sec
[ 4] 7.0- 8.0 sec 1.38 MBytes 11.5 Mbits/sec
[ 3] 7.0- 8.0 sec 1.25 MBytes 10.5 Mbits/sec
[ 6] 7.0- 8.0 sec 1.38 MBytes 11.5 Mbits/sec
[ 5] 7.0- 8.0 sec 1.38 MBytes 11.5 Mbits/sec
[SUM] 7.0- 8.0 sec 5.38 MBytes 45.1 Mbits/sec
[ 6] 8.0- 9.0 sec 1.38 MBytes 11.5 Mbits/sec
[ 3] 8.0- 9.0 sec 1.50 MBytes 12.6 Mbits/sec
[ 5] 8.0- 9.0 sec 1.38 MBytes 11.5 Mbits/sec
[ 4] 8.0- 9.0 sec 1.25 MBytes 10.5 Mbits/sec
[SUM] 8.0- 9.0 sec 5.50 MBytes 46.1 Mbits/sec
[ 5] 9.0-10.0 sec 1.25 MBytes 10.5 Mbits/sec
[ 4] 9.0-10.0 sec 1.12 MBytes 9.44 Mbits/sec
[ 6] 9.0-10.0 sec 1.50 MBytes 12.6 Mbits/sec
[ 3] 9.0-10.0 sec 1.38 MBytes 11.5 Mbits/sec
[SUM] 9.0-10.0 sec 5.25 MBytes 44.0 Mbits/sec
[ 3] 10.0-11.0 sec 1.12 MBytes 9.44 Mbits/sec
[ 6] 10.0-11.0 sec 1.38 MBytes 11.5 Mbits/sec
[ 4] 10.0-11.0 sec 1.25 MBytes 10.5 Mbits/sec
[ 5] 10.0-11.0 sec 1.25 MBytes 10.5 Mbits/sec
[SUM] 10.0-11.0 sec 5.00 MBytes 41.9 Mbits/sec
[ 5] 11.0-12.0 sec 1.25 MBytes 10.5 Mbits/sec
[ 4] 11.0-12.0 sec 1.38 MBytes 11.5 Mbits/sec
[ 6] 11.0-12.0 sec 1.38 MBytes 11.5 Mbits/sec
[ 3] 11.0-12.0 sec 1.38 MBytes 11.5 Mbits/sec
[SUM] 11.0-12.0 sec 5.38 MBytes 45.1 Mbits/sec
[ 5] 12.0-13.0 sec 1.38 MBytes 11.5 Mbits/sec
[ 6] 12.0-13.0 sec 1.25 MBytes 10.5 Mbits/sec
[ 3] 12.0-13.0 sec 1.50 MBytes 12.6 Mbits/sec
[ 4] 12.0-13.0 sec 1.25 MBytes 10.5 Mbits/sec
[SUM] 12.0-13.0 sec 5.38 MBytes 45.1 Mbits/sec
[ 4] 13.0-14.0 sec 1.25 MBytes 10.5 Mbits/sec
[ 5] 13.0-14.0 sec 1.12 MBytes 9.44 Mbits/sec
[ 6] 13.0-14.0 sec 1.25 MBytes 10.5 Mbits/sec
[ 3] 13.0-14.0 sec 1.38 MBytes 11.5 Mbits/sec
[SUM] 13.0-14.0 sec 5.00 MBytes 41.9 Mbits/sec
[ 3] 14.0-15.0 sec 1.12 MBytes 9.44 Mbits/sec
[ 6] 14.0-15.0 sec 1.38 MBytes 11.5 Mbits/sec
[ 4] 14.0-15.0 sec 1.38 MBytes 11.5 Mbits/sec
[ 5] 14.0-15.0 sec 1.25 MBytes 10.5 Mbits/sec
[SUM] 14.0-15.0 sec 5.12 MBytes 43.0 Mbits/sec
[ 6] 15.0-16.0 sec 1.00 MBytes 8.39 Mbits/sec
[ 4] 15.0-16.0 sec 1.00 MBytes 8.39 Mbits/sec
[ 5] 15.0-16.0 sec 896 KBytes 7.34 Mbits/sec
[ 3] 15.0-16.0 sec 1.00 MBytes 8.39 Mbits/sec
[SUM] 15.0-16.0 sec 3.88 MBytes 32.5 Mbits/sec
[ 6] 16.0-17.0 sec 384 KBytes 3.15 Mbits/sec
[ 3] 16.0-17.0 sec 256 KBytes 2.10 Mbits/sec
[ 5] 16.0-17.0 sec 256 KBytes 2.10 Mbits/sec
[ 4] 16.0-17.0 sec 384 KBytes 3.15 Mbits/sec
[SUM] 16.0-17.0 sec 1.25 MBytes 10.5 Mbits/sec
[ 4] 17.0-18.0 sec 896 KBytes 7.34 Mbits/sec
[ 6] 17.0-18.0 sec 1.00 MBytes 8.39 Mbits/sec
[ 5] 17.0-18.0 sec 1.00 MBytes 8.39 Mbits/sec
[ 3] 17.0-18.0 sec 1.00 MBytes 8.39 Mbits/sec
[SUM] 17.0-18.0 sec 3.88 MBytes 32.5 Mbits/sec
[ 3] 18.0-19.0 sec 256 KBytes 2.10 Mbits/sec
[ 4] 18.0-19.0 sec 256 KBytes 2.10 Mbits/sec
[ 5] 18.0-19.0 sec 256 KBytes 2.10 Mbits/sec
[ 6] 18.0-19.0 sec 256 KBytes 2.10 Mbits/sec
[SUM] 18.0-19.0 sec 1.00 MBytes 8.39 Mbits/sec
[ 6] 19.0-20.0 sec 1.38 MBytes 11.5 Mbits/sec
[ 6] 0.0-20.1 sec 20.8 MBytes 8.65 Mbits/sec
[ 4] 19.0-20.0 sec 1.12 MBytes 9.44 Mbits/sec
[ 4] 0.0-20.1 sec 19.6 MBytes 8.18 Mbits/sec
[ 3] 19.0-20.0 sec 1.38 MBytes 11.5 Mbits/sec
[ 3] 0.0-20.1 sec 20.1 MBytes 8.38 Mbits/sec
[ 5] 19.0-20.0 sec 1.38 MBytes 11.5 Mbits/sec
[SUM] 19.0-20.0 sec 5.25 MBytes 44.0 Mbits/sec
[ 5] 0.0-20.1 sec 19.6 MBytes 8.17 Mbits/sec
[SUM] 0.0-20.1 sec 80.1 MBytes 33.4 Mbits/sec
On Wed, Mar 13, 2019 at 03:41:50PM +0100, Tom Psyborg wrote:
> >> > It's just matter of sending already encrypted frames. All chipsets
> >> > handle that.
> >> >
> >> > Stanislaw
> >> >
> >>
> >> The question is how well all chipsets handle that. I've seen some lags
> >> too with MFP enabled connection. While being about 40-50% lower,
> >> throughput would still occasionally drop to very low values, like
> >> 800Kbps.
> >
> > The only reason I can image that might have impact on throughput
> > in this case is limited CPU power since encryption is done in
> > software. Would be good to compare with PA2 with nohwcrypte, if
> > there are similar lags. However MFP can require more CPU power.
> >
> > Stanislaw
> >
>
> nohwcrypt=y mfp=require: there was no throughput drop, no lag,
> measured about 80-85Mbps but the connection frozen after a minute or
> two. might be related to rekeying.
>
> CPU power cannot be the problem since I run it on laptop (2x2.20GHz)
It can be CPU power on AP, ath10k and ath9k also use software
encryption for MFP.
> hwcrypt enabled results are low, some lag but connection remained stable:
There should be no difference between enabling MFP with nohwcrypt and
without nohwcrypt, we will just return -EOPNOTSUPP at different point
from rt2x00mac_set_key:
if (!rt2x00_has_cap_hw_crypto(rt2x00dev))
return -EOPNOTSUPP;
<snip>
crypto.bssidx = rt2x00lib_get_bssidx(rt2x00dev, vif);
crypto.cipher = rt2x00crypto_key_to_cipher(key);
if (crypto.cipher == CIPHER_NONE)
return -EOPNOTSUPP;
However there are some few others points in the code where we check
rt2x00_has_cap_hw_crypto() as well, but all should work the same when
we report to mac80211 that the cipher is not supported.
Stanislaw
On 13/03/2019, Stanislaw Gruszka <[email protected]> wrote:
>
> There should be no difference between enabling MFP with nohwcrypt and
> without nohwcrypt,
well there is. do you still want me to resend this with MFP enabled
unconditionally for all chips?
On Thu, Mar 14, 2019 at 03:02:14PM +0100, Tom Psyborg wrote:
> On 13/03/2019, Stanislaw Gruszka <[email protected]> wrote:
>
> >
> > There should be no difference between enabling MFP with nohwcrypt and
> > without nohwcrypt,
>
> well there is.
Perhaps then you could provide explanation why there is difference ?
> do you still want me to resend this with MFP enabled
> unconditionally for all chips?
Yes, but first lets clarify things.
Stanislaw
On Thu, Mar 14, 2019 at 03:02:14PM +0100, Tom Psyborg wrote:
> On 13/03/2019, Stanislaw Gruszka <[email protected]> wrote:
>
> >
> > There should be no difference between enabling MFP with nohwcrypt and
> > without nohwcrypt,
>
> well there is. do you still want me to resend this with MFP enabled
> unconditionally for all chips?
Please share your hostapd config file with MFP enabled.
Stanislaw
On 25/03/2019, Stanislaw Gruszka <[email protected]> wrote:
> On Thu, Mar 14, 2019 at 03:02:14PM +0100, Tom Psyborg wrote:
>> On 13/03/2019, Stanislaw Gruszka <[email protected]> wrote:
>>
>> >
>> > There should be no difference between enabling MFP with nohwcrypt and
>> > without nohwcrypt,
>>
>> well there is. do you still want me to resend this with MFP enabled
>> unconditionally for all chips?
>
> Please share your hostapd config file with MFP enabled.
>
> Stanislaw
>
>
ctrl_interface=/var/run/wpa_supplicant
eapol_version=1
ap_scan=1
fast_reauth=1
pmf=2
network={
ssid="OpenWrt"
proto=WPA2
key_mgmt=WPA-PSK
pairwise=CCMP
group=CCMP
ieee80211w=2
psk="u7e5hwh46uz7ergv"
wpa_ptk_rekey=60
}
On Tue, Mar 26, 2019 at 02:54:25AM +0100, Tom Psyborg wrote:
> On 25/03/2019, Stanislaw Gruszka <[email protected]> wrote:
> > On Thu, Mar 14, 2019 at 03:02:14PM +0100, Tom Psyborg wrote:
> >> On 13/03/2019, Stanislaw Gruszka <[email protected]> wrote:
> >>
> >> >
> >> > There should be no difference between enabling MFP with nohwcrypt and
> >> > without nohwcrypt,
> >>
> >> well there is. do you still want me to resend this with MFP enabled
> >> unconditionally for all chips?
> >
> > Please share your hostapd config file with MFP enabled.
> >
> > Stanislaw
> >
> >
>
> ctrl_interface=/var/run/wpa_supplicant
> eapol_version=1
> ap_scan=1
> fast_reauth=1
> pmf=2
> network={
> ssid="OpenWrt"
> proto=WPA2
> key_mgmt=WPA-PSK
> pairwise=CCMP
> group=CCMP
> ieee80211w=2
> psk="u7e5hwh46uz7ergv"
> wpa_ptk_rekey=60
> }
This is supplicant config, I asked for hostapd. You can find it in
/tmp/run/hostapd-phy0.conf (I assume you use openwrt on QCA router,
or you use proprietary firmware ?).
Stanislaw
On 26/03/2019, Stanislaw Gruszka <[email protected]> wrote:
> On Tue, Mar 26, 2019 at 02:54:25AM +0100, Tom Psyborg wrote:
>> On 25/03/2019, Stanislaw Gruszka <[email protected]> wrote:
>> > On Thu, Mar 14, 2019 at 03:02:14PM +0100, Tom Psyborg wrote:
>> >> On 13/03/2019, Stanislaw Gruszka <[email protected]> wrote:
>> >>
>> >> >
>> >> > There should be no difference between enabling MFP with nohwcrypt
>> >> > and
>> >> > without nohwcrypt,
>> >>
>> >> well there is. do you still want me to resend this with MFP enabled
>> >> unconditionally for all chips?
>> >
>> > Please share your hostapd config file with MFP enabled.
>> >
>> > Stanislaw
>> >
>> >
>>
>> ctrl_interface=/var/run/wpa_supplicant
>> eapol_version=1
>> ap_scan=1
>> fast_reauth=1
>> pmf=2
>> network={
>> ssid="OpenWrt"
>> proto=WPA2
>> key_mgmt=WPA-PSK
>> pairwise=CCMP
>> group=CCMP
>> ieee80211w=2
>> psk="u7e5hwh46uz7ergv"
>> wpa_ptk_rekey=60
>> }
>
> This is supplicant config, I asked for hostapd. You can find it in
> /tmp/run/hostapd-phy0.conf (I assume you use openwrt on QCA router,
> or you use proprietary firmware ?).
>
> Stanislaw
>
in case it really matters here it is. basically default settings:
driver=nl80211
logger_syslog=127
logger_syslog_level=2
logger_stdout=127
logger_stdout_level=2
country_code=US
ieee80211d=1
hw_mode=g
supported_rates=60 90 120 180 240 360 480 540
basic_rates=60 120 240
beacon_int=100
channel=5
noscan=1
ieee80211n=1
ht_coex=0
ht_capab=[HT40+][LDPC][SHORT-GI-20][SHORT-GI-40][TX-STBC][RX-STBC1][DSSS_CCK-40]
interface=wlan0
ctrl_interface=/var/run/hostapd
ap_isolate=1
bss_load_update_period=60
chan_util_avg_period=600
disassoc_low_ack=1
preamble=1
wmm_enabled=1
ignore_broadcast_ssid=0
uapsd_advertisement_enabled=1
wpa_passphrase=u7e5hwh46uz7ergv
auth_algs=1
wpa=2
wpa_pairwise=CCMP
ssid=OpenWrt
bridge=br-lan
wpa_disable_eapol_key_retries=1
wpa_key_mgmt=WPA-PSK WPA-PSK-SHA256
okc=0
disable_pmksa_caching=1
ieee80211w=2
group_mgmt_cipher=AES-128-CMAC
bssid=10:fe:ed:a7:11:5f
On 2019-03-13 15:41, Tom Psyborg wrote:
> On 13/03/2019, Stanislaw Gruszka <[email protected]> wrote:
>> On Wed, Mar 13, 2019 at 02:48:01PM +0100, Tom Psyborg wrote:
>>> On 13/03/2019, Stanislaw Gruszka <[email protected]> wrote:
>>> > On Wed, Mar 13, 2019 at 02:02:32PM +0100, Tom Psyborg wrote:
>>> >> On 13/03/2019, Stanislaw Gruszka <[email protected]> wrote:
>>> >> > On Tue, Mar 12, 2019 at 08:11:42PM +0100, Tomislav Požega wrote:
>>> >> >> MFP can work with enabled HW crypt engine, but in this case
>>> >> >> available bandwidth is reduced at least when connecting to
>>> >> >> Archer C7 (QCA9558). Enable the feature for known to work chipsets-
>>> >> >> MT7620, RT3070 and RT5390. Userspace setting for ieee80211w should
>>> >> >> default to 0 in order to prevent unintentional bandwidth drop.
>>> >> >>
>>> >> >> Signed-off-by: Tomislav Po?ega <[email protected]>
>>> >> >> ---
>>> >> >> drivers/net/wireless/ralink/rt2x00/rt2800lib.c | 11 +++++++----
>>> >> >> 1 files changed, 7 insertions(+), 4 deletions(-)
>>> >> >>
>>> >> >> diff --git a/drivers/net/wireless/ralink/rt2x00/rt2800lib.c
>>> >> >> b/drivers/net/wireless/ralink/rt2x00/rt2800lib.c
>>> >> >> index a03b528..bb8204d 100644
>>> >> >> --- a/drivers/net/wireless/ralink/rt2x00/rt2800lib.c
>>> >> >> +++ b/drivers/net/wireless/ralink/rt2x00/rt2800lib.c
>>> >> >> @@ -9326,6 +9326,13 @@ static int rt2800_probe_hw_mode(struct
>>> >> >> rt2x00_dev
>>> >> >> *rt2x00dev)
>>> >> >> ieee80211_hw_set(rt2x00dev->hw, SIGNAL_DBM);
>>> >> >> ieee80211_hw_set(rt2x00dev->hw, SUPPORTS_PS);
>>> >> >>
>>> >> >> + /* Experimental: Set MFP with HW crypto enabled. */
>>> >> >> + if (rt2x00_rt(rt2x00dev, RT3070) || rt2x00_rt(rt2x00dev, RT5390)
>>> >> >> ||
>>> >> >> + rt2x00_rt(rt2x00dev, RT6352))
>>> >> >> + ieee80211_hw_set(rt2x00dev->hw, MFP_CAPABLE);
>>> >> >
>>> >> > Is not that we support MFP in hardware. We just return -EOPNOTSUPP
>>> >> > in rt2x00mac_set_key() when mac80211 will try to set MFP ciphers
>>> >> > (since rt2x00crypto_key_to_cipher() will return CIPHER_NONE) and
>>> >> > we fallback to software encryption.
>>> >> >
>>> >> > Please repost patch that enable MFP unconditionally with
>>> >> > 'Cc: [email protected]' tag.
>>> >> >
>>> >> > Stanislaw
>>> >> >
>>> >>
>>> >> No, I have not test any other chipsets besides the ones I enabled it
>>> >> for. It is possible this would cause problems on other devices, so
>>> >> just enable it for the known to work ones.
>>> >
>>> > It's just matter of sending already encrypted frames. All chipsets
>>> > handle that.
>>> >
>>> > Stanislaw
>>> >
>>>
>>> The question is how well all chipsets handle that. I've seen some lags
>>> too with MFP enabled connection. While being about 40-50% lower,
>>> throughput would still occasionally drop to very low values, like
>>> 800Kbps.
>>
>> The only reason I can image that might have impact on throughput
>> in this case is limited CPU power since encryption is done in
>> software. Would be good to compare with PA2 with nohwcrypte, if
>> there are similar lags. However MFP can require more CPU power.
>>
>> Stanislaw
>>
>
> nohwcrypt=y mfp=require: there was no throughput drop, no lag,
> measured about 80-85Mbps but the connection frozen after a minute or
> two. might be related to rekeying.
>
> CPU power cannot be the problem since I run it on laptop (2x2.20GHz)
The lag is probably caused by failed A-MPDU setup exchanges due to
broken management frames.
I think it's likely that rt28xx chipsets are behaving like mt7612e in
that area (since the MAC design is very similar).
I've spent quite a bit of time making MFP work properly in mt76 on that
chipset, and here are my findings:
Hardware crypto for management frames is broken.
When using management frame protection, the same pairwise encryption key
needs to be used for both data frames and management frames.
There is a flag in mac80211 that allows software-encryption for
management frames only.
That leads us to the next issue: CCMP PN is usually generated in
hardware and stored in on-chip memory, which means the mac80211 key
tx_pn counter will be out of sync and software-encrypted management
packets will trigger replay protection on the other side.
To fix this, you need to enable software generated IV if management
frames are to be sent with the same key.
In that case you need to set TXINFO_W0_WIV and fill TXWI_W2_IV+TXWI_W3_EIV.
Also, for software encrypted frames you need to mask out WCID, since
otherwise the hardware will try to encrypt the frame again.
You can use mt76 as reference for how to do all of this
- Felix
On Tue, Mar 26, 2019 at 11:41:37AM +0100, Felix Fietkau wrote:
> On 2019-03-13 15:41, Tom Psyborg wrote:
> > On 13/03/2019, Stanislaw Gruszka <[email protected]> wrote:
> >> On Wed, Mar 13, 2019 at 02:48:01PM +0100, Tom Psyborg wrote:
> >>> On 13/03/2019, Stanislaw Gruszka <[email protected]> wrote:
> >>> > On Wed, Mar 13, 2019 at 02:02:32PM +0100, Tom Psyborg wrote:
> >>> >> On 13/03/2019, Stanislaw Gruszka <[email protected]> wrote:
> >>> >> > On Tue, Mar 12, 2019 at 08:11:42PM +0100, Tomislav Požega wrote:
> >>> >> >> MFP can work with enabled HW crypt engine, but in this case
> >>> >> >> available bandwidth is reduced at least when connecting to
> >>> >> >> Archer C7 (QCA9558). Enable the feature for known to work chipsets-
> >>> >> >> MT7620, RT3070 and RT5390. Userspace setting for ieee80211w should
> >>> >> >> default to 0 in order to prevent unintentional bandwidth drop.
> >>> >> >>
> >>> >> >> Signed-off-by: Tomislav Po?ega <[email protected]>
> >>> >> >> ---
> >>> >> >> drivers/net/wireless/ralink/rt2x00/rt2800lib.c | 11 +++++++----
> >>> >> >> 1 files changed, 7 insertions(+), 4 deletions(-)
> >>> >> >>
> >>> >> >> diff --git a/drivers/net/wireless/ralink/rt2x00/rt2800lib.c
> >>> >> >> b/drivers/net/wireless/ralink/rt2x00/rt2800lib.c
> >>> >> >> index a03b528..bb8204d 100644
> >>> >> >> --- a/drivers/net/wireless/ralink/rt2x00/rt2800lib.c
> >>> >> >> +++ b/drivers/net/wireless/ralink/rt2x00/rt2800lib.c
> >>> >> >> @@ -9326,6 +9326,13 @@ static int rt2800_probe_hw_mode(struct
> >>> >> >> rt2x00_dev
> >>> >> >> *rt2x00dev)
> >>> >> >> ieee80211_hw_set(rt2x00dev->hw, SIGNAL_DBM);
> >>> >> >> ieee80211_hw_set(rt2x00dev->hw, SUPPORTS_PS);
> >>> >> >>
> >>> >> >> + /* Experimental: Set MFP with HW crypto enabled. */
> >>> >> >> + if (rt2x00_rt(rt2x00dev, RT3070) || rt2x00_rt(rt2x00dev, RT5390)
> >>> >> >> ||
> >>> >> >> + rt2x00_rt(rt2x00dev, RT6352))
> >>> >> >> + ieee80211_hw_set(rt2x00dev->hw, MFP_CAPABLE);
> >>> >> >
> >>> >> > Is not that we support MFP in hardware. We just return -EOPNOTSUPP
> >>> >> > in rt2x00mac_set_key() when mac80211 will try to set MFP ciphers
> >>> >> > (since rt2x00crypto_key_to_cipher() will return CIPHER_NONE) and
> >>> >> > we fallback to software encryption.
> >>> >> >
> >>> >> > Please repost patch that enable MFP unconditionally with
> >>> >> > 'Cc: [email protected]' tag.
> >>> >> >
> >>> >> > Stanislaw
> >>> >> >
> >>> >>
> >>> >> No, I have not test any other chipsets besides the ones I enabled it
> >>> >> for. It is possible this would cause problems on other devices, so
> >>> >> just enable it for the known to work ones.
> >>> >
> >>> > It's just matter of sending already encrypted frames. All chipsets
> >>> > handle that.
> >>> >
> >>> > Stanislaw
> >>> >
> >>>
> >>> The question is how well all chipsets handle that. I've seen some lags
> >>> too with MFP enabled connection. While being about 40-50% lower,
> >>> throughput would still occasionally drop to very low values, like
> >>> 800Kbps.
> >>
> >> The only reason I can image that might have impact on throughput
> >> in this case is limited CPU power since encryption is done in
> >> software. Would be good to compare with PA2 with nohwcrypte, if
> >> there are similar lags. However MFP can require more CPU power.
> >>
> >> Stanislaw
> >>
> >
> > nohwcrypt=y mfp=require: there was no throughput drop, no lag,
> > measured about 80-85Mbps but the connection frozen after a minute or
> > two. might be related to rekeying.
> >
> > CPU power cannot be the problem since I run it on laptop (2x2.20GHz)
> The lag is probably caused by failed A-MPDU setup exchanges due to
> broken management frames.
>
> I think it's likely that rt28xx chipsets are behaving like mt7612e in
> that area (since the MAC design is very similar).
> I've spent quite a bit of time making MFP work properly in mt76 on that
> chipset, and here are my findings:
> Hardware crypto for management frames is broken.
> When using management frame protection, the same pairwise encryption key
> needs to be used for both data frames and management frames.
> There is a flag in mac80211 that allows software-encryption for
> management frames only.
> That leads us to the next issue: CCMP PN is usually generated in
> hardware and stored in on-chip memory, which means the mac80211 key
> tx_pn counter will be out of sync and software-encrypted management
> packets will trigger replay protection on the other side.
> To fix this, you need to enable software generated IV if management
> frames are to be sent with the same key.
> In that case you need to set TXINFO_W0_WIV and fill TXWI_W2_IV+TXWI_W3_EIV.
> Also, for software encrypted frames you need to mask out WCID, since
> otherwise the hardware will try to encrypt the frame again.
> You can use mt76 as reference for how to do all of this
I see, I got it completely wrong. I thought with MFP we will use non
supported rt2x00 cipher and we will fallback to software encryption
anyway.
So, until properly implemented we should stay with nohwcrypt for MFP.
Stanislaw