Hi,
There are 2 similar operations in the struct cfg80211_ops:
remain_on_channel() and mgmt_tx(). Actually, mgmt_tx() when called for
off-channel operation, is the same as remain_on_channel() except it
transmits frame at the beginning.
What I am interesting about, is notifications to cfg80211. For
remain_on_channel(), there are 2: cfg80211_ready_on_channel() when
channel tuned, and cfg80211_remain_on_channel_expired() when tuned off
requested channel. In contrast, if mgmt_tx() called for off-channel
with duration, 2 above notifications are not used. Instead, only
cfg80211_mgmt_tx_status() called after tx.
My question is why don't mgmt_tx() call cfg80211_ready_on_channel() and
cfg80211_remain_on_channel_expired() ? It seems logical to notify about
off-channel status. Otherwise, how can upper layers know when off-channel
started/finished in context of mgmt_tx()?
Comments?
Thanks, Vladimir
On Thu, 2013-01-10 at 10:43 +0200, Vladimir Kondratiev wrote:
> Hi,
>
> There are 2 similar operations in the struct cfg80211_ops:
> remain_on_channel() and mgmt_tx(). Actually, mgmt_tx() when called for
> off-channel operation, is the same as remain_on_channel() except it
> transmits frame at the beginning.
>
> What I am interesting about, is notifications to cfg80211. For
> remain_on_channel(), there are 2: cfg80211_ready_on_channel() when
> channel tuned, and cfg80211_remain_on_channel_expired() when tuned off
> requested channel. In contrast, if mgmt_tx() called for off-channel
> with duration, 2 above notifications are not used. Instead, only
> cfg80211_mgmt_tx_status() called after tx.
>
> My question is why don't mgmt_tx() call cfg80211_ready_on_channel() and
> cfg80211_remain_on_channel_expired() ? It seems logical to notify about
> off-channel status. Otherwise, how can upper layers know when off-channel
> started/finished in context of mgmt_tx()?
If all they care about is transmitting a frame, why would they want to
know?
johannes
On Saturday, January 26, 2013 12:16:13 AM Johannes Berg wrote:
> On Thu, 2013-01-10 at 10:43 +0200, Vladimir Kondratiev wrote:
> > Hi,
> >
> > There are 2 similar operations in the struct cfg80211_ops:
> > remain_on_channel() and mgmt_tx(). Actually, mgmt_tx() when called for
> > off-channel operation, is the same as remain_on_channel() except it
> > transmits frame at the beginning.
> >
> > What I am interesting about, is notifications to cfg80211. For
> > remain_on_channel(), there are 2: cfg80211_ready_on_channel() when
> > channel tuned, and cfg80211_remain_on_channel_expired() when tuned off
> > requested channel. In contrast, if mgmt_tx() called for off-channel
> > with duration, 2 above notifications are not used. Instead, only
> > cfg80211_mgmt_tx_status() called after tx.
> >
> > My question is why don't mgmt_tx() call cfg80211_ready_on_channel() and
> > cfg80211_remain_on_channel_expired() ? It seems logical to notify about
> > off-channel status. Otherwise, how can upper layers know when off-channel
> > started/finished in context of mgmt_tx()?
>
> If all they care about is transmitting a frame, why would they want to
> know?
>
> johannes
>
My understanding is that mgmt_tx() with delay intended for the flows
when one expect to rx some frame(s) solicited by original tx.
Ex: active scan - one tx probe and waits for probe resp on the same channel;
other example may be GO negotiation.
So, actually tx_mgmt() is like remain_on_channel() but with initial tx. That's
why it is strange to see different notification policy.
For practical example, let's see fragmented scan while connected -
upper layers issue mgmt_tx() for probe with delay about 10 ms; and use
start/end offchannel notification to pause/resume tx. Currently, one can't
do this; and need to call remain_on_channel() following mgmt_tx() upon
receiving cfg80211_ready_on_channel notification.