A-MSDU reception not working?

[Denton Gentry]

On Tue, Jul 8, 2014 at 3:59 AM, Bartosz Markowski
<bartosz.markowski at tieto.com> wrote:
> On 8 July 2014 09:02, Janusz Dziedzic <janusz.dziedzic at tieto.com> wrote:
>
> [...]
>
>> BTW, when AP (ath10k) send TCP ACK - are this packets also AMSDU?
>> I see in my case AP can send 3 x A-MSDU (with total size 304 bytes)
>> small frames aggregated. Maybe your HW have problems with that.
>
> @Denton - could you please try to apply this patch -->
> http://permalink.gmane.org/gmane.linux.kernel.wireless.general/124128
> (adds debugfs entires so you can manually configure ampdu/amsdu
> settings) and check whether setting the amsdu to 1 will bypass the
> problem (gets rid of aggregated TCP ACKs)
>
> echo "1 64" > htt_max_amsdu_ampdu

I applied the patch and used echo "1 64" >
/sys/.../htt_max_amsdu_ampdu. It did not improve the throughput of the
802.11ac MacBook Air.

Even without applying this patch, the sniffer trace does not show the
TCP ACKs going back to the MacBook being aggregated as A-MSDU. They
are either individual frames or A-MPDU.


> As Janusz wrote ath10k has enabled checksum offloads, so we do not
> think the retransmissions you noticed, by sniffing via ath10k device,
> are due to the CRC erorrs.
>
>> As I remember correctly someone some time ago report problems with
>> MacBook pro retina but I am not sure this is the same, while no one
>> tests the fix.
>
> This is it: http://lists.infradead.org/pipermail/ath10k/2014-May/001917.html.
> We checked that time and got a hint from firmware guys there was an
> IOT problem with amsdu 3 setting in our AP with BRCM sta. Can follow
> up on this if that's the case here also.
>
> -Bartosz