From: tkc <chaitanya.mgit@xxxxxxxxx> Before the tx_status is received for the action frame, if we get another request, we respond to that by freeing the memory for pending_action_tx, but we don't cancel the TX wait, so in the kernel the ROC will not be cancelled. Due to above issue, wpa_supplicant assumes that all pending RoC's are cancelled and proceeds with interface creation and connection, where as state in mac80211/driver will be roc_in_progress. This is leading to issues at driver level. Signed-off-by: Chaitanya T K <chaitanya.mgit@xxxxxxxxx> --- V2: Fix 2 from's. Remove the unnecessary braces. --- wpa_supplicant/offchannel.c | 12 +++--------- 1 file changed, 3 insertions(+), 9 deletions(-) diff --git a/wpa_supplicant/offchannel.c b/wpa_supplicant/offchannel.c index 6b3f83c..581c5f6 100644 --- a/wpa_supplicant/offchannel.c +++ b/wpa_supplicant/offchannel.c @@ -253,15 +253,9 @@ int offchannel_send_action(struct wpa_supplicant *wpa_s, unsigned int freq, wpa_s->pending_action_tx_status_cb = tx_cb; - if (wpa_s->pending_action_tx) { - wpa_printf(MSG_DEBUG, "Off-channel: Dropped pending Action " - "frame TX to " MACSTR " (pending_action_tx=%p)", - MAC2STR(wpa_s->pending_action_dst), - wpa_s->pending_action_tx); - wpa_hexdump_buf(MSG_MSGDUMP, "Pending TX frame", - wpa_s->pending_action_tx); - wpabuf_free(wpa_s->pending_action_tx); - } + if (wpa_s->pending_action_tx) + offchannel_send_action_done(wpa_s); + wpa_s->pending_action_tx_done = 0; wpa_s->pending_action_tx = wpabuf_alloc(len); if (wpa_s->pending_action_tx == NULL) { -- 1.7.9.5 _______________________________________________ Hostap mailing list Hostap@xxxxxxxxxxxxxxxxxxx http://lists.infradead.org/mailman/listinfo/hostap