From patchwork Fri Dec 2 11:00:47 2016 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Jouni Malinen X-Patchwork-Id: 701925 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Received: from bombadil.infradead.org (bombadil.infradead.org [IPv6:2001:1868:205::9]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ozlabs.org (Postfix) with ESMTPS id 3tVWS04Xqpz9t9x for ; Fri, 2 Dec 2016 22:01:36 +1100 (AEDT) Received: from localhost ([127.0.0.1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.85_2 #1 (Red Hat Linux)) id 1cClaf-0001PC-8j; Fri, 02 Dec 2016 11:01:17 +0000 Received: from mail.w1.fi ([2a01:7e00::f03c:91ff:fedb:30e2] helo=li674-96.members.linode.com) by bombadil.infradead.org with esmtps (Exim 4.85_2 #1 (Red Hat Linux)) id 1cClaa-0001Co-Op for hostap@lists.infradead.org; Fri, 02 Dec 2016 11:01:15 +0000 Received: from jm (176-93-239-247.bb.dnainternet.fi [176.93.239.247]) by li674-96.members.linode.com (Postfix) with ESMTPSA id 4A74B11697; Fri, 2 Dec 2016 11:00:48 +0000 (UTC) Received: by jm (sSMTP sendmail emulation); Fri, 02 Dec 2016 13:00:47 +0200 Date: Fri, 2 Dec 2016 13:00:47 +0200 From: Jouni Malinen To: Matthias May Subject: Re: [PATCH] 4addr: fix reconnecting client on connection lost Message-ID: <20161202110047.GA4128@w1.fi> References: <1467723643-19694-1-git-send-email-matthias.may@neratec.com> <20160723180121.GB6586@w1.fi> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20161202_030113_223982_6FDA0588 X-CRM114-Status: GOOD ( 22.37 ) X-Spam-Score: -3.3 (---) X-Spam-Report: SpamAssassin version 3.4.0 on bombadil.infradead.org summary: Content analysis details: (-3.3 points) pts rule name description ---- ---------------------- -------------------------------------------------- -0.0 SPF_PASS SPF: sender matches SPF record -1.4 RP_MATCHES_RCVD Envelope sender domain matches handover relay domain -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-BeenThere: hostap@lists.infradead.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: hostap@lists.infradead.org Sender: "Hostap" Errors-To: hostap-bounces+incoming=patchwork.ozlabs.org@lists.infradead.org On Sun, Jul 24, 2016 at 11:03:30PM +0200, Matthias May wrote: > On 07/23/2016 08:01 PM, Jouni Malinen wrote: > > On Tue, Jul 05, 2016 at 03:00:43PM +0200, Matthias May wrote: > >> When a 4addr client suddenly looses its connection (no deauth/deassoc) > >> the AP still thinks it is connected. > >> If the client reconnects before the AP timeoutes the client, traffic > >> cannot flow. > >> > >> Fix this by making sure the WLAN_STA_WDS flag is unset in the sta->flags > >> when the client completes association. It looks like this can be fixed by moving around the code a bit so that the handle_assoc_cb() WDS special case gets executed only after setting the kernel STA flags to associated state. > >> diff --git a/src/ap/ieee802_11.c b/src/ap/ieee802_11.c > >> @@ -2829,6 +2829,7 @@ static void handle_assoc_cb(struct hostapd_data *hapd, > >> sta->flags |= WLAN_STA_ASSOC; > >> sta->flags &= ~WLAN_STA_WNM_SLEEP_MODE; > >> + sta->flags &= ~WLAN_STA_WDS; This on the other hand causes regressions into previously working cases. I now have full set of mac80211_hwsim test cases to show this and also show the issue you reported and how it can be fixed with that code move mentioned above. > > This looks a bit strange taken into account this same handle_assoc_cb() > > function is using the WLAN_STA_WDS flag just below this: > > > > if (sta->flags & WLAN_STA_WDS) { ... > > All that would become dead code if this patch were applied. > ieee802_11_rx_from_unknown is the function which sets WLAN_STA_WDS bit > once the WLAN_STA_ASSOC is set. > Wouldn't this mean that this is already dead code now? No, that is not dead code; that gets executed if a STA that used 4addr format (i.e., gets that WLAN_STA_WDS flag) during the previous association reassociates with the same AP without going through deauthentication. That is correct thing to do here, but it just did not seem to work when done before the hostapd_set_sta_flags(hapd, sta) call. This seems to fix the issue: diff --git a/src/ap/ieee802_11.c b/src/ap/ieee802_11.c index 3e65fd3..1cecc80 100644 --- a/src/ap/ieee802_11.c +++ b/src/ap/ieee802_11.c @@ -3232,16 +3232,6 @@ static void handle_assoc_cb(struct hostapd_data *hapd, sta->sa_query_timed_out = 0; #endif /* CONFIG_IEEE80211W */ - if (sta->flags & WLAN_STA_WDS) { - int ret; - char ifname_wds[IFNAMSIZ + 1]; - - ret = hostapd_set_wds_sta(hapd, ifname_wds, sta->addr, - sta->aid, 1); - if (!ret) - hostapd_set_wds_encryption(hapd, sta, ifname_wds); - } - if (sta->eapol_sm == NULL) { /* * This STA does not use RADIUS server for EAP authentication, @@ -3258,6 +3248,19 @@ static void handle_assoc_cb(struct hostapd_data *hapd, hostapd_set_sta_flags(hapd, sta); + if (sta->flags & WLAN_STA_WDS) { + int ret; + char ifname_wds[IFNAMSIZ + 1]; + + wpa_printf(MSG_DEBUG, "Reenable 4-address WDS mode for STA " + MACSTR " (aid %u)", + MAC2STR(sta->addr), sta->aid); + ret = hostapd_set_wds_sta(hapd, ifname_wds, sta->addr, + sta->aid, 1); + if (!ret) + hostapd_set_wds_encryption(hapd, sta, ifname_wds); + } + if (sta->auth_alg == WLAN_AUTH_FT) wpa_auth_sm_event(sta->wpa_sm, WPA_ASSOC_FT); else