Re: [RFC 1/3] nl80211: add spec scan flag

[Simon Wunderlich <simon.wunderlich@s2003.tu-chemnitz.de>]

[-- Attachment #1: Type: text/plain, Size: 5231 bytes --]

On Wed, Nov 28, 2012 at 05:26:14PM +0100, Johannes Berg wrote:
> 
> > > > That "if supported" here is pretty problematic. There's no way to know.
> > > > Feature flag maybe?
> > 
> > Hmm, I could certainly add a WIPHY_FLAG for that.
> 
> nl80211 feature flag would be better
> 

OK, that would work too. Just that there are some Atheros Chips which don't
support spectral scan, like AR9160, but are supported by ath9k. I guess I'd
just set the feature if the chip revision is supported, from within ath9k.

> > > > Also, there are scan flags now. However, I don't see that this should
> > > > (ab)use the scan function. It doesn't seem likely that you want to do
> > > > this while you're sending probe requests, etc. OTOH, it seems likely
> > > > you'd want identical dwell times on all channels to have comparable
> > > > values, which isn't the case here.
> > 
> > The times are not a big problem - at least for now, the spectral scan
> > is only done for a very short time [tm] when the channel is changed.
> > 
> > The main reason why I wanted to use this function is that it can be used
> > while operation, that is sending power save, forbidding payload tx, etc.
> 
> That's not an argument for using the scan API. That might be an argument
> for piggy-backing on the scan *implementation*, but that's an orthogonal
> issue. Note how I didn't comment on patch 2 -- I do think piggy-backing
> on the scan implementation would be acceptable.

OK

> 
> > > So bottom line is that I think there are two choices:
> > > 1) for a proof of concept, implement it in debugfs only, in ath9k only,
> > >    with e.g. a debugfs file that sets a flag that then triggers the
> > >    spectral scan when you do a scan (using sw_scan_start, config hooks)
> > >    --> no need to modify nl80211 at all
> > 
> > So the idea is something like:
> >  * open debugfs-file (e.g. with cat)
> >  * start scan "normally", without any flags
> >  * read debugfs results, and close it
> > 
> > Mhm, this is definitely possible, although not too beautiful as well. :)
> > 
> > It seems there is no way to trigger a scan from within ath9k/debugfs, right?
> 
> No.
> 
> > sw_scan_start() is currently undefined in ath9k, but we could add that.
> > By "config hooks" you mean the general config driver call to set the channel
> > etc?
> 
> I meant to trigger the data collection there.
> 
> > I could also cycle channels within ath9k, but the main problem I see is that
> > I can't turn off TX/go into power save mode from the driver, or would you see
> > anything feasible? 
> 
> Triggering it all from the driver doesn't seem possible, no. You could
> have the function take effect on the next scan, but it's still kinda
> hybrid. However, it wouldn't "pollute" nl80211 that way.
> 

OK, so it could look like:

echo start > debugfs/ath9k/spectral_scan
iw dev wlan0 scan
cat debugfs/ath9k/spectral_scan
[... get output ...]
echo stop > debugfs/ath9k/spectral_scan

yeah, that's still hybrid, but still simple.

> > > 2) implement some well-defined API in nl80211, but don't tie it to
> > >    scanning or a debugfs implementation of getting the data out, with
> > >    versioning of the FFT data packets etc. so it can be updated later
> > >    without breaking everything
> > 
> > I guess if we implement this in iw, this would be done similarly to scan,
> > e.g. trigger the scan and wait on the socket for results? Or would we
> > use events instead?
> > 
> > This would roughly mean:
> >  * duplicate the mac80211 scan part for spectral scan to cycle channels/be quite
> >    while doing this
> 
> No, I didn't say this. I said the API should be different, the
> implementation in mac80211 could very well just be "either going to send
> probes & wait, or collect spectral scan data and continue to the next
> channel"
> 
> >  * duplicate iw scan (at least some parts), the interface could look very similar:
> >    trigger scan, on receive scan results on another socket, wait for completion
> >    (although iw still has this "warning, it's racy" thing inside. :] )
> 
> Actually you need a separate application anyway, to interpret the
> results, so that application would
>  * open a socket
>  * send the spectral scan command
>  * read the results on the socket

Ah OK, so we would have a new nl80211 spectral scan command which then calls
the mac80211/scan stuff, but with special flags which the normal scan wouldn't
do. It could then return the results, and the current scan command wouldn't be
harmed. I hope I got this right? :)

Also, putting all this into iw to dump the raw data would be feasible, no?
Right now I'm dumping the data on some AP, but display it on another computer
(with a screen :] ), so this intermediate step is needed anyways.

Actually, the ath9k-only way seems to be faster for now. I'm not sure about
the data interpretation (offset/exponents etc), and I'd like to have
this confirmed/corrected before exporting results via nl80211 - I don't want
to change the data format all the time. Maybe some ath9k fellow can comment
on that, or if they like the debugfs-only idea. :)

Thanks again,
	Simon

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]