Linux wireless drivers development
 help / color / mirror / Atom feed
* Q: offchannel operations
@ 2013-01-10  8:43 Vladimir Kondratiev
  2013-01-25 23:16 ` Johannes Berg
  0 siblings, 1 reply; 3+ messages in thread
From: Vladimir Kondratiev @ 2013-01-10  8:43 UTC (permalink / raw)
  To: linux-wireless

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

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: Q: offchannel operations
  2013-01-10  8:43 Q: offchannel operations Vladimir Kondratiev
@ 2013-01-25 23:16 ` Johannes Berg
  2013-01-28  8:02   ` Vladimir Kondratiev
  0 siblings, 1 reply; 3+ messages in thread
From: Johannes Berg @ 2013-01-25 23:16 UTC (permalink / raw)
  To: Vladimir Kondratiev; +Cc: linux-wireless

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


^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: Q: offchannel operations
  2013-01-25 23:16 ` Johannes Berg
@ 2013-01-28  8:02   ` Vladimir Kondratiev
  0 siblings, 0 replies; 3+ messages in thread
From: Vladimir Kondratiev @ 2013-01-28  8:02 UTC (permalink / raw)
  To: Johannes Berg; +Cc: linux-wireless

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.


^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2013-01-28  8:02 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2013-01-10  8:43 Q: offchannel operations Vladimir Kondratiev
2013-01-25 23:16 ` Johannes Berg
2013-01-28  8:02   ` Vladimir Kondratiev

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox