802.11r issues, and some resolutions

[Jouni Malinen]

On Sun, Jan 17, 2010 at 01:39:14AM +0100, Marcin Marzec wrote:

> 1) There are some packets that shoud be send to the DS interface (PMK-R1 
> push, pull, etc) but they are going to wlan interface. Because in 802.11r AP 
> shoud be a bridge, this is my resolution for this:
> 
> --- ./a/src/ap/wpa_auth_glue.c 2010-01-08 21:16:53.474786606 +0100
> +++ ./b/src/ap/wpa_auth_glue.c 2010-01-08 20:36:05.000000000 +0100
> @@ -426,7 +426,7 @@
> 
>  #ifdef CONFIG_IEEE80211R
>   if (!hostapd_drv_none(hapd)) {
> -  hapd->l2 = l2_packet_init(hapd->conf->iface, NULL, ETH_P_RRB,
> +  hapd->l2 = l2_packet_init(hapd->conf->bridge, NULL, ETH_P_RRB,
>         hostapd_rrb_receive, hapd, 0);

I'll need to get my mac80211_hwsim setup into working state to run some
FT tests and this alone did not seem to be enough for it. I'll see if I
can get it working better by adding two l2_packet connections (i.e., one
for receiving frames from the bridge interface and another one for
transmitting frames through the wlan0 interface which will then end up
in the bridge.

> and it works fine, but bridge must be created before starting hostapd.
> But probably there will be more issues with this because of bridge issues 
> with new 2.6.33 kernel.

That bridge issue should now be resolved with hostapd 0.7.1 which is
able to add the interfaces into a bridge after having changed the
interface type.

> 2) L2 packets, which are going to DS are encrypted, and tehre are key for 
> this in configuration files. Packets send from AP1 to AP2 are encrypted with 
> AP2 key. AP2 recives packet and decrypt it using AP1 key which is diffrent. 
> So it should be that AP2 decrypt packet with his AP2 key. Also r0kh and r1kh 
> keys are mixed.
> 
> As a workaround i set all keys the same i config file.

Hmm.. How did you configure the keys? There should be a match between
r0kh on AP1 and r1kh on AP2 (and the other way around). My test setup
was not working properly, so I did not yet confirm that this works in
the way I assume it was supposed to.

> 3) Typo error in src/common/defs.h
> 
> --- a/src/common/defs.h 2010-01-03 21:20:27.000000000 +0100
> +++ b/src/common/defs.h 2010-01-17 01:11:30.689846688 +0100
> @@ -77,7 +77,7 @@
>  #define WPA_AUTH_ALG_OPEN BIT(0)
>  #define WPA_AUTH_ALG_SHARED BIT(1)
>  #define WPA_AUTH_ALG_LEAP BIT(2)
> -#define WPA_AUTH_ALG_FT BIT(2)
> +#define WPA_AUTH_ALG_FT BIT(3)

Thanks, applied.

> Even after fixing those problems 802.11r still don't work.
> When using 2.6.31 kernel I got problem like this (on wpa_supplicant):
> [...]
> FT: Installing PTK to the driver.
> wpa_driver_nl80211_set_key: ifindex=4 alg=3 addr=0xbfe746e0 key_idx=0 
> set_tx=1 seq_len=6 key_len=16
>    addr=00:1d:0f:b4:a9:15
> nl80211: set_key failed; err=-2 No such file or directory)
> FT: Failed to set PTK to the driver
> [...]

There is an issue in PTK configuration with nl80211/mac80211.. There
should be a TODO/FIX comment on that in the source code. The problem
here is that the key is being configured before association and
mac80211/cfg80211 is not exactly ready for it.. I quick workaround would
be to re-configure the key after reassociation has been completed.

> When using 2.6.32 kernell I got problem like this(on wpa_supplicant):
> 
> [...]
> EAPOL: External notification - portControl=Auto
> nl80211: Authenticate (ifindex=2)
>   * bssid=00:1d:0f:b4:a9:15
>   * freq=2457
>   * SSID - hexdump_ascii(len=11):
>      6d 2d 77 70 61 32 2d 70 73 6b 72                  m-wpa2-pskr

>   * Auth Type 2
> nl80211: MLME command failed: ret=-114 (Operation already in progress)
> nl80211: Retry authentication after forced deauthentication
> wpa_driver_nl80211_deauthenticate
> nl80211: Authenticate (ifindex=2)

This is known cfg80211 limitation and the workaround in wpa_supplicant
seems to work for it. Eventually, it could be optimized to avoid having
to send out the deauthentication frame.

> FT: Installing PTK to the driver.
> wpa_driver_nl80211_set_key: ifindex=2 alg=3 addr=0xbfc92ca0 key_idx=0 
> set_tx=1 seq_len=6 key_len=16
>    addr=00:1d:0f:b4:a9:15
> nl80211: set_key default failed; err=-67 Link has been severed)
> FT: Failed to set PTK to the driver

I would assume this is the same issue as with older kernel or well, at
least my comments above apply to this ;-).

> So I think this is because of mac80211 MLME for station mode. Is there a 
> kernel patch to make MLME in mac80211 for station mode to userspace ?
> Maybe after this 802.11r finally should work.

I have not kept my patch up-to-date for this and anyway, that would not
be the proper way to get this working with mac80211.

There is now support for registering Action frame handlers in
nl80211/mac80211 in the kernel tree and that should make it possible to
complete support for over-the-DS FT. I added initial step for that (TX
part) into wpa_supplicant driver_nl80211.c and it looks like the Action
frame was being transmitted properly. Once I get my test setup working
on the AP side, I can hopefully complete this by adding the RX event for
the FT Action frame response. The other remaining blocker is the PTK
set_key operation as mentioned above and I think I'll start with the
workaround of re-configuring the key after reassociation for now..

There are number of other things that need to be cleaned up or fixed in
cfg80211/mac80211, but the changes described above will hopefully get
some more use cases into more or less working state.

-- 
Jouni Malinen                                            PGP id EFC895FA