Association race when acting as AP?

[Michal Kazior]

Hello,

I've been recently trying to figure out why I'm seeing messages like the
following in dmesg:

 [  135.866308] p2p-wlan1-0: authenticate with 02:03:7f:91:53:51
 [  135.869745] p2p-wlan1-0: send auth to 02:03:7f:91:53:51 (try 1/3)
 [  135.877538] p2p-wlan1-0: authenticated
 [  135.888029] p2p-wlan1-0: associate with 02:03:7f:91:53:51 (try 1/3)
 [  135.912461] p2p-wlan1-0: RX AssocResp from 02:03:7f:91:53:51
(capab=0x411 status=0 aid=1)
 [  135.916226] p2p-wlan1-0: associated
 [  135.918038] p2p-wlan1-0: deauthenticated from 02:03:7f:91:53:51
(Reason: 7=CLASS3_FRAME_FROM_NONASSOC_STA)

This gets repeated a few times. Sometimes the connection succeeds after a
few cycles, sometimes it doesn't. I've seen this mostly while testing P2P.

After looking into hostapd code I noticed something strange and I wonder if
anyone else is already aware of this problem:

 1. AP starts
 2. STA->AP auth OTA
 3. AP->STA auth OTA
 4. STA->AP assoc req OTA
 5. AP->STA assoc resp OTA
 6. STA sends NullFunc with "STA will go to sleep" bit set
 7. AP driver/device sees a frame from with unknown TA/SA and issues Deauth
w/ Reason 7
   (this Deauth doesn't originate from hostapd; it comes from the device FW
in my case)
 8. AP sees TX_STATUS for (5) so it just now installs station entry to
device/driver
 9. AP attempts to send EAPOL but STA is no longer there

I'm able to reproduce this quite easily with QCA6174 (ath10k) acting as P2P
GO and Intel 7260 (iwlmvm) as P2P Client.

This also suggests it's not P2P specific.

To me this looks like a race in hostapd. The station should be installed to
driver _before_ sending Assoc Resp frame, not after. My quick-n-dirty hack
seems to help:

--- a/src/ap/ieee802_11.c
+++ b/src/ap/ieee802_11.c
@@ -42,6 +42,11 @@
 #include "dfs.h"


+static void handle_assoc_cb(struct hostapd_data *hapd,
+                           const struct ieee80211_mgmt *mgmt,
+                           size_t len, int reassoc, int ok);
+
+
 u8 * hostapd_eid_supp_rates(struct hostapd_data *hapd, u8 *eid)
 {
        u8 *pos = eid;
@@ -1675,6 +1680,8 @@ static void send_assoc_resp(struct hostapd_data
*hapd, struct sta_info *sta,

        send_len += p - reply->u.assoc_resp.variable;

+       handle_assoc_cb(hapd, reply, send_len, 0, 1);
+
        if (hostapd_drv_send_mlme(hapd, reply, send_len, 0) < 0)
                wpa_printf(MSG_INFO, "Failed to send assoc resp: %s",
                           strerror(errno));
@@ -2561,7 +2568,6 @@ void ieee802_11_mgmt_cb(struct hostapd_data *hapd,
const u8 *buf, size_t len,
                break;
        case WLAN_FC_STYPE_ASSOC_RESP:
                wpa_printf(MSG_DEBUG, "mgmt::assoc_resp cb");
-               handle_assoc_cb(hapd, mgmt, len, 0, ok);
                break;
        case WLAN_FC_STYPE_REASSOC_RESP:
                wpa_printf(MSG_DEBUG, "mgmt::reassoc_resp cb");


Obviously this is whitespace damaged and incomplete as it doesn't cover all
the possible fail cases. It's just a proof-of-concept for the purpose of
discussion.

Is anyone aware of this problem already? Anyone working on it? Any gotchas
I should be aware of before I go into fixing this in a proper way? Or am I
missing something and this isn't actually a problem?


Micha?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.shmoo.com/pipermail/hostap/attachments/20150702/ff980c43/attachment.htm>