aboutsummaryrefslogtreecommitdiffstats
path: root/src/fst
diff options
context:
space:
mode:
authorDedy Lansky <qca_dlansky@qca.qualcomm.com>2015-12-29 07:24:51 (GMT)
committerJouni Malinen <j@w1.fi>2015-12-29 16:41:35 (GMT)
commit071e3bf1164c7eb261375f03f3665c548c1d58aa (patch)
treebde93a57a21f8a9056e4cc00b33fb0791fceed40 /src/fst
parent324ade51e168f28430f4429849becd0f08d507c0 (diff)
downloadhostap-071e3bf1164c7eb261375f03f3665c548c1d58aa.zip
hostap-071e3bf1164c7eb261375f03f3665c548c1d58aa.tar.gz
hostap-071e3bf1164c7eb261375f03f3665c548c1d58aa.tar.bz2
FST: Fix handling of Rx FST Setup Request when session already exists
When we receive FST Setup Request when session already exists, the following validations take place: 1. we drop the frame if needed according to MAC comparison 2. we drop the frame if the session is "not pending", i.e., if FST Setup Response was already exchanged (sent or received). There are two issues with the above: 1. MAC comparison is relevant only before the Setup Response exchange. In other words, Setup Request should not be dropped due to MAC comparison after Setup Response has been exchanged. 2. Receiving Setup Request after Setup Response exchange most likely means that FST state machine is out of sync with the peer. Dropping the Setup Request will not help solve this situation. The fix is: 1. do MAC comparison only if session is "pending", i.e., Setup Response was not yet exchanged. 2. In case Setup Response was already exchanged, reset our session and handle the Setup Request as if it arrived when session doesn't exist. Signed-off-by: Jouni Malinen <jouni@qca.qualcomm.com>
Diffstat (limited to 'src/fst')
-rw-r--r--src/fst/fst_session.c34
1 files changed, 19 insertions, 15 deletions
diff --git a/src/fst/fst_session.c b/src/fst/fst_session.c
index f804b12..9e4dada 100644
--- a/src/fst/fst_session.c
+++ b/src/fst/fst_session.c
@@ -447,7 +447,9 @@ static void fst_session_handle_setup_request(struct fst_iface *iface,
* the initiator’s MAC address, in which case, the responder
* shall delete the received FST Setup Request.
*/
- if (os_memcmp(mgmt->da, mgmt->sa, ETH_ALEN) > 0) {
+ if (fst_session_is_ready_pending(s) &&
+ /* waiting for Setup Response */
+ os_memcmp(mgmt->da, mgmt->sa, ETH_ALEN) > 0) {
fst_printf_session(s, MSG_WARNING,
"FST Request dropped due to MAC comparison (our MAC is "
MACSTR ")",
@@ -455,23 +457,26 @@ static void fst_session_handle_setup_request(struct fst_iface *iface,
return;
}
- if (!fst_session_is_ready_pending(s)) {
- fst_printf_session(s, MSG_WARNING,
- "FST Request from " MACSTR
- " dropped due to inappropriate state %s",
- MAC2STR(mgmt->da),
- fst_session_state_name(s->state));
- return;
- }
+ /*
+ * State is SETUP_COMPLETION (either in transition or not) or
+ * TRANSITION_DONE (in transition).
+ * Setup Request arriving in this state could mean:
+ * 1. peer sent it before receiving our Setup Request (race
+ * condition)
+ * 2. peer didn't receive our Setup Response. Peer is retrying
+ * after STT timeout
+ * 3. peer's FST state machines are out of sync due to some
+ * other reason
+ *
+ * We will reset our session and create a new one instead.
+ */
+ fst_printf_session(s, MSG_WARNING,
+ "resetting due to FST request");
/*
* If FST Setup Request arrived with the same FSTS ID as one we
- * initialized before, it means the other side either didn't
- * receive our FST Request or skipped it for some reason (for
- * example, due to numerical MAC comparison).
- *
- * In this case, there's no need to tear down the session.
+ * initialized before, there's no need to tear down the session.
* Moreover, as FSTS ID is the same, the other side will
* associate this tear down with the session it initiated that
* will break the sync.
@@ -483,7 +488,6 @@ static void fst_session_handle_setup_request(struct fst_iface *iface,
"Skipping TearDown as the FST request has the same FSTS ID as initiated");
fst_session_set_state(s, FST_SESSION_STATE_INITIAL, &evext);
fst_session_stt_disarm(s);
- fst_printf_session(s, MSG_WARNING, "reset due to FST request");
}
s = fst_session_create(g);