Question on IBSS + RSN

[Ben Greear]

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 at candelatech.com>
Candela Technologies Inc  http://www.candelatech.com