[mka]: Fix re-establishment by reset MI

[Ze Gan <ganze718@xxxxxxxxx>]

Key server maybe removed due to the ingress packets delay.
In this situation, the endpoint of key server may not be aware of
this participant who has removed the key server from peer list.
Because the egress traffic is normal, the key server will not
remove this participant from the peer list of key server.
So in the next MKA message, the key server will not dispatch a
new SAK to this participant.
And this participant can not be aware of that is a new round
of communication so that it will not update its mi at re-adding
the key server to its peer list.
So we need to update mi to avoid the failure of re-establishment
MKA session.

Signed-off-by: Ze Gan <ganze718@xxxxxxxxx>
---
 src/pae/ieee802_1x_kay.c | 25 +++++++++++++++++++++++++
 1 file changed, 25 insertions(+)

diff --git a/src/pae/ieee802_1x_kay.c b/src/pae/ieee802_1x_kay.c
index b2905a792..f3bac00af 100644
--- a/src/pae/ieee802_1x_kay.c
+++ b/src/pae/ieee802_1x_kay.c
@@ -2667,6 +2667,7 @@ static void ieee802_1x_participant_timer(void
*eloop_ctx, void *timeout_ctx)
    struct ieee802_1x_kay_peer *peer, *pre_peer;
    time_t now = time(NULL);
    bool lp_changed;
+   bool key_server_removed;
    struct receive_sc *rxsc, *pre_rxsc;
    struct transmit_sa *txsa, *pre_txsa;

@@ -2691,6 +2692,7 @@ static void ieee802_1x_participant_timer(void
*eloop_ctx, void *timeout_ctx)
    }

    lp_changed = false;
+   key_server_removed = false;
    dl_list_for_each_safe(peer, pre_peer, &participant->live_peers,
                  struct ieee802_1x_kay_peer, list) {
        if (now > peer->expire) {
@@ -2706,12 +2708,35 @@ static void ieee802_1x_participant_timer(void
*eloop_ctx, void *timeout_ctx)
                        participant, rxsc);
                }
            }
+           key_server_removed |= peer->is_key_server;
            dl_list_del(&peer->list);
            os_free(peer);
            lp_changed = true;
        }
    }

+   /**
+    * Key server may be removed due to the ingress packets delay.
+    * In this situation, the endpoint of key server may not be aware of
+    * this participant who has removed the key server from the peer list.
+    * Because the egress traffic is normal, the key server will not
+    * remove this participant from the peer list of key server.
+    * So in the next MKA message, the key server will not dispatch a
+    * new SAK to this participant.
+    * And this participant can not be aware that is a new round
+    * of communication so it will not update its mi at re-adding
+    * the key server to its peer list.
+    * So we need to update mi to avoid the failure of the re-establishment
+    * MKA session.
+    */
+   if (key_server_removed) {
+       if (!reset_participant_mi(participant)) {
+           wpa_printf(MSG_WARNING, "KaY: Could not update mi");
+       } else {
+           wpa_printf(MSG_DEBUG, "KaY: Update mi");
+       }
+   }
+
    if (lp_changed) {
        if (dl_list_empty(&participant->live_peers)) {
            participant->advised_desired = false;
--
2.25.1

_______________________________________________
Hostap mailing list
Hostap@xxxxxxxxxxxxxxxxxxx
http://lists.infradead.org/mailman/listinfo/hostap