Patchwork EAPOL issue when switching between SSIDs

login
register
mail settings
Submitter David Bird
Date Oct. 24, 2012, 4:55 p.m.
Message ID <1351097713.6771.5.camel@david-laptop>
Download mbox | patch
Permalink /patch/193862/
State Accepted
Commit f826635c2d4951113e87e4fd89f13ec3c39ab6fa
Headers show

Comments

David Bird - Oct. 24, 2012, 4:55 p.m.
Greetings,

There is an issue with associating to SSIDs using WPA when there are
multiple SSIDs being controlled by hostapd and when you are switching
between SSIDs. When processing the EAPOL packet, the array of virtual
APs (iface->bss) is searched looking for the station that sent the
packet in order to identify which signal context should be used during
processing. The first signal with the station in it's list gets used in
the ieee802_1x_receive() function. However, even after a station has
disassociated from a signal, it remains in that signals list of stations
pending an inactivity timeout. This leads to the wrong signal context
(one where the station had already disassociated) being used in some
cases (if the current/active bss entry appears in the list AFTER one
where the station has just disassociated from) for EAPOL processing. The
attached patch checks for the WLAN_STA_ASSOC flag before assuming it
found the 'right' signal context for the given station. 

Signed-hostap: David Bird <dbird@powercloudsystems.com>
Jouni Malinen - Oct. 25, 2012, 6:26 a.m.
On Wed, Oct 24, 2012 at 09:55:13AM -0700, David Bird wrote:
> There is an issue with associating to SSIDs using WPA when there are
> multiple SSIDs being controlled by hostapd and when you are switching
> between SSIDs. When processing the EAPOL packet, the array of virtual
> APs (iface->bss) is searched looking for the station that sent the
> packet in order to identify which signal context should be used during
> processing. The first signal with the station in it's list gets used in
> the ieee802_1x_receive() function. However, even after a station has
> disassociated from a signal, it remains in that signals list of stations
> pending an inactivity timeout. This leads to the wrong signal context
> (one where the station had already disassociated) being used in some
> cases (if the current/active bss entry appears in the list AFTER one
> where the station has just disassociated from) for EAPOL processing. The
> attached patch checks for the WLAN_STA_ASSOC flag before assuming it
> found the 'right' signal context for the given station. 

Thanks! Applied.

Patch

diff --git a/src/ap/drv_callbacks.c b/src/ap/drv_callbacks.c
index 23fa241..0200435 100644
--- a/src/ap/drv_callbacks.c
+++ b/src/ap/drv_callbacks.c
@@ -672,12 +673,15 @@  static void hostapd_event_eapol_rx(struct hostapd_data *hapd, const u8 *src,
 				   const u8 *data, size_t data_len)
 {
 	struct hostapd_iface *iface = hapd->iface;
+	struct sta_info *sta;
 	size_t j;
 
 	for (j = 0; j < iface->num_bss; j++) {
-		if (ap_get_sta(iface->bss[j], src)) {
-			hapd = iface->bss[j];
-			break;
+		if ((sta = ap_get_sta(iface->bss[j], src))) {
+			if (sta->flags & WLAN_STA_ASSOC) {
+				hapd = iface->bss[j];
+				break;
+			}
 		}
 	}