Add spectral scan support for Atheros AR92xx/AR93xx

This flag indicates that a spectrum scan is requested, if supported.

Quoted 1 line · Simon Wunderlich

This flag indicates that a spectrum scan is requested, if supported.

That "if supported" here is pretty problematic. There's no way to know. Feature flag maybe?

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.

I really think you need to decouple the API for this from scanning.

Quoted 5 lines · Johannes Berg

Quoted 1 line · Simon Wunderlich

This flag indicates that a spectrum scan is requested, if supported.

That "if supported" here is pretty problematic. There's no way to know. Feature flag maybe?

Quoted 6 lines

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.

Quoted 2 lines

I really think you need to decouple the API for this from scanning.

And then you can also define APIs to get the data out. While I realize that the data is implementation-dependent, you could have an enum that indicates the data format and describes it:

@NL80211_SPECTRAL_DATA_ATHEROS: u8 rssi,ext_rssi,noise,fft_data[] ...

enum nl80211_spectral_data {
	NL80211_SPECTRAL_DATA_ATHEROS,
	...
};

Then you can define a function to send the data to the userspace socket that asked for it (yes, if you have a separate command you can send it only to that app... wohoo! :P ) and don't even have to store it in the kernel...

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

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

This hybrid isn't a good approach at all.

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.

It seems there is no way to trigger a scan from within ath9k/debugfs, right?

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?

Quoted 2 lines · Simon Wunderlich

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.

Have you looked at the remain-on-channel commands?

Quoted 2 lines

It seems there is no way to trigger a scan from within ath9k/debugfs, right?

I don't think there is nor that there should be.. Do you really need scan operating for this? I would use remain-on-channel commands from a user space app to go through the channels you want to analyze.

Quoted 5 lines

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?

Remain-on-channel should take care of that, but yes, that would not be triggered from ath9k, but from user space.

Hmm, that would be possible as well ... Using the scan function is very convenient as I don't have to think about cycling, channel lists, etc. But putting more control to userspace is also possible, if we can ask the driver to just have a "quick spectral peek" on another channel.

Anyway, you'd suggest to use the NL80211 remain on channel command for that?

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?

BTW, is there any limitation to remain on channel commands, like will they work on AP ifaces, Ad-Hoc ifaces, MultiSSID in general, etc?

Quoted 3 lines

Anyway, you'd suggest to use the NL80211 remain on channel command for that?

Yes.

Quoted 3 lines

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).

Quoted 2 lines

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.

Quoted 9 lines

Quoted 3 lines

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?

Quoted 3 lines

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.

GAS/ANQP is pre-association if that makes any difference. Anyway, quite a few new things will start depending on off channel Action frames and everything I'm working on this area will most likely be using r-o-c..

Quoted 2 lines

Maybe we should start advertising where it's supported so wpa_s/hostapd can disable/enable features appropriately?

Yeah, sounds reasonable. I guess you could also reject the r-o-c command, but it is cleaner if this can be determined beforehand.

Quoted 3 lines

Quoted 3 lines

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.

Quoted 5 lines

Quoted 5 lines

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.

Quoted 5 lines

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?

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 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?

Quoted 4 lines

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

* 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. :] )

Quoted 5 lines

Quoted 3 lines

Quoted 3 lines

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

Quoted 9 lines

Quoted 5 lines

Quoted 5 lines

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.

Quoted 2 lines

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.

Quoted 7 lines

Quoted 6 lines

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

Quoted 8 lines

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.

Quoted 3 lines

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.

Quoted 3 lines

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.

Quoted 5 lines

Quoted 4 lines

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

Quoted 7 lines

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"

Quoted 3 lines

* 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

drivers/net/wireless/ath/ath9k/ar9002_phy.c +26 -0

+void ar9002_hw_spectral_scan(struct ath_hw *ah)
+{
+       struct ath_common *common = ath9k_hw_common(ah);
+
+       REG_SET_BIT(ah, AR_PHY_RADAR_0, AR_PHY_RADAR_0_FFT_ENA);
+
+       /* NOTE: this will generate a few samples ... lacking documentation,
+        * I'm not really sure what these parameters mean.
+        */
+       REG_SET_BIT(ah, AR_PHY_SPECTRAL_SCAN, AR_PHY_SPECTRAL_SCAN_ENABLE);
+       REG_SET_BIT(ah, AR_PHY_SPECTRAL_SCAN,
+                   AR_PHY_SPECTRAL_SCAN_SHORT_REPEAT);
+       REG_RMW_FIELD(ah, AR_PHY_SPECTRAL_SCAN,
+                     AR_PHY_SPECTRAL_SCAN_COUNT, 8);
+       REG_RMW_FIELD(ah, AR_PHY_SPECTRAL_SCAN,
+                     AR_PHY_SPECTRAL_SCAN_PERIOD, 0xF);
+       REG_RMW_FIELD(ah, AR_PHY_SPECTRAL_SCAN,
+                     AR_PHY_SPECTRAL_SCAN_FFT_PERIOD, 0xFF);
+
+       /* Activate spectral scan */
+       REG_SET_BIT(ah, AR_PHY_SPECTRAL_SCAN,
+                   AR_PHY_SPECTRAL_SCAN_ACTIVE);
+
+       /* Poll for spectral scan complete */
+       if (!ath9k_hw_wait(ah, AR_PHY_SPECTRAL_SCAN,
+                          AR_PHY_SPECTRAL_SCAN_ACTIVE,

Not that I'm specifically getting into this in any deep way right now, but..

On 27 November 2012 11:01, Simon Wunderlich
<[email protected]> wrote:

[snip] - this should apply to AR9380 and later I think.

Quoted 26 lines

drivers/net/wireless/ath/ath9k/ar9002_phy.c +26 -0

+void ar9002_hw_spectral_scan(struct ath_hw *ah)
+{
+       struct ath_common *common = ath9k_hw_common(ah);
+
+       REG_SET_BIT(ah, AR_PHY_RADAR_0, AR_PHY_RADAR_0_FFT_ENA);
+
+       /* NOTE: this will generate a few samples ... lacking documentation,
+        * I'm not really sure what these parameters mean.
+        */
+       REG_SET_BIT(ah, AR_PHY_SPECTRAL_SCAN, AR_PHY_SPECTRAL_SCAN_ENABLE);
+       REG_SET_BIT(ah, AR_PHY_SPECTRAL_SCAN,
+                   AR_PHY_SPECTRAL_SCAN_SHORT_REPEAT);
+       REG_RMW_FIELD(ah, AR_PHY_SPECTRAL_SCAN,
+                     AR_PHY_SPECTRAL_SCAN_COUNT, 8);
+       REG_RMW_FIELD(ah, AR_PHY_SPECTRAL_SCAN,
+                     AR_PHY_SPECTRAL_SCAN_PERIOD, 0xF);
+       REG_RMW_FIELD(ah, AR_PHY_SPECTRAL_SCAN,
+                     AR_PHY_SPECTRAL_SCAN_FFT_PERIOD, 0xFF);
+
+       /* Activate spectral scan */
+       REG_SET_BIT(ah, AR_PHY_SPECTRAL_SCAN,
+                   AR_PHY_SPECTRAL_SCAN_ACTIVE);
+
+       /* Poll for spectral scan complete */
+       if (!ath9k_hw_wait(ah, AR_PHY_SPECTRAL_SCAN,
+                          AR_PHY_SPECTRAL_SCAN_ACTIVE,

drivers/net/wireless/ath/ath9k/ar9002_phy.c static void ar9002_hw_antdiv_comb_conf_set(struct ath_hw *ah, · line 593

Quoted 10 lines

drivers/net/wireless/ath/ath9k/ar9002_phy.c +10 -0

+                          0, AH_WAIT_TIMEOUT)) {
+               ath_err(common, "spectral scan wait failed\n");
+               return;
+       }
+
+       /* Disable spectral scan */
+       REG_CLR_BIT(ah, AR_PHY_SPECTRAL_SCAN,
+                   AR_PHY_SPECTRAL_SCAN_ENABLE);
+}
+

You shouldn't have to do this. There's two spectral scan modes (well, three) -

* when you're not decoding things, and you meet these parameters, please send me some events (I think the patent mentions this);
* trigger _now_ and send me "X" events; then clear the spectral scan bit;
* trigger _now_ and just send me infinite events - on earlier chips (AR9280 I think) the magic value may be 0; on the later values it may be 255. Someone should experiment.

I suggest you separate out "configure/enable/disable" and "trigger" as options.

Grr, mumble mumble open source developers mumble mumble.. :-)

I suggest experimenting around with those particular parameters. You should be able to coax out specific numbers of spectral scan events when you set the COUNT parameter to something other than 8. But polling that bit isn't needed. It should be asynchronous.

Good luck,

Adrian

Quoted 4 lines

I suggest experimenting around with those particular parameters. You should be able to coax out specific numbers of spectral scan events when you set the COUNT parameter to something other than 8. But polling that bit isn't needed. It should be asynchronous.

As I said, on AR9220 it appears I get 8 samples when doing setting AR_PHY_SPECTRAL_SCAN_COUNT to 8 (plus maybe some other "stuff"/non-samples). On AR9380 I'm not so sure. Probably need to play with it a little more. Also, I don't know what "SHORT REPEAT" is supposed to mean, etc.

About polling, you mean the SCAN_ACTIVE bit? It is probably only needed when I want to trigger for few samples and want to be informed when it's finished - which is a good thing when doing spectral scan (change channel, start and wait for samples, change again). But we probably don't need to wait for the "background spectral scanning" mode, that's right. If someone wants to implement detection for interfering radio users, that mode would be useful. I don't need it, but can prepare the neccesary functions.

So I'd repost then:
* ath9k/debugfs only patch for now, as Johannes suggested - I think we should concentrate on this for now (their are still a lot of open questions in my initial mail regarding sample interpretation etc)
* split commands into enable/disable/configure/trigger
* maybe add some defines for magic values (if I find any)

I'd like this patchset to make the graphical spectral scan possible (as a Ubiquiti Airview), and give others the opportunity to add own features (pattern matching etc) on top of it. However I (currently) don't plan to do the latter myself.

How about using relay (Documentation/filesystems/relay.txt) to stream sample data to user space via the debugfs file?
That way you don't have to keep a linked list of small struct fft_sample buffers in the kernel and you can stream much more data efficiently with little kernel side overhead.
It also makes pushing the streaming data to a network socket via sendfile much more efficient.

This patchset is a first request for comments for the upcoming spectral scan feature. It adds a new attribute to nl80211 to ask for a spectral scan while scanning, because we cycle through the channels anyway at this time. If enabled by the driver, spectral scan results will be collected. This feature has been enabled for AR92xx and AR93xx based chipsets. As the FFT samples are very hardware dependent, they are only provided via a debugfs file for further evaluation.

[3] http://www.wehavemorefun.de/fritzbox/Ath_spectral.ko#Symbole

Quoted 8 lines · Simon Wunderlich

This patchset is a first request for comments for the upcoming spectral scan feature. It adds a new attribute to nl80211 to ask for a spectral scan while scanning, because we cycle through the channels anyway at this time. If enabled by the driver, spectral scan results will be collected. This feature has been enabled for AR92xx and AR93xx based chipsets. As the FFT samples are very hardware dependent, they are only provided via a debugfs file for further evaluation.

Quoted 1 line

[3] http://www.wehavemorefun.de/fritzbox/Ath_spectral.ko#Symbole

Erm. Just a quick question, since you mentioned this fritzbox ath_spectral.ko module... Is your "work" based or related to it, i.e.: did you peek at the assembler listings of it, or did someone else write a spec. and you just implemented it?

[...]

The goal of this was to create the spectral scan feature based on public information, so the results are probably not optimal yet, but I hope that this will help to move Qualcomm/Atheros disclosing some information (this seems to be planned anyway[2]). Otherwise, maybe other people can help reverse-engineering this. :)

Quoted 7 lines · Simon Wunderlich

[...]

The goal of this was to create the spectral scan feature based on public information, so the results are probably not optimal yet, but I hope that this will help to move Qualcomm/Atheros disclosing some information (this seems to be planned anyway[2]). Otherwise, maybe other people can help reverse-engineering this. :)

Just to clarify: I don't mean anyone should disassemble proprietary object files or use proprietary source code and re-use these findings without permission to create this feature - this would probably be illegal anyway.

By reverse-engineering, I mean we can already dump data spectral scan data with this patchset, but the hard part is to interpret this data correctly - as you'll find in the patches, there are a lot of bits which we don't know what they mean, and maybe there is even more info hidden in these bits. I've uploaded some samples taken on my hardware to the github repo, so anyone can use my program, matlab, or just stare at these heaps of bytes to find some patterns and try to interpret it. Actually I was just staring at the bytes myself and wrote this visualizer to get a better idea what they could mean.

Of course, if we can some docs or support from QCA officially, this would be even better. :)

Cheers,
Simon

Hi Simon,

Quoted 24 lines · Simon Wunderlich

Quoted 7 lines · Simon Wunderlich

[...]

The goal of this was to create the spectral scan feature based on public information, so the results are probably not optimal yet, but I hope that this will help to move Qualcomm/Atheros disclosing some information (this seems to be planned anyway[2]). Otherwise, maybe other people can help reverse-engineering this. :)

Just to clarify: I don't mean anyone should disassemble proprietary object files or use proprietary source code and re-use these findings without permission to create this feature - this would probably be illegal anyway.

By reverse-engineering, I mean we can already dump data spectral scan data with this patchset, but the hard part is to interpret this data correctly - as you'll find in the patches, there are a lot of bits which we don't know what they mean, and maybe there is even more info hidden in these bits. I've uploaded some samples taken on my hardware to the github repo, so anyone can use my program, matlab, or just stare at these heaps of bytes to find some patterns and try to interpret it. Actually I was just staring at the bytes myself and wrote this visualizer to get a better idea what they could mean.

Of course, if we can some docs or support from QCA officially, this would be even better. :)

Quoted 2 lines

Cheers,
Simon

A search brought me to their patent application. The Drawings on their patent application contain some more information on the signal classifications. Hopefully this will be able to help you or someone else.

http://www.google.com/patents/US7929508