On Fri, Nov 23, 2018 at 09:05:36PM +0530, Sarada Prasanna Garnayak wrote:
> In some cases we got to the assoc cb function even though
> the was not associated. fix it by ignoring the assoc cb.
What does this fix? Please note that (Re)Association Response frame TX
callback is supposed to be received for all transmitted (Re)Association
Response frames, including the ones that indicate failure. In those
failure cases, the STA would not be associated and this patch is
actually breaking the expected behavior (which is not really doing more
than a debug print at the moment).
> diff --git a/src/ap/ieee802_11.c b/src/ap/ieee802_11.c
> @@ -4153,6 +4153,13 @@ static void handle_assoc_cb(struct hostapd_data *hapd,
> else
> status = le_to_host16(mgmt->u.assoc_resp.status_code);
>
> + if (!(sta->flags & WLAN_STA_ASSOC_REQ_OK)) {
> + hostapd_logger(hapd, sta->addr, HOSTAPD_MODULE_IEEE80211,
> + HOSTAPD_LEVEL_INFO,
> + "STA is not associated, ignoring assoc cb");
WLAN_STA_ASSOC_REQ_OK does not mean that the STA is associated;
WLAN_STA_ASSOC does. In other words, the commit message is confusing
since it does not match this flag use and this print would also be
misleading.
> + return;
> + }
> +
> if (!ok) {
Anyway, I do not think this patch is correct. If there is a real issue
here, please describe it in more detail and provide a debug log showing
the case. If some parts of handle_assoc_cb() needs to be skipped, that's
fine, but it most likely needs to be done based on something else than
missing WLAN_STA_ASSOC_REQ_OK resulting in return from the function
before that !ok case.
--
Jouni Malinen PGP id EFC895FA
_______________________________________________
Hostap mailing list
Hostap@xxxxxxxxxxxxxxxxxxx
http://lists.infradead.org/mailman/listinfo/hostap
