Should ath10k enable RX_FLAG_ALLOW_SAME_PN

Adrian Chadd adrian at
Wed Mar 15 09:27:42 PDT 2017

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.)


On 15 March 2017 at 08:26, Ben Greear <greearb at> 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>
> 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>
> Candela Technologies Inc
> _______________________________________________
> ath10k mailing list
> ath10k at

More information about the ath10k mailing list