MIME-Version: 1.0
In-Reply-To: <20190313130910.GD2003@redhat.com>
References: <1552417902-11040-1-git-send-email-pozega.tomislav@gmail.com>
 <1552417902-11040-2-git-send-email-pozega.tomislav@gmail.com>
 <20190313091252.GB2663@redhat.com> <CAKR_QV+sFc6J97f5dtW9OtxGoEj5udB=fY5qAb3_QgF4jfqEVA@mail.gmail.com>
 <20190313130910.GD2003@redhat.com>
From:   Tom Psyborg <pozega.tomislav@gmail.com>
Date:   Wed, 13 Mar 2019 14:48:01 +0100
Message-ID: <CAKR_QVLB9k0bGiRW9ON3PeQR1ZoMfWbrXg3W+Bg4N4G+9pAsZg@mail.gmail.com>
Subject: Re: [PATCH 2/2] rt2x00: enable experimental MFP with HW crypt
To:     Stanislaw Gruszka <sgruszka@redhat.com>
Cc:     linux-wireless@vger.kernel.org, kvalo@codeaurora.org,
        daniel@makrotopia.org
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Sender: linux-wireless-owner@vger.kernel.org
Precedence: bulk

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=C5=BEega 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.