> >Anyway, you'd suggest to use the NL80211 remain on channel command for > >that? > > Yes. > > >Or add a new "spectral scan" nl80211 command to do a spectral scan on this > >(or multiple) channels, and use the various functions from > >mac80211/offchannel.c? > > I would rather add a flag to the existing r-o-c command to indicate that > spectral scan functionality is to be enabled (well, assuming Johannes is > fine with this). Ultimately I don't really care all that much whether it's ROC-like or SCAN-like, though it didn't seem like the timing mattered because all the data was just collected inside the callback while it was running, i.e. synchronously, and thus extended the scan timing? For ROC I guess an argument could be made that it could just be a flag, for SCAN I don't think so since none of the other scan functionality applies. As far as the implementation is concerned, I don't really care, but I do want to keep the userspace API clean. scan could be more efficient since it doesn't always go back to the same channel and can do multiple in a row, unlike ROC. > >BTW, is there any limitation to remain on channel commands, like will they > >work on AP ifaces, Ad-Hoc ifaces, MultiSSID in general, etc? > > I hope not. There may be some practical issues with not all drivers > supporting this, but remain-on-channel is the mechanism we use for > supporting concurrent operations (e.g., P2P negotiations or GAS/ANQP) and > making this work in all combinations would be important regardless. FWIW, right now our plan for iwlwifi is to only really support it with the P2P Device wdev, but I'm not sure what implications that has in terms of support for GAS/ANQP etc. We might have to revisit that. Maybe we should start advertising where it's supported so wpa_s/hostapd can disable/enable features appropriately? 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
