> -----Original Message-----
> From: Johannes Berg <johannes@xxxxxxxxxxxxxxxx>
> Sent: Monday, April 11, 2022 5:12 PM
> To: Pkshih <pkshih@xxxxxxxxxxx>
> Cc: linux-wireless@xxxxxxxxxxxxxxx
> Subject: Re: [PATCH] mac80211: consider Order bit to fill CCMP AAD
>
> On Thu, 2022-03-24 at 08:48 +0800, Ping-Ke Shih wrote:
> > Follow IEEE 802.11-21 that HTC subfield masked to 0 for all data frames
> > containing a QoS Control field.
> >
>
> That seems fine, though not sure it's actually _relevant_ - how would we
> possibly generate such frames in mac80211?
I suddenly meet this case, because hardware decryption isn't configured properly
during development, so it falls into software decryption. The received packets
can possibly contain HTC.
After I fix my driver, I don't need this, but I think it is worth to have
this patch.
>
> > It also defines the AAD length depends on
> > QC and A4 fields, so change logic to determine length accordingly.
>
> This I don't understand.
IEEE 802.11-21 illustrate the use cases as below
QC Field A4 Field AAD length
------- -------- ---------
x x 22
o x 24
x o 28
o o 30
I write logic along with this table, because it would be clear and simple.
>
> The code
>
>
> > - hdrlen = ieee80211_hdrlen(hdr->frame_control);
> > - len_a = hdrlen - 2;
>
> sets it to the same thing, no?
Since AAD consists of "FC | A1 | A2 | A3 | SC | [A4] | [QC]"
I think '-2' here means AAD doesn't contain 'Duration' field.
>
> Oh, I see - again you're worried about IEEE80211_HT_CTL_LEN I guess?
>
> Maybe just subtract that again?
Yes, we can subtract length from ieee80211_hdrlen().
But, this function is called in data path that means every packet can use it.
Is it reasonable to += IEEE80211_HT_CTL_LEN in ieee80211_hdrlen() and
-= IEEE80211_HT_CTL_LEN right after leaving ieee80211_hdrlen() if the packet is
ieee80211_has_order()?
Ping-Ke
