* ROC event when CMD_FRAME duration expires
@ 2019-06-11 20:51 James Prestwood
2019-06-12 19:11 ` Johannes Berg
0 siblings, 1 reply; 4+ messages in thread
From: James Prestwood @ 2019-06-11 20:51 UTC (permalink / raw)
To: linux-wireless
Hi,
I see that the event CMD_CANCEL_REMAIN_ON_CHANNEL is emitted when a
CMD_REMAIN_ON_CHANNEL duration expires, but this is not true for
CMD_FRAME when sending offchannel and providing a duration. I see
wpa_supplicant handles this with its own timeout, but couldn't the same
event be emitted for CMD_FRAME if the duration expires?
Looking in mac80211/offchannel.c: ieee80211_roc_notify_destroy:
if (!roc->mgmt_tx_cookie)
cfg80211_remain_on_channel_expired(&roc->sdata->wdev,
roc->cookie, roc->chan,
GFP_KERNEL);
In the case of CMD_FRAME, mgmt_tx_cookie is set, so this event does not
get emitted. Could the same expire event be emitted when mgmt_tx_cookie
is set as well? This would eliminate the need for userspace to keep a
timeout tracking this.
If this is ok I can send a patch (Looks like all I would need to do is
remove the if, and include the correct cookie, roc->cookie or roc-
>mgmt_tx_cookie).
Thanks,
James
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: ROC event when CMD_FRAME duration expires
2019-06-11 20:51 ROC event when CMD_FRAME duration expires James Prestwood
@ 2019-06-12 19:11 ` Johannes Berg
2019-06-12 19:18 ` James Prestwood
0 siblings, 1 reply; 4+ messages in thread
From: Johannes Berg @ 2019-06-12 19:11 UTC (permalink / raw)
To: James Prestwood, linux-wireless
On Tue, 2019-06-11 at 13:51 -0700, James Prestwood wrote:
> Hi,
>
> I see that the event CMD_CANCEL_REMAIN_ON_CHANNEL is emitted when a
> CMD_REMAIN_ON_CHANNEL duration expires, but this is not true for
> CMD_FRAME when sending offchannel and providing a duration. I see
> wpa_supplicant handles this with its own timeout, but couldn't the same
> event be emitted for CMD_FRAME if the duration expires?
I guess? I guess this is for a case where you actually have a wait after
the TX, for waiting for a response?
johannes
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: ROC event when CMD_FRAME duration expires
2019-06-12 19:11 ` Johannes Berg
@ 2019-06-12 19:18 ` James Prestwood
2019-06-12 19:31 ` Johannes Berg
0 siblings, 1 reply; 4+ messages in thread
From: James Prestwood @ 2019-06-12 19:18 UTC (permalink / raw)
To: Johannes Berg, linux-wireless
On Wed, 2019-06-12 at 21:11 +0200, Johannes Berg wrote:
> On Tue, 2019-06-11 at 13:51 -0700, James Prestwood wrote:
> > Hi,
> >
> > I see that the event CMD_CANCEL_REMAIN_ON_CHANNEL is emitted when a
> > CMD_REMAIN_ON_CHANNEL duration expires, but this is not true for
> > CMD_FRAME when sending offchannel and providing a duration. I see
> > wpa_supplicant handles this with its own timeout, but couldn't the
> > same
> > event be emitted for CMD_FRAME if the duration expires?
>
> I guess? I guess this is for a case where you actually have a wait
> after
> the TX, for waiting for a response?
Yes exactly. For example a GAS/ANQP request before association to some
offchannel AP (that's at least our use case).
Thanks,
James
>
> johannes
>
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: ROC event when CMD_FRAME duration expires
2019-06-12 19:18 ` James Prestwood
@ 2019-06-12 19:31 ` Johannes Berg
0 siblings, 0 replies; 4+ messages in thread
From: Johannes Berg @ 2019-06-12 19:31 UTC (permalink / raw)
To: James Prestwood, linux-wireless
On Wed, 2019-06-12 at 12:18 -0700, James Prestwood wrote:
> On Wed, 2019-06-12 at 21:11 +0200, Johannes Berg wrote:
> > On Tue, 2019-06-11 at 13:51 -0700, James Prestwood wrote:
> > > Hi,
> > >
> > > I see that the event CMD_CANCEL_REMAIN_ON_CHANNEL is emitted when a
> > > CMD_REMAIN_ON_CHANNEL duration expires, but this is not true for
> > > CMD_FRAME when sending offchannel and providing a duration. I see
> > > wpa_supplicant handles this with its own timeout, but couldn't the
> > > same
> > > event be emitted for CMD_FRAME if the duration expires?
> >
> > I guess? I guess this is for a case where you actually have a wait
> > after
> > the TX, for waiting for a response?
>
> Yes exactly. For example a GAS/ANQP request before association to some
> offchannel AP (that's at least our use case).
Makes sense, I guess. Send a patch? Seems easy enough.
johannes
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2019-06-12 19:31 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2019-06-11 20:51 ROC event when CMD_FRAME duration expires James Prestwood
2019-06-12 19:11 ` Johannes Berg
2019-06-12 19:18 ` James Prestwood
2019-06-12 19:31 ` Johannes Berg
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox