On 12/05/2017 05:12 PM, Ben Greear wrote:
On 12/05/2017 04:23 PM, Ben Greear wrote:
Hello,
We've been doing some tests where we have lots of virtual stations on
a wave-2 9984 ath10k system, and another linux PC acting as an AP. hostapd, supplicant,
and kernels should be fairly recent on all of these, but all of them are modified at least
a bit from stock software/firmware.
We are restarting the AP over and over and verifying that the
station system can properly reconnect.
After some time, we see the stations fail to connect, due to status-14.
I have uploaded a pcap here:
http://www.candelatech.com/downloads/err-14.pcapng
One example of this problem is in frames 76 and 77.
Frame 53 and 54 show what appears to be a successful auth attempt.
I have not dug into this in detail yet...but in case someone has
time to take a look, I'd welcome suggestions as to where the problem
might lie.
So, I noticed I can restart hostapd and problem persists (I have not restarted
the stations).
It is failing here in handle-auth (I added the debugging):
if (hapd->tkip_countermeasures) {
wpa_printf(MSG_DEBUG,
"Michael-MIC failure (tkip-countermeasures)");
resp = WLAN_REASON_MICHAEL_MIC_FAILURE;
goto fail;
}
One thing, the resp here is assigned to a REASON code instead of a status, which seems
to be one bug. What is the proper status code for this?
I don't yet know why tkip_countermeasures is true...
Here are some more logs from the AP that might shed some light. It
definitely seems that TKIP counter measures are being invoked for one
of the stations (at least), and then no others can associate during
this time.
http://paste.ubuntu.com/26127085/
Thanks,
Ben
--
Ben Greear <greearb@xxxxxxxxxxxxxxx>
Candela Technologies Inc http://www.candelatech.com
_______________________________________________
Hostap mailing list
Hostap@xxxxxxxxxxxxxxxxxxx
http://lists.infradead.org/mailman/listinfo/hostap
