OK, I will try this again - but to have a post flagged and removed without any right of appeal, nor any actual pointer to the bit that was thought unreasonable leaving me to guess, is pretty offensive and not the way to encourage participation in the forum.
If people thought discussing a diagnostic step was unreasonable I a) could have explained that it was just a diagnostic step, any precautions that I took and b) I would have happily edited the post if necessary.
I have the above card in an x86 mini PC and have been exploring how well it works as an AP in OpenWrt.
I was reasonably pleased to see that it does indeed work in AP mode once the drivers are installed – and in both 2.4Ghz and 5Ghz bands.
Except where radar detection is needed – in which case I get:
hostapd: DFS start_dfs_cac() failed, -1
Every time, no matter what channel and the AP is disabled.
If the channel is not marked for radar detection, everything works as anticipated.
I know sometimes Realtek devices don’t always work well so was wondering if this is a known/expected issue or a bug?
My PC Engines APU with an MT7915E works fine in the same environment so I do not think it is because there are actual radar signals in the vicinity - in any case the sequence of messages if there were would be different - it would report that the scan had started, then radar detected.
That certainly works, as same chip is used for both AP and client styled devices. You can run AP off your lucky laptop
hostapd error handling could wish better, if driver does not export DFS function it chokes on error and does not get to being access point.
Looking at the source code following support DFS (and none other)
drivers/net/wireless/realtek/rtw89/rtw8851b.c
drivers/net/wireless/realtek/rtw89/rtw8852a.c
drivers/net/wireless/realtek/rtw89/rtw8852c.c
drivers/net/wireless/realtek/rtw89/rtw8922a.c
I get that - but that isn’t what I want, nor was suggesting and I let the MT7915E scan that channel first. Mainly I just wanted to check the 8852 was capable of operating on the channel.
OK, is that a missing feature in the driver, or in the card?
Rules apply to every radio transmitter. You can check iw list after iw reg set DE to see available channels without activating transmissions. Most card firmwares allow changing country just once per power-on. ie reboot may not suffice.
Those drivers have the bits to call firmware DFS function, other drivers do not have that. No speculation about firmware or hardware functionality, probably respective datasheets are under NDA somewhere.
Thanks - yes I was aware of that. But ultimately it only tells you of the requirements for the currently set territory - when what would be more useful would be an indication along the lines of "Radar detection needed but not possible with this hardware".
It would not surprise me, about the NDA that is.
But it comes back to a comment that you made yourself - "hostapd error handling could wish better".
Ideally there would be some sort of message to say "needed feature not implemented" or, even better, for the list of available channels to be set to just the ones which can be supported with the current hardware/driver.