On 01/13/2017 02:20 PM, Jouni Malinen wrote:
On Wed, Jan 11, 2017 at 05:56:01PM -0800, Ben Greear wrote:
Hello!
Looks like there are still some issues in getting your messages through
to the list..
Yeah, I am hoping Mr Woodhouse will get back to me soon...
I am trying again to get IBSS + RSN working with ath10k. After tweaking the
firmware a bit, it sometimes works, but often it does not. In particular,
it appears that one side will be able to send and receive (and decode properly),
and the other side can send properly, but the other side cannot decode.
Perhaps in a simpler case, I sometimes see one side send EAPOL 1/4, and the peer responds
with what is almost certainly an encrypted EAPOL 2/4.
At other times, both sides do the EAPOL 4-way at the same time, and then I see
all 4 messages for each peer in wireshark (each of them are not encryped).
For now, I would like to try to debug and understand this EAPOL issue.
First, which part of the code determines if EAPOL messages should be
encrypted or not?
Ignoring WPA (the original version, i.e., not WPA2) and IEEE 802.1X
(dynamic WEP), the actual WPA2/RSN cases are pretty clear: EAPOL frames
are encrypted if TK is configured and enabled for TX and are sent in
plain if TK is not configured (or enabled for TX). In practice, the
initial EAP authentication (if any) and the first 4-way handshake are
sent in clear and everything after that is sent encrypted.
Is it ever valid for an EAPOL 2/4 to be encrypted?
Yes, that would be the case when using 4-way handshake to rekey the
pairwise key.
As far as the specific RSN IBSS case is concerned, it sounds like either
the existing key is not cleared when it should be (on receiving
Authentication frame) or a request to clear the key is not send (a STA
can send out an Authentication frame to clear the peer TK to recover
from cases where the other end has a key and the local end had to be
restarted in a manner that lost its TK).
Ok, seems I should focus on events around Authentication message then.
I have spent some more time on the problem, and here is a summary in case
something comes to mind (all of this pertains to 2 ath10k devices trying
to talk to themselves with ISBS + RSN):
When using latest LEDE on an ARM platform (and my ath10k-ct driver and firmware), then IBSS + RSN
almost never works, but, for instance, I went off to lunch today with supplicants
running and trying to connect (but ping failing), and when I got back from lunch
it was working. I had previously tried all sorts disconnect & reassociate sequences
in hopes of getting it to work earlier, without success.
When using my 4.7.10+ kernel (with same ath10k-ct driver and firmware),
Fedora OS, Intel x64 platform, recent supplicant, then IBSS + RSN + ath10k usually works, though occasionally
it will not, or it will require some restarts of supplicant to get it going.
When using a 4.9.2+ kernel on same systems that previously ran 4.7.10+ successfully,
then I could not get IBSS + RSN to work at all. Maybe if I let it sit for a while it would have worked,
and maybe I was just getting unlucky for one reason or another, and maybe I have
other regression bugs I have not found yet.
Needless to say, it's all a bit frustrating. As far as I can tell, the firmware
is handling the encryption properly, at least when properly configured. But,
I am suspicious that something after 4.7 kernel has made this work less often.
On a related topic, is this page below a good guide for how hostap project
attempst to implement IBSS + RSN?
http://etutorials.org/Networking/802.11+security.+wi-fi+protected+access+and+802.11i/Part+II+The+Design+of+Wi-Fi+Security/Chapter+13.+Wi-Fi+LAN+Coordination+ESS+and+IBSS/IBSS+Ad-Hoc+Networks/
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
