On Tue, 2022-04-12 at 00:37 +0000, Pkshih wrote: > > > > 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. Haha, right. I'm an idiot I guess, why did I not think of RX? > After I fix my driver, I don't need this, but I think it is worth to > have > this patch. OK. But I guess that means no hurry. > > > > 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()? Yeah, thinking about that, I guess you're right. Maybe we can express the 22 a bit better (some headerlen - 2 with a comment?), but I can look at that when I apply the patch. Thanks! johannes
