From: tkc <[email protected]>
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 <[email protected]>
---
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
On Mon, Nov 23, 2015 at 12:45 AM, Jouni Malinen <[email protected]> wrote:
>
> On Mon, Nov 02, 2015 at 08:40:28PM +0530, Chaitanya T K wrote:
> > From: tkc <[email protected]>
> >
> > 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 <[email protected]>
> > ---
> > V2: Fix 2 from's.
> > Remove the unnecessary braces.
>
> I'm not sure I'd call that "From:" in the message body fixed (i.e., it
> should have been the second one, not the first one; alternatively, it
> would be fine to remove that From: line from the message body since the
> one in the message header has a value matching that SOB).
>
Sure will remove From.
>
> > diff --git 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);
>
> As noted in your reply to this, those debug prints should not be
> removed.
>
> As far as the change to offchannel_send_action_done() is concerned, I'm
> not sure it is the correct thing to do in all cases. Why would we cancel
> Action frame TX wait or remain-on-channel if the new frame is for the
> same channel?
>
I think wpa_supplicant can start the RoC, the FSM in mac80211
will check whether to start a new or continue the old depending on
the channel and time.
On Mon, Nov 2, 2015 at 8:40 PM, Chaitanya T K <[email protected]> wrote:
> From: tkc <[email protected]>
>
> 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 <[email protected]>
> ---
> 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);
I think we should retain this print to identify if its a proper complete
or dropping pending. Anyways will wait for comments before sending V3.
.
On Mon, Nov 02, 2015 at 08:40:28PM +0530, Chaitanya T K wrote:
> From: tkc <[email protected]>
>
> 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 <[email protected]>
> ---
> V2: Fix 2 from's.
> Remove the unnecessary braces.
I'm not sure I'd call that "From:" in the message body fixed (i.e., it
should have been the second one, not the first one; alternatively, it
would be fine to remove that From: line from the message body since the
one in the message header has a value matching that SOB).
> diff --git 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);
As noted in your reply to this, those debug prints should not be
removed.
As far as the change to offchannel_send_action_done() is concerned, I'm
not sure it is the correct thing to do in all cases. Why would we cancel
Action frame TX wait or remain-on-channel if the new frame is for the
same channel?
--
Jouni Malinen PGP id EFC895FA