Re: [ath9k-devel] [PATCH 7/7] ath10k: strip protected flag
Michal Kazior writes:
> On 30/04/13 09:58, Kalle Valo wrote:
>> Michal Kazior writes:
>>
>>> We already do decryption and all crypto
>>> verification in HW. mac80211 tries to verify CCMP
>>> for fragmented rx and fails without this patch.
>>>
>>> This fixes fragmented rx on CCMP networks.
>>>
>>> Signed-off-by: Michal Kazior
>>
>> [...]
>>
>>> - if (info->encrypt_type != HTT_RX_MPDU_ENCRYPT_NONE)
>>> + if (info->encrypt_type != HTT_RX_MPDU_ENCRYPT_NONE) {
>>> status->flag |= RX_FLAG_DECRYPTED | RX_FLAG_IV_STRIPPED |
>>> RX_FLAG_MMIC_STRIPPED;
>>> + hdr->frame_control = __cpu_to_le16(
>>> + __le16_to_cpu(hdr->frame_control) &
>>> + ~IEEE80211_FCTL_PROTECTED);
>>> + }
>>
>> This looks ugly. Is this a bug in mac80211 which we just workaround in
>> ath10k? Isn't there any other way to fix this? At least this deserves a
>> big comment in the code to explain why we are doing this.
>>
>> I'll apply this anyway, but we need to discuss more about this.
>
> I'm not quite sure whether this is an issue in mac80211 or we should
> be actually stripping the protected flag. b43 driver seems to strip
> the flag as well.
If b43 does the same when I'm happy with this. Just send a new patch
adding a comment to the code as well.
> mac80211 seems to want to do some extra checks for CCMP in fragmented
> rx data path. Perhaps it shouldn't?
IMHO it shouldn't, but I'm no security expert. Maybe you should ask in
the linux-wireless list?
--
Kalle Valo
___
ath9k-devel mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] [PATCH 7/7] ath10k: strip protected flag
On 30/04/13 09:58, Kalle Valo wrote:
> Michal Kazior writes:
>
>> We already do decryption and all crypto
>> verification in HW. mac80211 tries to verify CCMP
>> for fragmented rx and fails without this patch.
>>
>> This fixes fragmented rx on CCMP networks.
>>
>> Signed-off-by: Michal Kazior
>
> [...]
>
>> -if (info->encrypt_type != HTT_RX_MPDU_ENCRYPT_NONE)
>> +if (info->encrypt_type != HTT_RX_MPDU_ENCRYPT_NONE) {
>> status->flag |= RX_FLAG_DECRYPTED | RX_FLAG_IV_STRIPPED |
>> RX_FLAG_MMIC_STRIPPED;
>> +hdr->frame_control = __cpu_to_le16(
>> +__le16_to_cpu(hdr->frame_control) &
>> +~IEEE80211_FCTL_PROTECTED);
>> +}
>
> This looks ugly. Is this a bug in mac80211 which we just workaround in
> ath10k? Isn't there any other way to fix this? At least this deserves a
> big comment in the code to explain why we are doing this.
>
> I'll apply this anyway, but we need to discuss more about this.
I'm not quite sure whether this is an issue in mac80211 or we should be
actually stripping the protected flag. b43 driver seems to strip the
flag as well.
mac80211 seems to want to do some extra checks for CCMP in fragmented rx
data path. Perhaps it shouldn't?
-- Pozdrawiam / Best regards, Michal Kazior.
___
ath9k-devel mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] [PATCH 7/7] ath10k: strip protected flag
Michal Kazior writes:
> We already do decryption and all crypto
> verification in HW. mac80211 tries to verify CCMP
> for fragmented rx and fails without this patch.
>
> This fixes fragmented rx on CCMP networks.
>
> Signed-off-by: Michal Kazior
[...]
> - if (info->encrypt_type != HTT_RX_MPDU_ENCRYPT_NONE)
> + if (info->encrypt_type != HTT_RX_MPDU_ENCRYPT_NONE) {
> status->flag |= RX_FLAG_DECRYPTED | RX_FLAG_IV_STRIPPED |
> RX_FLAG_MMIC_STRIPPED;
> + hdr->frame_control = __cpu_to_le16(
> + __le16_to_cpu(hdr->frame_control) &
> + ~IEEE80211_FCTL_PROTECTED);
> + }
This looks ugly. Is this a bug in mac80211 which we just workaround in
ath10k? Isn't there any other way to fix this? At least this deserves a
big comment in the code to explain why we are doing this.
I'll apply this anyway, but we need to discuss more about this.
--
Kalle Valo
___
ath9k-devel mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel
