htt_rx questions in 4.0 kernel.

[Michal Kazior]

On 6 May 2015 at 00:35, Ben Greear <greearb at candelatech.com> wrote:
> I am slowly tracking down problems with receiving data frames
> on 3.19 and higher kernels, when using my rx-sw-crypt patch
> and CT firmware.
>
> I think the main thing my patch is changing in this case is that
> the frames are received in raw mode with this patch enabled.
>
> Hard to do a bisect, because the rx logic changed so much and I
> have to apply fairly tricky patches to make my feature work, but
> 3.18 and earlier seem to work fine, and 3.19 and 4.0 does not.
>
> Latest clue appears to be that ARP frames are received fine (data
> contents looks right), but the stack fails the is_data() check.
>
> While poking at this further, I noticed that ath10k_htt_rx_h_undecap
> defines 'hdr' and assigns it, but never uses it.

It does use it:

 https://github.com/kvalo/ath/blob/master/drivers/net/wireless/ath/ath10k/htt_rx.c#L1028
 https://github.com/kvalo/ath/blob/master/drivers/net/wireless/ath/ath10k/htt_rx.c#L1034
 https://github.com/kvalo/ath/blob/master/drivers/net/wireless/ath/ath10k/htt_rx.c#L1039


> I also do not see the first_hdr used when decapping raw
> frames.

`first_hdr` isn't necessary for raw frame processing. Let me explain why:

When you receive A-MSDU you have two options: you either get it raw, or non-raw.

When you get non-raw each subframe is delivered in a separate MSDU
buffer on HTT. Each contains an rx descriptor. However only first MSDU
in that list contains a complete decapped 802.11 header info. That's
why `first_hdr` is needed.

When you get raw there's no MSDU-based splitting. If a raw frame
doesn't fit into a single HTT buffer you get chained MSDUs. In that
case only first buffer contains Rx descriptor. Others are just data
continuation and have no Rx descriptor.

Ergo `first_hdr` doesn't make sense for raw as it is the `hdr` anyway.


> Maybe that is part of the problem?

Hmm..

Did you try to compare ARP hexdump when it is popped from HTT Rx ring
and when it is given to mac80211? Is the protected-bit set correctly?
Are Rx flags set correctly so mac80211 treats the frame properly?
Maybe the way you're hooking your swcrypto is not correct anymore,
i.e. there's an implicit assumption in your swcrypto logic which isn't
true anymore?


Michał