Re: Wi-Fi Access Point Powered by Hostapd Sends Malformed Packets to 65th Client

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 06/19/2018 01:59 PM, Daniel Miess wrote:
Hi Ben,

The Wi-Fi module in question is using a QCA9880 chipset. The driver is Ath10k on the 3.14.28 kernel with some backports. The firmware is v10.1 of the Candela Tech Ath10k firmware.

I would suggest trying to reproduce this with a recent stock kernel (4.16 or 4.17), stock QCA firmware, and stock hostapd.

You can do this in a PC with the 9880 NIC in it, so no special backports or other
board-specific stuff will be needed.

If the problem persists in stock code, then it would be worth looking more closely at the
hostapd (and since you would be using stock code and normal hardware, others could
probably reproduce the same problem for debugging).

If the problem does not persist with stock code, then you can try introducing the
ath10k-ct driver and/or firmware in a controlled manner to see if they are at fault.

Thanks,
Ben



Thanks,
Daniel

-----Original Message-----
From: Ben Greear <greearb@xxxxxxxxxxxxxxx>
Sent: Tuesday, June 19, 2018 9:34 AM
To: Daniel Miess <DMiess@xxxxxxxxxxxxxxxxxx>; hostap@xxxxxxxxxxxxxxxxxxx
Subject: Re: Wi-Fi Access Point Powered by Hostapd Sends Malformed Packets to 65th Client

On 06/19/2018 08:44 AM, Daniel Miess wrote:
Hello Everyone,

I am debugging an issue I have with an access point powered by Hostapd. Hostapd was built with the default defconfig configuration and is using a Wi-Fi card which uses Ath10k drivers. I am running a test where I attempt to connect 128 clients to an access point running on the card in rapid succession. I am able to connect 64 clients to the card in about 6 or 7 seconds but once the 65th client is reached the process stalls. Responses from the access point to authentication requests from this client are malformed, being sent out with incorrect frame check sequences. I do not encounter this issue when running hostapd 2.5 but observe it with 100% reproducibility on version 2.6 as well as the latest git master branch. By bisecting I was able to narrow down my issue to a pair of commits: dc55b6b & bb598c3. These commits are seeking to "Add support for full station state operations".

Is there someone familiar with the work done in these check-ins who can comment on why I might be seeing this behavior and what I might be able to do to work around it?

ath10k behavior is significantly impacted by what firmware, driver, and chipset it is using, so please let us know what versions of those components you are using.

Thanks,
Ben


Thanks,
Daniel


_______________________________________________
Hostap mailing list
Hostap@xxxxxxxxxxxxxxxxxxx
http://lists.infradead.org/mailman/listinfo/hostap



--
Ben Greear <greearb@xxxxxxxxxxxxxxx>
Candela Technologies Inc  http://www.candelatech.com



--
Ben Greear <greearb@xxxxxxxxxxxxxxx>
Candela Technologies Inc  http://www.candelatech.com


_______________________________________________
Hostap mailing list
Hostap@xxxxxxxxxxxxxxxxxxx
http://lists.infradead.org/mailman/listinfo/hostap



[Index of Archives]     [Linux Wireless]     [Linux Kernel]     [ATH6KL]     [Linux Bluetooth]     [Linux Netdev]     [Kernel Newbies]     [IDE]     [Security]     [Git]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux ATA RAID]     [Samba]     [Device Mapper]

  Powered by Linux