[PATCH 1/2] rt2x00: code-style fix in rt2800usb.c

[PATCH 1/2] rt2x00: code-style fix in rt2800usb.c

[Tomislav Požega]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=UTF-8, Size: 1085 bytes --]

Signed-off-by: Tomislav Po¸ega <pozega.tomislav@gmail.com>
---
 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

[PATCH 2/2] rt2x00: enable experimental MFP with HW crypt

[Tomislav Požega]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=UTF-8, Size: 1885 bytes --]

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 <pozega.tomislav@gmail.com>
---
 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

Re: [PATCH 2/2] rt2x00: enable experimental MFP with HW crypt

[Stanislaw Gruszka]

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 <pozega.tomislav@gmail.com>
> ---
>  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: stable@vger.kernel.org' tag.

Stanislaw

Re: [PATCH 2/2] rt2x00: enable experimental MFP with HW crypt

[Tom Psyborg]

On 13/03/2019, Stanislaw Gruszka <sgruszka@redhat.com> 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 <pozega.tomislav@gmail.com>
>> ---
>>  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: stable@vger.kernel.org' 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.

Re: [PATCH 2/2] rt2x00: enable experimental MFP with HW crypt

[Stanislaw Gruszka]

On Wed, Mar 13, 2019 at 02:02:32PM +0100, Tom Psyborg wrote:
> On 13/03/2019, Stanislaw Gruszka <sgruszka@redhat.com> 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 <pozega.tomislav@gmail.com>
> >> ---
> >>  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: stable@vger.kernel.org' 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

Re: [PATCH 2/2] rt2x00: enable experimental MFP with HW crypt

[Tom Psyborg]

On 13/03/2019, Stanislaw Gruszka <sgruszka@redhat.com> wrote:
> On Wed, Mar 13, 2019 at 02:02:32PM +0100, Tom Psyborg wrote:
>> On 13/03/2019, Stanislaw Gruszka <sgruszka@redhat.com> 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 <pozega.tomislav@gmail.com>
>> >> ---
>> >>  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: stable@vger.kernel.org' 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.

Re: [PATCH 2/2] rt2x00: enable experimental MFP with HW crypt

[Stanislaw Gruszka]

On Wed, Mar 13, 2019 at 02:48:01PM +0100, Tom Psyborg wrote:
> On 13/03/2019, Stanislaw Gruszka <sgruszka@redhat.com> wrote:
> > On Wed, Mar 13, 2019 at 02:02:32PM +0100, Tom Psyborg wrote:
> >> On 13/03/2019, Stanislaw Gruszka <sgruszka@redhat.com> 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 <pozega.tomislav@gmail.com>
> >> >> ---
> >> >>  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: stable@vger.kernel.org' 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

Re: [PATCH 2/2] rt2x00: enable experimental MFP with HW crypt

[Tom Psyborg]

On 13/03/2019, Stanislaw Gruszka <sgruszka@redhat.com> wrote:
> On Wed, Mar 13, 2019 at 02:48:01PM +0100, Tom Psyborg wrote:
>> On 13/03/2019, Stanislaw Gruszka <sgruszka@redhat.com> wrote:
>> > On Wed, Mar 13, 2019 at 02:02:32PM +0100, Tom Psyborg wrote:
>> >> On 13/03/2019, Stanislaw Gruszka <sgruszka@redhat.com> 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 <pozega.tomislav@gmail.com>
>> >> >> ---
>> >> >>  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: stable@vger.kernel.org' 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

Re: [PATCH 2/2] rt2x00: enable experimental MFP with HW crypt

[Stanislaw Gruszka]

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

Re: [PATCH 2/2] rt2x00: enable experimental MFP with HW crypt

[Tom Psyborg]

On 13/03/2019, Stanislaw Gruszka <sgruszka@redhat.com> 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?

Re: [PATCH 2/2] rt2x00: enable experimental MFP with HW crypt

[Stanislaw Gruszka]

On Thu, Mar 14, 2019 at 03:02:14PM +0100, Tom Psyborg wrote:
> On 13/03/2019, Stanislaw Gruszka <sgruszka@redhat.com> 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

Re: [PATCH 2/2] rt2x00: enable experimental MFP with HW crypt

[Stanislaw Gruszka]

On Thu, Mar 14, 2019 at 03:02:14PM +0100, Tom Psyborg wrote:
> On 13/03/2019, Stanislaw Gruszka <sgruszka@redhat.com> 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

Re: [PATCH 2/2] rt2x00: enable experimental MFP with HW crypt

[Tom Psyborg]

On 25/03/2019, Stanislaw Gruszka <sgruszka@redhat.com> wrote:
> On Thu, Mar 14, 2019 at 03:02:14PM +0100, Tom Psyborg wrote:
>> On 13/03/2019, Stanislaw Gruszka <sgruszka@redhat.com> 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
}

Re: [PATCH 2/2] rt2x00: enable experimental MFP with HW crypt

[Stanislaw Gruszka]

On Tue, Mar 26, 2019 at 02:54:25AM +0100, Tom Psyborg wrote:
> On 25/03/2019, Stanislaw Gruszka <sgruszka@redhat.com> wrote:
> > On Thu, Mar 14, 2019 at 03:02:14PM +0100, Tom Psyborg wrote:
> >> On 13/03/2019, Stanislaw Gruszka <sgruszka@redhat.com> 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

Re: [PATCH 2/2] rt2x00: enable experimental MFP with HW crypt

[Tom Psyborg]

On 26/03/2019, Stanislaw Gruszka <sgruszka@redhat.com> wrote:
> On Tue, Mar 26, 2019 at 02:54:25AM +0100, Tom Psyborg wrote:
>> On 25/03/2019, Stanislaw Gruszka <sgruszka@redhat.com> wrote:
>> > On Thu, Mar 14, 2019 at 03:02:14PM +0100, Tom Psyborg wrote:
>> >> On 13/03/2019, Stanislaw Gruszka <sgruszka@redhat.com> 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

Re: [PATCH 2/2] rt2x00: enable experimental MFP with HW crypt

[Felix Fietkau]

On 2019-03-13 15:41, Tom Psyborg wrote:
> On 13/03/2019, Stanislaw Gruszka <sgruszka@redhat.com> wrote:
>> On Wed, Mar 13, 2019 at 02:48:01PM +0100, Tom Psyborg wrote:
>>> On 13/03/2019, Stanislaw Gruszka <sgruszka@redhat.com> wrote:
>>> > On Wed, Mar 13, 2019 at 02:02:32PM +0100, Tom Psyborg wrote:
>>> >> On 13/03/2019, Stanislaw Gruszka <sgruszka@redhat.com> 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 <pozega.tomislav@gmail.com>
>>> >> >> ---
>>> >> >>  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: stable@vger.kernel.org' 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

Re: [PATCH 2/2] rt2x00: enable experimental MFP with HW crypt

[Stanislaw Gruszka]

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 <sgruszka@redhat.com> wrote:
> >> On Wed, Mar 13, 2019 at 02:48:01PM +0100, Tom Psyborg wrote:
> >>> On 13/03/2019, Stanislaw Gruszka <sgruszka@redhat.com> wrote:
> >>> > On Wed, Mar 13, 2019 at 02:02:32PM +0100, Tom Psyborg wrote:
> >>> >> On 13/03/2019, Stanislaw Gruszka <sgruszka@redhat.com> 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 <pozega.tomislav@gmail.com>
> >>> >> >> ---
> >>> >> >>  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: stable@vger.kernel.org' 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