Getting bad MIC when trying ath10k + ath9k IBSS with RSN

Getting bad MIC when trying ath10k + ath9k IBSS with RSN

[Ben Greear]

I have been hacking on ath10k driver and firmware in attempt to enable IBSS + RSN.

Currently, I see message 1/4 in both directions, but the ath9k wpa_supplicant always reports 2/4
from ath10k station as having bad MIC (and AC supplicant dumps core shortly after when there is an EAPOL timeout,
I haven't looked into the core yet, but unlikely to be directly related to bad MIC I think since
ath9k <-> ath9k works fine).

Almost certainly this is some bug in ath10k and/or the firmware, but if someone
has some suggestions as to what it might be or how to debug it further, I would
appreciate the help!

Network capture and supplicant logs are found here:

https://www.candelatech.com/downloads/tmp/

Thanks,
Ben

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


_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k

Re: Getting bad MIC when trying ath10k + ath9k IBSS with RSN

[Nicolas Cavallari]

[re-adding ath10k, sorry for removing it]

On 09/04/2015 01:25, Ben Greear wrote:
> On 04/08/2015 07:53 AM, Ben Greear wrote:
> Ok, the EAPOL seems to work now, as long as I restart both supplicants before
> I try to connect.
> 
> It appears now that there is something wrong with setting the keys.  The
> firmware appears to get a real key, and then shortly after, the keys are
> removed and encryption is disabled.
> 
> The supplicant log is below.  I believe the crucial part is this.  Any idea why
> this would be failing?  (I'll poke in the kernel tomorrow to try to find
> the reason as well...)
> 
> 1428534417.236258: wpa_driver_nl80211_set_key: ifindex=131 (wlan0) alg=3 addr=0x2344900 key_idx=1 set_tx=0 seq_len=6 key_len=16
> 1428534417.236273: nl80211: KEY_DATA - hexdump(len=16): a5 28 f3 02 e9 cb a4 de 87 01 a4 9c c9 d2 a8 89
> 1428534417.236298: nl80211: KEY_SEQ - hexdump(len=6): 00 00 00 00 00 00
> 1428534417.236311:    addr=00:0e:8e:3e:8b:96
> 1428534417.236319:    RSN IBSS RX GTK
> 1428534417.236355: nl80211: set_key failed; err=-22 Invalid argument)
> 1428534417.236367: wlan0: WPA: Failed to set GTK to the driver (alg=3 keylen=16 keyidx=1)
> 1428534417.236376: wlan0: RSN: Failed to install GTK
> 1428534417.236385: wlan0: RSN: Failed to configure GTK
> 1428534417.236393: SUPP: supp_deauthenticate (TODO)
> 1428534417.236419: l2_packet_receive: src=00:0e:8e:3e:8b:96 len=99

I see this failure with drivers that do not support IBSS-RSN...
Otherwise, this request must succeed.

The only difference between AP mode and IBSS mode is that in IBSS mode,
each peer have their own GTK, so you have to program a per-sta GTK for
decryption.

But GTK is for multicast frames, and I already made broken IBSS-RSN
networks with drivers that do not support IBSS-RSN, because the PTK was
still programmed correctly. You just have a network that can only pass
unicast traffic.  Your PTK was programmed correctly:

1428534380.576614: AUTH: set_key - key - hexdump(len=16): 99 76 89 40 b3
61 28 4f 60 2c 4b 75 72 6b 4e e8
1428534380.576645: wpa_driver_nl80211_set_key: ifindex=131 (wlan0) alg=3
addr=0x23490f0 key_idx=0 set_tx=1 seq_len=6 key_len=16
1428534380.576657: nl80211: KEY_DATA - hexdump(len=16): 99 76 89 40 b3
61 28 4f 60 2c 4b 75 72 6b 4e e8
1428534380.576668: nl80211: KEY_SEQ - hexdump(len=6): 00 00 00 00 00 00
1428534380.576677:    addr=00:0e:8e:3e:8b:96
1428534380.577056: nl80211: Set STA flags - ifname=wlan0
addr=00:0e:8e:3e:8b:96 total_flags=0x1 flags_or=0x1 flags_and=0xffffffff
authorized=1
1428534380.577108: AUTH: 00:0e:8e:3e:8b:96 authorizing port


However, there are other problems in your log:

1) There are two NL80211_CMD_JOIN_IBSS events from the kernel, for only
one join request.

2) wpa_supplicant sent a authentication frame at 1428534380.167582 and
never got any tx_status response from the kernel.  This was before the
second NL80211_CMD_JOIN_IBSS event.

Loosing a authentication frame is normally no big deal. It often
happens. They are even stations that do not support them.  If i remember
the logic that i implemented in wpa_supplicant, you consider the other
station as authenticated if you receive an authentication response or an
authentication request, or after a timeout.

3) But this timeout seems buggy: after completing the EAPOL exchange,
this timer fires:

1428534381.168652: RSN: Timeout on waiting Authentication frame response
from 00:0e:8e:3e:8b:96 - start authenticator

This timer shouldn't even be present. And even if it did, it shouldn't
start the authenticator as it is already started.  I didn't track the
latest changes in wpa_supplicant's IBSS-RSN support, but this seems wrong.

But it restart the authenticator anyway, which clears the PTK:

1428534381.168693: AUTH: auth_set_key(alg=0 addr=00:0e:8e:3e:8b:96
key_idx=0)
1428534381.168703: AUTH: set_key - key - hexdump(len=0): [NULL]
1428534381.168737: wpa_driver_nl80211_set_key: ifindex=131 (wlan0) alg=0
addr=0x2344bb0 key_idx=0 set_tx=1 seq_len=6 key_len=0
1428534381.168751: nl80211: KEY_SEQ - hexdump(len=6): 00 00 00 00 00 00
1428534381.168761:    addr=00:0e:8e:3e:8b:96

And mark the station as unauthorized:

1428534381.169266: nl80211: Set STA flags - ifname=wlan0
addr=00:0e:8e:3e:8b:96 total_flags=0x0 flags_or=0x0 flags_and=0xfffffffe
authorized=0
1428534381.169347: AUTH: 00:0e:8e:3e:8b:96 unauthorizing port

After that, it retries an EAPOL exchange which basically fail: the
remote station still have an encrypted session, and the logic in
wpa_supplicant is that you can only reset a encryption session by
sending an authentication frame.

_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k

Re: Getting bad MIC when trying ath10k + ath9k IBSS with RSN

[Ben Greear]

On 04/09/2015 01:41 AM, Nicolas Cavallari wrote:
> [re-adding ath10k, sorry for removing it]
> 
> On 09/04/2015 01:25, Ben Greear wrote:
>> On 04/08/2015 07:53 AM, Ben Greear wrote:
>> Ok, the EAPOL seems to work now, as long as I restart both supplicants before
>> I try to connect.
>>
>> It appears now that there is something wrong with setting the keys.  The
>> firmware appears to get a real key, and then shortly after, the keys are
>> removed and encryption is disabled.
>>
>> The supplicant log is below.  I believe the crucial part is this.  Any idea why
>> this would be failing?  (I'll poke in the kernel tomorrow to try to find
>> the reason as well...)
>>
>> 1428534417.236258: wpa_driver_nl80211_set_key: ifindex=131 (wlan0) alg=3 addr=0x2344900 key_idx=1 set_tx=0 seq_len=6 key_len=16
>> 1428534417.236273: nl80211: KEY_DATA - hexdump(len=16): a5 28 f3 02 e9 cb a4 de 87 01 a4 9c c9 d2 a8 89
>> 1428534417.236298: nl80211: KEY_SEQ - hexdump(len=6): 00 00 00 00 00 00
>> 1428534417.236311:    addr=00:0e:8e:3e:8b:96
>> 1428534417.236319:    RSN IBSS RX GTK
>> 1428534417.236355: nl80211: set_key failed; err=-22 Invalid argument)
>> 1428534417.236367: wlan0: WPA: Failed to set GTK to the driver (alg=3 keylen=16 keyidx=1)
>> 1428534417.236376: wlan0: RSN: Failed to install GTK
>> 1428534417.236385: wlan0: RSN: Failed to configure GTK
>> 1428534417.236393: SUPP: supp_deauthenticate (TODO)
>> 1428534417.236419: l2_packet_receive: src=00:0e:8e:3e:8b:96 len=99
> 
> I see this failure with drivers that do not support IBSS-RSN...
> Otherwise, this request must succeed.

Yeah, I thought I had applied Januz's patch to enable this in ath10k,
but I had not.

With that enabled, the system tries to do encrypted traffic, but
it looks like the unicast frames from ath10k are corrupted.

> However, there are other problems in your log:
> 
> 1) There are two NL80211_CMD_JOIN_IBSS events from the kernel, for only
> one join request.
> 
> 2) wpa_supplicant sent a authentication frame at 1428534380.167582 and
> never got any tx_status response from the kernel.  This was before the
> second NL80211_CMD_JOIN_IBSS event.
> 
> Loosing a authentication frame is normally no big deal. It often
> happens. They are even stations that do not support them.  If i remember
> the logic that i implemented in wpa_supplicant, you consider the other
> station as authenticated if you receive an authentication response or an
> authentication request, or after a timeout.
> 
> 3) But this timeout seems buggy: after completing the EAPOL exchange,
> this timer fires:
> 
> 1428534381.168652: RSN: Timeout on waiting Authentication frame response
> from 00:0e:8e:3e:8b:96 - start authenticator
> 
> This timer shouldn't even be present. And even if it did, it shouldn't
> start the authenticator as it is already started.  I didn't track the
> latest changes in wpa_supplicant's IBSS-RSN support, but this seems wrong.
> 
> But it restart the authenticator anyway, which clears the PTK:
> 
> 1428534381.168693: AUTH: auth_set_key(alg=0 addr=00:0e:8e:3e:8b:96
> key_idx=0)
> 1428534381.168703: AUTH: set_key - key - hexdump(len=0): [NULL]
> 1428534381.168737: wpa_driver_nl80211_set_key: ifindex=131 (wlan0) alg=0
> addr=0x2344bb0 key_idx=0 set_tx=1 seq_len=6 key_len=0
> 1428534381.168751: nl80211: KEY_SEQ - hexdump(len=6): 00 00 00 00 00 00
> 1428534381.168761:    addr=00:0e:8e:3e:8b:96
> 
> And mark the station as unauthorized:
> 
> 1428534381.169266: nl80211: Set STA flags - ifname=wlan0
> addr=00:0e:8e:3e:8b:96 total_flags=0x0 flags_or=0x0 flags_and=0xfffffffe
> authorized=0
> 1428534381.169347: AUTH: 00:0e:8e:3e:8b:96 unauthorizing port
> 
> After that, it retries an EAPOL exchange which basically fail: the
> remote station still have an encrypted session, and the logic in
> wpa_supplicant is that you can only reset a encryption session by
> sending an authentication frame.


Ok, this is probably why I have to restart supplicant on each side when
I try to make the stations associate.

I think I'll look at this later, since now my stations are staying
authenticated long enough to do some traffic tests at least.

Thanks,
Ben

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


_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k