rt2x00: Work around a firmware bug with shared keys
authorBernd Edlinger <bernd.edlinger@hotmail.de>
Tue, 15 Jan 2019 14:01:29 +0000 (14:01 +0000)
committerKalle Valo <kvalo@codeaurora.org>
Fri, 1 Feb 2019 12:16:05 +0000 (14:16 +0200)
commita4296994eb8061ee3455721a296c387c639bf635
tree22a98a125df6dc7f59a1003618c5bd09e656af73
parent3844dec0f45df0737eec86444e280057fd042507
rt2x00: Work around a firmware bug with shared keys

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>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
drivers/net/wireless/ralink/rt2x00/rt61pci.c