diff options
| author | Bernd Edlinger <bernd.edlinger@hotmail.de> | 2019-01-15 14:01:29 +0000 |
|---|---|---|
| committer | Kalle Valo <kvalo@codeaurora.org> | 2019-02-01 14:16:05 +0200 |
| commit | a4296994eb8061ee3455721a296c387c639bf635 (patch) | |
| tree | 22a98a125df6dc7f59a1003618c5bd09e656af73 /drivers/net/phy/fixed_phy.c | |
| parent | 3844dec0f45df0737eec86444e280057fd042507 (diff) | |
| download | linux-a4296994eb8061ee3455721a296c387c639bf635.tar.bz2 | |
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>
Diffstat (limited to 'drivers/net/phy/fixed_phy.c')
0 files changed, 0 insertions, 0 deletions