On Thu, 2013-02-07 at 11:54 -0600, Seth Forshee wrote: > Scans currently work by stopping the netdev tx queues but leaving the > mac80211 queues active. This stops the flow of incoming packets while > still allowing mac80211 to transmit nullfunc and probe request frames to > facilitate scanning. However, the driver may try to wake the mac80211 > queues while in this state, which will also wake the netdev queues. > > To prevent this, add a new queue stop reason, > IEEE80211_QUEUE_STOP_REASON_OFFCHANNEL, to be used when stopping the tx > queues for off-channel operation. This prevents the netdev queues from > waking when a driver wakes the mac80211 queues. > > This also stops all frames from being transmitted, even those required > for scanning. To get around this, add a new offchan_tx_ok argument to > most of the tx interfaces. This flag can be set for frames which need to > be transmitted during off-channel operation, allowing off-channel frames > to be passed down to the driver if the queues have only been stopped for > off-channel. Add ieee80211_tx_skb_offchannel() for transmitting > off-channel frames with this flag set. I started wondering -- is there a reason to modify the entire TX path? Could we maybe bypass it instead and call the driver's TX op almost directly? The frames in question don't really need much TX handling, the only thing that might be relevant _could_ be rate control but even that I'd argue isn't really needed, just using rate_control_send_low() should be ok (by setting IEEE80211_TX_CTL_USE_MINRATE it will always return true). For the null data packets the sta pointer is also obvious, the AP station (BSSID) ... we don't need any of the extra monitor/whatever handling either. That might be simpler overall? johannes -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
