NanoPI R5S refusing to go in AP mode with both RTL8822CE and atk10k_pci

[tarastella]

Describe the bug

I've bought a NanoPI R5C using FriendlyWRT 22.03.4, based on the OpenWRT release (I switched repo to the official OpenWRT).
The stock R5C comes with an RTL8822CE card that, in my case, is "refusing" to go in AP mode.
I tried with a Qualcomm Atheros QCA6174, and I compiled the ath10k modules for the R5S, and I got the same behaviour.

The system is "refusing" to go into AP mode with both cards. The card gets stuck in unknown status, with something like this:

wlan0     ESSID: "OpenWrt"
          Access Point: E8:6F:38:3B:55:5F
          Mode: Master  Channel: 64 (5.320 GHz)  HT Mode: NOHT
          Center Channel 1: unknown 2: unknown
          Tx-Power: 0 dBm  Link Quality: unknown/70
          Signal: unknown  Noise: -100 dBm
          Bit Rate: unknown
          Encryption: none
          Type: nl80211  HW Mode(s): 802.11ac/b/g/n
          Hardware: 168C:003E 1028:364A [Generic MAC80211]
          TX power offset: unknown
          Frequency offset: unknown
          Supports VAPs: yes  PHY name: phy0

More info on the forum here:
https://forum.openwrt.org/t/rtl8822ce-refusing-to-go-in-ap-mode/161090/5

The card can scan the networks as a client, and iw is reporting (as above) the correct information about the card.
I don't know how to debug further.
Can you please help me debugging it?

P.S. I am aware it is a fork, but should be 1:1. FriendlyElec is referring to your bug system as per:
https://github.com/friendlyarm/friendlywrt

OpenWrt version

r20123-38ccc47687

OpenWrt target/subtarget

rockchip/armv8

Device

FriendlyElec NanoPI R5C

Image kind

Self-built image

Steps to reproduce

No response

Actual behaviour

No response

Expected behaviour

No response

Additional info

No response

Diffconfig

No response

Terms

• I am reporting an issue for OpenWrt, not an unsupported fork.

[brada4]

First install OpenWRT, then use logread to see ACS/DFS events. Channel 64 most likely needs radar detection everywhere.

[ynezz]

P.S. I am aware it is a fork, but should be 1:1. FriendlyElec is referring to your bug system as per:

@friendlyarm can you please kindly change that? Folks seems to be confused, thanks!

I am reporting an issue for OpenWrt, not an unsupported fork.

This is unsupported fork. So you've two options:

1. Start using OpenWrt as suggested in the forum post already
2. Close this issue

[tarastella]

@brada4 you are a lifesaver! with that logs from logread, I discovered that "No IR" actually meant "No Irradiate". So AFAIK, no transmission is allowed. As per the output of my post on the forum, you'll see that basically, no 5GHz frequency is available. So I switched to a 2.4GHz without any "No IR" flag and it worked.

I'm not happy about it and perhaps is linked to some firmware, but at least I know where to investigate. Worse case, I might disable the CRDA support from the Kernel. It's meant to be a small, portable, emergency VPN device for me. I did the test with ath10k, but I'll try the Realtek out of curiosity and understand if it was the case.

@ynezz I'll close the ticket

I'd appreciate it if @friendlyarm can open an issue tracking on their kernel and OpenWrt fork repo, so we can interact with them.

Thanks very much for your help.