From: Kalle Valo <kvalo@codeaurora.org>
To: Stanislaw Gruszka <sgruszka@redhat.com>
Cc: Bernd Edlinger <bernd.edlinger@hotmail.de>,
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] rt61pci: Work around a firmware bug with shared keys
Date: Wed, 16 Jan 2019 18:29:07 +0200 [thread overview]
Message-ID: <87imyo4ld8.fsf@codeaurora.org> (raw)
In-Reply-To: <20190116112129.GC5234@redhat.com> (Stanislaw Gruszka's message of "Wed, 16 Jan 2019 12:21:30 +0100")
Stanislaw Gruszka <sgruszka@redhat.com> writes:
> On Tue, Jan 15, 2019 at 02:01:29PM +0000, Bernd Edlinger 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>
The prefix should be "rt2x00:", I can change that.
--
Kalle Valo
next prev parent reply other threads:[~2019-01-16 16:29 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 [this message]
2019-02-01 12:16 ` [PATCH] rt2x00: " Kalle Valo
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=87imyo4ld8.fsf@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.