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@xxxxxxxxxxxxxxx> 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@xxxxxxxxx> > 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@xxxxxxxxxxxxxxx> > Candela Technologies Inc http://www.candelatech.com > > > _______________________________________________ > ath10k mailing list > ath10k@xxxxxxxxxxxxxxxxxxx > http://lists.infradead.org/mailman/listinfo/ath10k
