respondd provider for cfg80211 DFS state

[mweinelt]

It is currently unclear how well the DFS stack currently used in OpenWrt and Linux in general performs, especially with different radio drivers, that each have to reimplement the pulse pattern detection, so the general idea is to collect data to compare different radios and locations, to eventually see the area in which a DFS event took place and check if the devices back each others claims..

Testing could be done with an SDR and https://github.com/TobleMiner/dfs-pulse-tester, if @TobleMiner can confirm it works for that purpose.

cfg80211 can be queried via nl80211 and offers the following state:

• NL80211_FREQUENCY_ATTR_DFS_STATE is one of usable, available, unavailable, unknown
• NL80211_FREQUENCY_ATTR_DFS_TIME holds the time, that a channel is in the above state

So the proposed format would be a list of channels containing their respective state and the time they've been in that state.

Basically:

• loop over all channels
  • drop NL80211_FREQUENCY_ATTR_DISABLED
  • drop NL80211_FREQUENCY_ATTR_INDOOR_ONLY
  • report state and time

{
  "wireless": {
    "dfs": {
      "100": {"state": "available", "for": "35580"},
      "104": {"state": "usable", "for": "35769"},
      ...
    }
  }
}

[genofire]

That will cost a lot of space in json for every possible channel :(
But it would work

[Adorfer]

@genofire you suggest a table in the other direction? like
"available" and then a list of for channels, plus the same for "usable"?

[mweinelt]

We are talking about roughly 15 channels, like so:

{
  "dfs": {
    "52": {"state": "usable", "for": "13923"},
    "56": {"state": "usable", "for": "13923"},
    "60": {"state": "usable", "for": "13923"},
    "64": {"state": "usable", "for": "13923"},
    "100": {"state": "usable", "for": "13923"},
    "104": {"state": "usable", "for": "13923"},
    "108": {"state": "usable", "for": "13923"},
    "112": {"state": "usable", "for": "13923"},
    "116": {"state": "usable", "for": "13923"},
    "120": {"state": "usable", "for": "13923"},
    "124": {"state": "usable", "for": "13923"},
    "128": {"state": "usable", "for": "13923"},
    "132": {"state": "usable", "for": "13923"},
    "136": {"state": "usable", "for": "13923"},
    "140": {"state": "usable", "for": "13923"} ,
  }
}

saved to disk that is ~750 Byte and 147 Byte after gzip.

[TobleMiner]

@mweinelt The ETSI flowgraph at https://github.com/TobleMiner/dfs-pulse-tester implements some of the ETSI DFS testpatterns thus it should be fit for limited DFS testing. I might try adding the missing modulated radar signal in the near future though.

There are a few more regulatory requirements associated wit DFS that are harder to test though. Starting at page 10 https://mentor.ieee.org/802.11/dcn/09/11-09-1217-00-0reg-dfs-criteria-whitepaper.pdf details them quite well. Especially parameters like Channel Closing Transmission time need to be monitored closely.

[mweinelt]

@TobleMiner I had no luck triggering NOP states on Archer C7 v4 (ath10k) and UAP-AC Lite (stock Firmware), I only had a rad1o without a proper antenna, only a wire attached. I'll probably have to get another SDR device before continuing.

Edit: Well, one should check the frequency range of the SDR before such an undertaking, as the rad1o can only go up to roughly 4 GHz per design.

[TobleMiner]

@mweinelt I should have mentioned the SDR used. I'm using a HackRF One with a small 5 GHz WiFi antenna.