Verified your new patch works with our setup (ath10k/mac80211 v4.19)
with no issues after long-term testing.
Thanks Jouni.
Dennis
On Fri, Jan 4, 2019 at 3:34 PM Jouni Malinen <j@xxxxx> wrote:
>
> (oops.. managed to miss a cc to the list in my response.. sorry
> about the duplicate message Dennis)
>
> On Thu, Jan 03, 2019 at 08:17:11PM -0700, Dennis Bland wrote:
> > When hostapd 2.7 is configured for FT over-the-DS mode, performing an
> > FT roam back to a previously-connected AP gives the following error in
> > hostapd:
> >
> > nl80211: NL80211_CMD_SET_STATION result: -22 (Invalid argument)
> > wlan01: STA 06:05:04:03:02:01 IEEE 802.11: Could not set STA to kernel driver
> >
> > This results in hostapd refusing the reassociation request with code
> > 17 (Association denied because AP is unable to handle additional
> > associated stations). The kernel driver in this case is the ath10k
> > (4.19).
> >
> > In add_associated_sta() in ieee802_11.c, there is a conditional that
> > resets the wpa sm (required for FT over-the-DS mode as there is no
> > authentication frame to reset the wpa sm), but only if the STA is not
> > authorized. The STA is not authorized when performing an FT roam to a
> > new AP, but it is authorized when roaming back to a
> > previously-connected AP. Therefore, any FT over-the-DS roams to new
> > APs will work correctly, and FT over-the-DS roams to
> > previously-connected (authorized) APs will fail.
>
> mac80211 is quite unhappy in this particular case since there is no STA
> entry in the kernel and hostapd ends up trying to work around key
> reinstallation issues by refusing to clear and re-add a STA entry here.
>
> > The patch below appears to fix this issue, validated after performing
> > several thousand FT over-the-air and over-the-DS roams with our
> > automated test bed. However, I am hesitant to submit it in this form
> > as it may affect FILS (which we are not currently using) or possibly
> > KRACK:
> >
> > diff -Naur orig/hostap_2_7/src/ap/ieee802_11.c
> > new/hostap_2_7/src/ap/ieee802_11.c
> > --- orig/hostap_2_7/src/ap/ieee802_11.c 2018-12-02 12:34:59.000000000 -0700
> > +++ new/hostap_2_7/src/ap/ieee802_11.c 2018-12-28 23:41:00.394507047 -0700
> > @@ -2808,10 +2808,11 @@
> > * TK has been configured since the TX/RX PN must not be reset to 0 for
> > * the same key.
> > */
> > - if (!sta->added_unassoc &&
> > - (!(sta->flags & WLAN_STA_AUTHORIZED) ||
> > +
> > + /* do not check for WLAN_STA_AUTHORIZED for FT-over-the-DS */
> > + if (!sta->added_unassoc ||
> > (!wpa_auth_sta_ft_tk_already_set(sta->wpa_sm) &&
> > - !wpa_auth_sta_fils_tk_already_set(sta->wpa_sm)))) {
> > + !wpa_auth_sta_fils_tk_already_set(sta->wpa_sm))) {
>
> This would seem to break key reinstallation checks completely, so this
> is clearly not a good way of fixing this.
>
> This is unfortunately a very inconvenient case to handle with mac80211
> and that's why this ended up the way it did with the security fixes.
> However, I did not realize it broke more cases than the potential corner
> cases I was thinking of earlier.
>
> There is a case here in which it is safe to add the STA entry "again"
> since the encryption key (TK) is known to have changes during the
> FT-over-the-DS exchange. That is the case that you are most likely to
> hit here. I applied following changing to address this:
> https://w1.fi/cgit/hostap/commit/?id=4cf5efece394067542673a252d6ea67b898b8eb9
>
> > Not sure if FT roaming to a previous AP is included in the unit tests.
> > If not, it might be a good idea to add it.
>
> ap_ft_over_ds did indeed cover this sequence and that's what I used to
> test the key reinstallation fixes in order to try to avoid regressions
> here. Alas, that test case did not cover this particular detail since it
> was using a single hostapd process that ended up clearing the old
> association during reassociation to the other AP. I implemented a more
> complex test case with two hostapd processes to cover this particular
> sequence in more detail and that was indeed able to reproduce the issue.
> The commit mentioned above got rid of the issue that I was able to
> reproduce.
>
> --
> Jouni Malinen PGP id EFC895FA
_______________________________________________
Hostap mailing list
Hostap@xxxxxxxxxxxxxxxxxxx
http://lists.infradead.org/mailman/listinfo/hostap
