Question on software-crypt mode.
Hello!
I am trying to implement software-crypt for ath10k so that it can do crypt with multiple stations connected to same AP.
I tried using ath9k's approach and just not setting keys, but that does not work at all (no stations can communicate).
If I basically leave code as is, then secondary stations can associate but never get DHCP. I see FCS and hw-crypt errored packets being received from the ath10k firmware/chip. This is probably because the chip/firmware decodes the secondary station's packets with the first station's keys. Transmitted packets (as sniffed from the AP) do appear fine.
I was thinking to just take all fcs and/or crypt-errored packets in the receive path and somehow send them up the stack for the software-crypt layer to (re)decrypt. I think I have managed to get ath10k to send them up, but still DHCP does not complete.
Does anyone have any suggestions for things to try or code to look at in detail?
Thanks,
Ben
Signature · 8 lines
Ben Greear <[email protected]> Candela Technologies Inc http://www.candelatech.com _______________________________________________ ath10k mailing list [email protected] http://lists.infradead.org/mailman/listinfo/ath10k
Quoted 9 lines · Ben Greear
Hello!
I am trying to implement software-crypt for ath10k so that it can do crypt with multiple stations connected to same AP.
I tried using ath9k's approach and just not setting keys, but that does not work at all
(no stations can communicate).
Quoted 7 lines
If I basically leave code as is, then secondary stations can associate but never
get DHCP. I see FCS and hw-crypt errored packets being received from the ath10kfirmware/chip. This is probably because the chip/firmware decodes the
secondary station's packets with the first station's keys. Transmitted packets (as sniffed from the AP) do appear fine.
This sounds a lot like a multi-BSS issues that were discovered recently on AP branch firmware.
See commit:
ath10k: fix multi BSSID with WPA on FW 10.1
You could try applying the commit and remove the following code from it:
if (arvif->vdev_type != WMI_VDEV_TYPE_AP)
return;
The commit was originally only tested against AP interfaces but I was suspecting the same thing (i.e. corrupted Tx) could be happening on multi-STA.
Michał
Quoted 18 lines · Michal Kazior
Quoted 9 lines · Ben Greear
Hello!
I am trying to implement software-crypt for ath10k so that it can do crypt with multiple stations connected to same AP.
I tried using ath9k's approach and just not setting keys, but that does not work at all
(no stations can communicate).Quoted 7 lines
If I basically leave code as is, then secondary stations can associate but never
get DHCP. I see FCS and hw-crypt errored packets being received from the ath10kfirmware/chip. This is probably because the chip/firmware decodes the
secondary station's packets with the first station's keys. Transmitted packets (as sniffed from the AP) do appear fine.
Quoted 2 lines
This sounds a lot like a multi-BSS issues that were discovered recently on AP branch firmware.
I think that it may be mostly impossible to
get hardware to do crypt with multiple STA associated to same AP because hardware/firmware wants to hash on peer's MAC, and in this case, I have multiple peers with same MAC. I wanted to just ignore the RX crypt errors and have the software RX path handle it up in mac80211, but I did not make much progress when trying that.
I made some progress with software-only crypt, but I had to modify firmware because it will not transmit the 4/4 handshake message until key has been configured, and with sw-crypt, the key will never be set.
With this change to the firmware, I can authenticate/connect to the AP, but DHCP will not work, and the AP shows no received data packets. I suspect the firmware is expecting the tx packets to be un-encrypted and is either trying to crypt them again or is getting confused when it cannot find packet headers where it expects them.
When I find time I will dig back into the firmware to work on this some more.
Quoted 4 lines
See commit:
ath10k: fix multi BSSID with WPA on FW 10.1
Quoted 8 lines
You could try applying the commit and remove the following code from it:
if (arvif->vdev_type != WMI_VDEV_TYPE_AP) return;The commit was originally only tested against AP interfaces but I was suspecting the same thing (i.e. corrupted Tx) could be happening on multi-STA.
I will look at that as well.
Thanks,
Ben
Signature · 8 lines
Ben Greear <[email protected]> Candela Technologies Inc http://www.candelatech.com _______________________________________________ ath10k mailing list [email protected] http://lists.infradead.org/mailman/listinfo/ath10k