Should ath10k enable RX_FLAG_ALLOW_SAME_PN

[Adrian Chadd]

have you verified with a sniffer that it indeed is an A-MSDU that the
hardware is decap'ing for you?

(ath9k doesn't do hardware A-MSDU decap.)

-adrian


On 15 March 2017 at 08:26, Ben Greear <greearb at candelatech.com> wrote:
> We notice a strange problem when receiving ath10k frames in
> raw mode (with modified firmware).
>
> The very first data message (UDP discovery response) is dropped
> in WPA2 + AES mode, and it appears that if we would set the
> RX_FLAG_ALLOW_SAME_PN it would be accepted.  ath9k in software-crypt
> mode does not have this issue as far as we can tell.
>
> So, maybe ath10k should set this flag??
>
> Here is commit ID from the logic that introduced this flag, in case
> that helps jog some memory.
>
> commit f631a77ba920f7153a1094d09cd8f2ebbffd0328
> Author: Sara Sharon <sara.sharon at intel.com>
> Date:   Tue May 3 15:59:44 2016 +0300
>
>     mac80211: allow same PN for AMSDU sub-frames
>
>     Some hardware (iwlwifi an example) de-aggregate AMSDUs and copy the IV
>     as is to the generated MPDUs, so the same PN appears in multiple
>     packets without being a replay attack.  Allow driver to explicitly
>     indicate that a frame is allowed to have the same PN as the previous
>     frame.
>
> Thanks,
> Ben
>
> --
> Ben Greear <greearb at candelatech.com>
> Candela Technologies Inc  http://www.candelatech.com
>
>
> _______________________________________________
> ath10k mailing list
> ath10k at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/ath10k