get RSSI from ASUS RT_AC86U router in monitor mode

[yujianyuanhaha]

greetings,

How can we get the RSSI on the ASUS router running nexmon tool?

I know there is a command wl rssi and wl noise that is straight forward. However, it only work for router in regular mode where one router is communication with the other.
While in our nexmon router is in monitor mode and do sniffering, which mean it does not connect to another router, so the command mention would not work ...

As we know the nexmon ease the RSSI, and current only get RSSI for Raspberry PI.

Is there any idea we can get that? @DanielAW @schmittner @jlinktu

Thanks

[mzakharo]

The RSSI patch you mention is not Raspberry PI specific, should work for ASUS too. Have you tried?

[yujianyuanhaha]

@mzakharo apparently that patch doesn't work for ASUS

[mzakharo]

got to elaborate, what do you mean 'does not work'. the line below is device-agnostic. If it does not work for you, it is a good starting point for you to debug yourself and to figure out why.

 wlc_phy_rssi_compute(wlc_hw->band->pi, wlc_rxhdr);
 last_rssi = wlc_rxhdr->rssi;

[Deltaaaaaaaaaa]

@mzakharo
Greetings,
I'm also trying to get RSSI along with CSI on AC86U, Thankyou for your instruction!
I've tried modifying the csi_extractor.c file, and received rssi value secussfully.
However, the extracted rssi values are always the same across the 4 antennas. It seems frames from different antennas in one measurement (one packet from tx) are reporting the rssi from one antenna.
I really wonder what is it like on Raspberry PI, did the same problem occured to you when getting rssi from different antennas?
I noticed in your commit on RPI, both the patch file (src/csi.ucode.bcm43455c0.7_45_189.patch) and the csi_extractor.c file were modified. How does the added line and [3,off1], 0xff, [4,off5] in the patch file work? How should i modify the patch file for AC86U (src/csi.ucode.bcm4366c0.10_10_122_20.patch) to make it report the rssi for each antenna?
Could you please give us a hint, sir?
Thankyou so much!

[mzakharo]

wlc_rxhdr->rssi is a computed value, derived from all 4 antennas-> the source code for wlc_phy_rssi_compute is available if you google for it. RPI-4 has only 1 antenna, so this is no problem. Now as far as getting separate RSSI for each antenna on ASUS, you have to dig those out yourself, they should be in there, part of phybits: b79d935 and a9d2a2f . Good luck!

[jlinktu]

You can use the attached patch to include received power per antenna on the bcm4366c0 in the corresponding CSI UDPs.
With the patch the ucode extracts the value of the correct antenna from the phystatus and appends it to the header that is passed to the arm core together with the CSI data. The arm core just receives and converts the value before inserting it as a int16 in the CSI UDP. Note that this adds another 2 bytes to the header in the CSI UDP before the actual CSI values.
This is roughly what wlc_phy_rssi_compute does but without combining the per antenna values. wlc_phy_rssi_compute actually might do more like additionally compensating temperature, applying per band offets etc. If the raw receive power extracted by the patch isn't fine enough for you and you are interested you can find the function called by wlc_phy_rssi_compute at 0x21c532.

add_rxpwr_extraction_bcm4366c0.patch.txt
Clone nexmon_csi as usual and apply with git apply add_rxpwr_extraction_bcm4366c0.patch.txt before compiling.

[yujianyuanhaha]

@jlinktu sounds make sense, thanks a lot

I follow your instruction and I do see there are two extra byte in the UDP packet, see figure below, left debug.pcap 1042byte is orginal setup, while right debug2.pcap 1044byte come from include RSSI setup.

However, this git apply does not include change to .c or .m codes under ./utils/matlab, I still have difficult read the extra byte RSSI from .pcap file. Could you kindly look into that as well? @jlinktu I believe it is tiny modification on the readpcap.m or unpack_float.c somewhere.

To be specific, the read the refined .pcap file with existing code will met bug at readpcap.m line 59, where we expect the int32 here.

Best.

Jet

[tweigel-dev]

@yujianyuanhaha I am writing a python script to extract CSI.
Currently this is only working with bcm43455c0 but i want to implement an patch for bcm4366c0.
https://github.com/tweigel-dev/nexmon_csi/tree/feature/python
look at utils/python

[zeroby0]

@tweigel-dev looks nice!

It would be faster and less memory hungry to load the entries into pandas tables than put them into classes (although I too am guilty of this XD).

My version of python csi explorer is here: https://github.com/zeroby0/csi-explorer. I implemented it in browser and terminal, feel free to take code from there :)

[tweigel-dev]

@zeroby0 thx ^^ I think it's great that we do the same things. we should share more to avoid double work ! 👍🏻
Did you also implemented a subscriber at port 5500 to sniff the output of nexutils with python? I want to do this in near future to pass the csi directly to plotting or some other algorythms.

[zeroby0]

@tweigel-dev Yess! I have implemented sniffing the port, and found ways for optimise it. The optimised version for reading pcap files is also done. I don't know if we can run python on the router though.

I'll create a github org and add you?

[tweigel-dev]

@zeroby0 sure !

[Gi-z]

@zeroby0 @tweigel-dev Hi, I've got some code doing some similar stuff here: https://github.com/Gi-z/CSIKit, as I've got some implementations I've been working on for sensing with the Pi. If you're pooling work together, I'd love to get involved.

[zeroby0]

Awesome! Let's do it!

@tweigel-dev @Gi-z can I have both of your emails? Mine is [email protected].

Sorry for spamming everyone in the thread 🙏

[yujianyuanhaha]

@jlinktu may I know how the extra 2 byte is presented for your solution?

I am nowing get a RSSI value of eb ff (overall it is stable, few times ea ff e0 ff), what does that stands for? Is it in format of 1st bit sign, 2th-10th real, 11th-16th for exp value? Or something else? I suppose the value is between [-100, 0]dBm