Ralink RT5572 based wireless adapter not working in AP mode in 5 GHz band with DFS

Question

Objective:

Get a CSL USB 2.0 WLAN adapter work in AP mode in the 5 GHz band, in a Linux-based system (in particular, Ubuntu 16.04.4 LTS, kernel 4.13). The USB adapter is based on a chipset from Ralink, namely RT5572, as per the output of the lsusb command:

(...)
Bus 001 Device 003: ID 148f:5572 Ralink Technology, Corp. RT5572 Wireless Adapter
(...)

Problem:

I've partially achieved my objective: I'm able to set the adapter as an AP in the 5 GHz band for channels 36, 38, ... up to 48, by setting the variable channel in the hostapd.conf file, as shown below.

interface=wlx24050f615114
driver=nl80211
ssid=nikola-tesla
hw_mode=a
ieee80211n=1
ht_capab=HT40+
channel=48
country_code=PT
macaddr_acl=0
auth_algs=1           # 1=wpa, 2=wep, 3=both
wpa=2                 # WPA2 only
wpa_key_mgmt=WPA-PSK  
rsn_pairwise=CCMP
wpa_passphrase=xxxxxxxxxx
ignore_broadcast_ssid=0
logger_syslog=-1
logger_syslog_level=0

However, 'higher' channels don't work. E.g., if I set channel=52 (or larger), the AP setup fails, with the following error messages from hostapd:

hostapd: wlx24050f615114: IEEE 802.11 Configured channel (52) not found from the channel list of current mode (2) IEEE 802.11a
hostapd: wlx24050f615114: IEEE 802.11 Hardware does not support configured channel

Note that none of the channels in the 'working' range requires radar detection (i.e., no DFS requirement), as shown by the output of iw list below.

Band 2:
    Bitrates (non-HT):
        * 6.0 Mbps
        * 9.0 Mbps
        * 12.0 Mbps
        * 18.0 Mbps
        * 24.0 Mbps
        * 36.0 Mbps
        * 48.0 Mbps
        * 54.0 Mbps
    Frequencies:
        * 5170 MHz [34] (disabled)
        * 5180 MHz [36] (20.0 dBm)
        * 5190 MHz [38] (20.0 dBm)
        * 5200 MHz [40] (20.0 dBm)
        * 5210 MHz [42] (20.0 dBm)
        * 5220 MHz [44] (20.0 dBm)
        * 5230 MHz [46] (20.0 dBm)
        * 5240 MHz [48] (20.0 dBm)
        * 5260 MHz [52] (20.0 dBm) (radar detection)
          DFS state: usable (for 15263 sec)
          DFS CAC time: 60000 ms
        * 5280 MHz [56] (20.0 dBm) (radar detection)
          DFS state: usable (for 15263 sec)
          DFS CAC time: 60000 ms
        * 5300 MHz [60] (20.0 dBm) (radar detection)
          DFS state: usable (for 15263 sec)
          DFS CAC time: 60000 ms
        * 5320 MHz [64] (20.0 dBm) (radar detection)
          DFS state: usable (for 15263 sec)
          DFS CAC time: 60000 ms

Questions:

• Why don't the 5 GHz channels requiring DFS work with this setup?

I have some suspicions, but no idea on how to follow up on them:

The DFS CAC (Channel Availability Check) time reported by iw reg get is 0 ms (shown below), while the value given by iw list is 60 sec (as shown above).

country PT: DFS-ETSI
    (2402 - 2482 @ 40), (N/A, 20), (N/A)
    (5170 - 5250 @ 80), (N/A, 20), (N/A)
    (5250 - 5330 @ 80), (N/A, 20), (0 ms), DFS
    (5490 - 5710 @ 160), (N/A, 27), (0 ms), DFS
    (57000 - 66000 @ 2160), (N/A, 40), (N/A)

Could this be why channels with DFS requirements don't work? My assumption here is that a max. allowed CAC time of 0 ms blocks every attempt for radar detection.

There may be further regulatory domain restrictions 'burned' into the device. I know this issue can happen with Atheros chipsets (e.g., regdomain set in firmware/EEPROM), and that there are workarounds for it (e.g., as in this example). However, I couldn't find a way to check if the same is happening with the RT5572. Is there a way to know if this is what's happening?

• Has anyone been able to get DFS channels to work with Ralink chipsets (e.g., the RT5572)?

Answer 1

I've found some further information which may answer my own question.

Only a few Linux wireless drivers support Dynamic Frequency Selection (DFS), namely 3: ath5k ath9k and ath10k. This feature is referred to as 'Automatic Channel Selection (ACS)' in other source.

I've confirmed this by inspecting the source code of wireless drivers in Linux, and noticed that only the ath* drivers implement methods such as ieee80211_radar_detected(). This may explain why hostapd can't set the channel to a value in the DFS range (52 to 140) when the RT5572 chipset is used (note: Linux uses the rt2800usb driver to work with the RT5572).