Should ath10k enable RX_FLAG_ALLOW_SAME_PN

Should ath10k enable RX_FLAG_ALLOW_SAME_PN

[Ben Greear]

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@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@candelatech.com>
Candela Technologies Inc  http://www.candelatech.com

Should ath10k enable RX_FLAG_ALLOW_SAME_PN

[Ben Greear]

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@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@candelatech.com>
Candela Technologies Inc  http://www.candelatech.com


_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k

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

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

_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k