HLK-7928N Monitor Mode Support?

Hey everyone! So I've spent an entire day or so on a problem, and I've ended up grasping at straws. So I figured it was time to throw the towel in and ask the geniuses about it (you people). :grinning:

So recently as part of a development project, I brought an HLK-7928N module and the company's development board, the HLK-RM08A-KIT-V2.5 for its easy soldering and OpenWRT support. What I really needed from it was monitor mode from its main processor and wifi receiver, the MT7628. I upgraded the firmware to its latest supported firmware, v23.05.3, and ran the command: "iw phy phy0 interface add mon0 type monitor" which was completed successfully. Then I run "tcpdump -I -i mon0" which says that monitor mode is not supported. When I try to activate monitor mode again, using "airmon-ng check kill" and then "airmon-ng start mon0", it kills the interfering processes but when running start the processes are back with a different PID and the same result with tcpdump.
Pls help!

Let me know if more info is needed.
Thanks for any advice, UnknownBot

PS: iw reports that monitor mode is supported so it should be right?

Option -I is not supported, but you do not need it because you have already created a monitor interface.

tcpdump -i mon0 should be enough.

Thank you for responding!
I have tried before without the -I option, but then the kernel reports the device entering promiscuous mode everytime it is used.

root@OpenWrt:/# iw phy phy0 interface add mon0 type monitor
root@OpenWrt:/# iw dev
        Interface mon0
                ifindex 8
                wdev 0x2
                addr 40:d6:3c:81:65:35
                type monitor
                txpower 25.00 dBm
root@OpenWrt:/# ifconfig mon0 up
root@OpenWrt:/# tcpdump -i mon0
[  277.981663] device mon0 entered promiscuous mode
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on mon0, link-type IEEE802_11_RADIO (802.11 plus radiotap header), snapshot length 262144 bytes
03:33:28.658880 266902218us tsft 1.0 Mb/s 2412 MHz 11b -93dBm signal [bit 22] Probe Request () [1.0* 2.0* 5.5* 11.0* 9.0 18.0 36.0 54.0 Mbit]
03:33:29.658831 267902168us tsft 1.0 Mb/s 2412 MHz 11b -94dBm signal [bit 22] Probe Request () [1.0* 2.0* 5.5* 11.0* 9.0 18.0 36.0 54.0 Mbit]
2 packets captur[  284.984564] device mon0 left promiscuous mode
2 packets received by filter
0 packets dropped by kernel

The -p option will prevent this.

Ah! Perfect! I'm surprised that they don't document that in the command line options. It works; though for some reason it's only capturing control packets (QoS Data, Beacons, RTS, CTS) and no data frames, which I REALLY need. Is there something else I'm supposed to do to get data frames?
(Am I supposed to create a new question in the forum? The forum was never clear on this)