* [PATCH 1/2] rt2x00: code-style fix in rt2800usb.c @ 2019-03-12 19:11 Tomislav Požega 2019-03-12 19:11 ` [PATCH 2/2] rt2x00: enable experimental MFP with HW crypt Tomislav Požega 0 siblings, 1 reply; 17+ messages in thread From: Tomislav Požega @ 2019-03-12 19:11 UTC (permalink / raw) To: linux-wireless; +Cc: kvalo, sgruszka, daniel, 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 ^ permalink raw reply related [flat|nested] 17+ messages in thread
* [PATCH 2/2] rt2x00: enable experimental MFP with HW crypt 2019-03-12 19:11 [PATCH 1/2] rt2x00: code-style fix in rt2800usb.c Tomislav Požega @ 2019-03-12 19:11 ` Tomislav Požega 2019-03-13 9:12 ` Stanislaw Gruszka 0 siblings, 1 reply; 17+ messages in thread From: Tomislav Požega @ 2019-03-12 19:11 UTC (permalink / raw) To: linux-wireless; +Cc: kvalo, sgruszka, daniel, 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 ^ permalink raw reply related [flat|nested] 17+ messages in thread
* Re: [PATCH 2/2] rt2x00: enable experimental MFP with HW crypt 2019-03-12 19:11 ` [PATCH 2/2] rt2x00: enable experimental MFP with HW crypt Tomislav Požega @ 2019-03-13 9:12 ` Stanislaw Gruszka 2019-03-13 13:02 ` Tom Psyborg 0 siblings, 1 reply; 17+ messages in thread From: Stanislaw Gruszka @ 2019-03-13 9:12 UTC (permalink / raw) To: Tomislav Požega; +Cc: linux-wireless, kvalo, daniel 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 ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [PATCH 2/2] rt2x00: enable experimental MFP with HW crypt 2019-03-13 9:12 ` Stanislaw Gruszka @ 2019-03-13 13:02 ` Tom Psyborg 2019-03-13 13:09 ` Stanislaw Gruszka 0 siblings, 1 reply; 17+ messages in thread From: Tom Psyborg @ 2019-03-13 13:02 UTC (permalink / raw) To: Stanislaw Gruszka; +Cc: linux-wireless, kvalo, daniel 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. ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [PATCH 2/2] rt2x00: enable experimental MFP with HW crypt 2019-03-13 13:02 ` Tom Psyborg @ 2019-03-13 13:09 ` Stanislaw Gruszka 2019-03-13 13:48 ` Tom Psyborg 0 siblings, 1 reply; 17+ messages in thread From: Stanislaw Gruszka @ 2019-03-13 13:09 UTC (permalink / raw) To: Tom Psyborg; +Cc: linux-wireless, kvalo, daniel 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 ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [PATCH 2/2] rt2x00: enable experimental MFP with HW crypt 2019-03-13 13:09 ` Stanislaw Gruszka @ 2019-03-13 13:48 ` Tom Psyborg 2019-03-13 14:06 ` Stanislaw Gruszka 0 siblings, 1 reply; 17+ messages in thread From: Tom Psyborg @ 2019-03-13 13:48 UTC (permalink / raw) To: Stanislaw Gruszka; +Cc: linux-wireless, kvalo, daniel 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. ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [PATCH 2/2] rt2x00: enable experimental MFP with HW crypt 2019-03-13 13:48 ` Tom Psyborg @ 2019-03-13 14:06 ` Stanislaw Gruszka 2019-03-13 14:41 ` Tom Psyborg 0 siblings, 1 reply; 17+ messages in thread From: Stanislaw Gruszka @ 2019-03-13 14:06 UTC (permalink / raw) To: Tom Psyborg; +Cc: linux-wireless, kvalo, daniel 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 ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [PATCH 2/2] rt2x00: enable experimental MFP with HW crypt 2019-03-13 14:06 ` Stanislaw Gruszka @ 2019-03-13 14:41 ` Tom Psyborg 2019-03-13 15:50 ` Stanislaw Gruszka 2019-03-26 10:41 ` Felix Fietkau 0 siblings, 2 replies; 17+ messages in thread From: Tom Psyborg @ 2019-03-13 14:41 UTC (permalink / raw) To: Stanislaw Gruszka; +Cc: linux-wireless, kvalo, daniel 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 ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [PATCH 2/2] rt2x00: enable experimental MFP with HW crypt 2019-03-13 14:41 ` Tom Psyborg @ 2019-03-13 15:50 ` Stanislaw Gruszka 2019-03-14 14:02 ` Tom Psyborg 2019-03-26 10:41 ` Felix Fietkau 1 sibling, 1 reply; 17+ messages in thread From: Stanislaw Gruszka @ 2019-03-13 15:50 UTC (permalink / raw) To: Tom Psyborg; +Cc: linux-wireless, kvalo, daniel 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 ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [PATCH 2/2] rt2x00: enable experimental MFP with HW crypt 2019-03-13 15:50 ` Stanislaw Gruszka @ 2019-03-14 14:02 ` Tom Psyborg 2019-03-14 14:13 ` Stanislaw Gruszka 2019-03-25 14:25 ` Stanislaw Gruszka 0 siblings, 2 replies; 17+ messages in thread From: Tom Psyborg @ 2019-03-14 14:02 UTC (permalink / raw) To: Stanislaw Gruszka; +Cc: linux-wireless, kvalo, daniel 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? ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [PATCH 2/2] rt2x00: enable experimental MFP with HW crypt 2019-03-14 14:02 ` Tom Psyborg @ 2019-03-14 14:13 ` Stanislaw Gruszka 2019-03-25 14:25 ` Stanislaw Gruszka 1 sibling, 0 replies; 17+ messages in thread From: Stanislaw Gruszka @ 2019-03-14 14:13 UTC (permalink / raw) To: Tom Psyborg; +Cc: linux-wireless, kvalo, daniel 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 ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [PATCH 2/2] rt2x00: enable experimental MFP with HW crypt 2019-03-14 14:02 ` Tom Psyborg 2019-03-14 14:13 ` Stanislaw Gruszka @ 2019-03-25 14:25 ` Stanislaw Gruszka 2019-03-26 1:54 ` Tom Psyborg 1 sibling, 1 reply; 17+ messages in thread From: Stanislaw Gruszka @ 2019-03-25 14:25 UTC (permalink / raw) To: Tom Psyborg; +Cc: linux-wireless, kvalo, daniel 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 ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [PATCH 2/2] rt2x00: enable experimental MFP with HW crypt 2019-03-25 14:25 ` Stanislaw Gruszka @ 2019-03-26 1:54 ` Tom Psyborg 2019-03-26 6:16 ` Stanislaw Gruszka 0 siblings, 1 reply; 17+ messages in thread From: Tom Psyborg @ 2019-03-26 1:54 UTC (permalink / raw) To: Stanislaw Gruszka; +Cc: linux-wireless, kvalo, daniel 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 } ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [PATCH 2/2] rt2x00: enable experimental MFP with HW crypt 2019-03-26 1:54 ` Tom Psyborg @ 2019-03-26 6:16 ` Stanislaw Gruszka 2019-03-26 8:13 ` Tom Psyborg 0 siblings, 1 reply; 17+ messages in thread From: Stanislaw Gruszka @ 2019-03-26 6:16 UTC (permalink / raw) To: Tom Psyborg; +Cc: linux-wireless, kvalo, daniel 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 ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [PATCH 2/2] rt2x00: enable experimental MFP with HW crypt 2019-03-26 6:16 ` Stanislaw Gruszka @ 2019-03-26 8:13 ` Tom Psyborg 0 siblings, 0 replies; 17+ messages in thread From: Tom Psyborg @ 2019-03-26 8:13 UTC (permalink / raw) To: Stanislaw Gruszka; +Cc: linux-wireless, kvalo, daniel 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 ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [PATCH 2/2] rt2x00: enable experimental MFP with HW crypt 2019-03-13 14:41 ` Tom Psyborg 2019-03-13 15:50 ` Stanislaw Gruszka @ 2019-03-26 10:41 ` Felix Fietkau 2019-03-26 11:35 ` Stanislaw Gruszka 1 sibling, 1 reply; 17+ messages in thread From: Felix Fietkau @ 2019-03-26 10:41 UTC (permalink / raw) To: Tom Psyborg, Stanislaw Gruszka; +Cc: linux-wireless, kvalo, daniel 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 ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [PATCH 2/2] rt2x00: enable experimental MFP with HW crypt 2019-03-26 10:41 ` Felix Fietkau @ 2019-03-26 11:35 ` Stanislaw Gruszka 0 siblings, 0 replies; 17+ messages in thread From: Stanislaw Gruszka @ 2019-03-26 11:35 UTC (permalink / raw) To: Felix Fietkau; +Cc: Tom Psyborg, linux-wireless, kvalo, daniel 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 ^ permalink raw reply [flat|nested] 17+ messages in thread
end of thread, other threads:[~2019-03-26 11:35 UTC | newest] Thread overview: 17+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2019-03-12 19:11 [PATCH 1/2] rt2x00: code-style fix in rt2800usb.c Tomislav Požega 2019-03-12 19:11 ` [PATCH 2/2] rt2x00: enable experimental MFP with HW crypt Tomislav Požega 2019-03-13 9:12 ` Stanislaw Gruszka 2019-03-13 13:02 ` Tom Psyborg 2019-03-13 13:09 ` Stanislaw Gruszka 2019-03-13 13:48 ` Tom Psyborg 2019-03-13 14:06 ` Stanislaw Gruszka 2019-03-13 14:41 ` Tom Psyborg 2019-03-13 15:50 ` Stanislaw Gruszka 2019-03-14 14:02 ` Tom Psyborg 2019-03-14 14:13 ` Stanislaw Gruszka 2019-03-25 14:25 ` Stanislaw Gruszka 2019-03-26 1:54 ` Tom Psyborg 2019-03-26 6:16 ` Stanislaw Gruszka 2019-03-26 8:13 ` Tom Psyborg 2019-03-26 10:41 ` Felix Fietkau 2019-03-26 11:35 ` Stanislaw Gruszka
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.