From: Kalle Valo <kvalo@codeaurora.org>
To: Bernd Edlinger <bernd.edlinger@hotmail.de>
Cc: Stanislaw Gruszka <sgruszka@redhat.com>,
Helmut Schaa <helmut.schaa@googlemail.com>,
"David S. Miller" <davem@davemloft.net>,
"linux-wireless@vger.kernel.org" <linux-wireless@vger.kernel.org>,
"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] rt2x00: Work around a firmware bug with shared keys
Date: Fri, 1 Feb 2019 12:16:36 +0000 (UTC) [thread overview]
Message-ID: <20190201121636.D7DB26030D@smtp.codeaurora.org> (raw)
In-Reply-To: <AM0PR07MB3874E8F6ADD41C4E1BCBE43EE4810@AM0PR07MB3874.eurprd07.prod.outlook.com>
Bernd Edlinger <bernd.edlinger@hotmail.de> wrote:
> Apparently the rt2x61 firmware fails temporarily to decode
> broadcast packets if the shared keys are not assigned
> in the "correct" sequence. At the same time unicast
> packets work fine, since they are encrypted with the
> pairwise key.
>
> At least with WPA2 CCMP mode the shared keys are
> set in the following sequence: keyidx=1, 2, 1, 2.
> After a while only keyidx 2 gets decrypted, and
> keyidx 1 is ignored, probably because there is never
> a keyidx 3.
>
> Symptoms are arping -b works for 10 minutes, since
> keyidx=2 is used for broadcast, and then it stops
> working for 10 minutes, because keyidx=1 is used.
> That failure mode repeats forever.
>
> Note, the firmware does not even know which keyidx
> corresponds to which hw_key_idx so the firmware is
> trying to be smarter than the driver, which is bound
> to fail.
>
> As workaround the function rt61pci_config_shared_key
> requests software decryption of the shared keys,
> by returning EOPNOTSUPP. However, pairwise keys are
> still handled by hardware which works just fine.
>
> Signed-off-by: Bernd Edlinger <bernd.edlinger@hotmail.de>
> Acked-by: Stanislaw Gruszka <sgruszka@redhat.com>
Patch applied to wireless-drivers-next.git, thanks.
a4296994eb80 rt2x00: Work around a firmware bug with shared keys
--
https://patchwork.kernel.org/patch/10764543/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
prev parent reply other threads:[~2019-02-01 12:16 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-01-15 14:01 [PATCH] rt61pci: Work around a firmware bug with shared keys Bernd Edlinger
2019-01-16 11:21 ` Stanislaw Gruszka
2019-01-16 16:29 ` Kalle Valo
2019-02-01 12:16 ` Kalle Valo [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20190201121636.D7DB26030D@smtp.codeaurora.org \
--to=kvalo@codeaurora.org \
--cc=bernd.edlinger@hotmail.de \
--cc=davem@davemloft.net \
--cc=helmut.schaa@googlemail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-wireless@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=sgruszka@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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.