bcm4366c0 CSI extraction on 2.4GHz

[ghost]

Hi,

I'm trying to extract CSI with the Wi-Fi router Asus AC-RT86U using firmware patch bcm4366c0.

Currently it works very well on 5GHz channel. But for 2.4GHz band, it seems CSI can only be extracted from certain type of Wi-Fi frames (e.g. probing request). Usually I use ping to trigger CSI extraction with data frames, but it cannot work on 5GHz channel.

I think 2.4GHz channel is important because signal attenuates less quickly than it's on 5GHz channel, so 2.4GHz usually offers larger coverage.

Is there anyway that I can make CSI extraction with any type of Wi-Fi frames (or with data frames triggered by Ping) on 2.4GHz band?

Expecting any suggestions! Many thanks.

[mzakharo]

It works at 2.4GHz, just have to use compatible AP. Any LEDE/Openwrt router with .b support disabled will work to get beacons. As for ping/data -> that again, depends on AP. firmware does not extract CSI from data packets directly, but rather from extra managmenet frames that are sent along with data as part of 802.11 standard. at 2.4GHz, some APS do not send this as often as they do in 5Ghz. Triggering these extra management frames is AP configuration/firmare dependent, as well as ping payload size dependent.

[ghost]

Many thanks! @mzakharo But still some questions following your answer.

Any LEDE/Openwrt router with .b support disabled will work to get beacons.

I am currently using an AP operating on LEDE. But could you explain a bit more on ".b support", is there a full name of ".b support"? I'm actually not very familiar with LEDE.

but rather from extra managmenet frames that are sent along with data as part of 802.11 standard

Actually I'm more inclined to extracted CSI with the packets sent by client device. So can you please be more specific on the type of management frames?

Triggering these extra management frames is AP configuration/firmare dependent, as well as ping payload size dependent.

I'll try ping with different payload size later. Can you please share some more experience on what configuration on AP that I can try, or perhaps which firmware version worked for you?

[mzakharo]

GUI: advanced settings, WIFI. disable 802.11b support. command line: https://openwrt.org/docs/guide-user/network/wifi/basic

[ghost]

Got it. Thanks a lot @mzakharo

[ghost]

I tried disable 802.11b rates with Luci, but it seems still cannot obtain CSI from beacon. Ping with long payload size (15000 bytes) fails, either.

I did some study on which types of the management frame work well with CSI extraction on 2.4GHz by using wireshark to sniff the Wi-Fi traffic, I found that: 1) CSI can be captured when my smartphone gets association/de-association, during which the captured management frame types are:

• Authentication

• Association request

• Deassociation

• Action 2) I also compared the traffic caused by Ping for 2.4GHz and 5GHz. I find that for 2.4GHz, there will be an ACK response after every Ping data frame. But for 5GHz, the ACK becomes block-ACK, which should work as a reply for A-MPDU. Because I can obtain CSI with Ping on 5GHz but not on 2.4GHz, I think block-ACK should be the cause.

I think I'll look into why block-ACK is not triggered on 2.4GHz. Expecting any comments or suggestions!

[mzakharo]

you should be getting beacons if your AP is configured correctly. I had no problem getting beacons from https://www.gl-inet.com/products/gl-ar300m/ with offical/stock (LEDE-based) firmware. TL-WDR4300 is also confirmed working @ 2.4GHz (with LEDE). This with RPI-4 as CSI monitor.

[jlinktu]

It works at 2.4GHz, just have to use compatible AP. Any LEDE/Openwrt router with .b support disabled will work to get beacons. As for ping/data -> that again, depends on AP. firmware does not extract CSI from data packets directly, but rather from extra managmenet frames that are sent along with data as part of 802.11 standard. at 2.4GHz, some APS do not send this as often as they do in 5Ghz. Triggering these extra management frames is AP configuration/firmare dependent, as well as ping payload size dependent.

@mzakharo The patched firmwares do not extract CSI from extra management frames sent along with data. CSI extracted by this project is calculated from the long training sequence of the phy preample of every incoming frame. You might have mixed this up with the beamforming feedback? If yes, it is not used by this extractor. Edit: I might have misunderstood you. You're probably talking about the ICMP packets (in case of ping) as data packets and Wi-Fi frames enclosing them as "extra management frames"? You are right, there isn't necessarily a one to one relation and CSI are extracted from the Wi-Fi frames.

@PtOH03 The extractor itself does not differentiate between the 2.4 and 5GHz band. To get CSI for any kind of frame you can omit the -b byte filter when generating the config parameters with makecsiparams. However, I suggest to capture and inspect your desired frames instead to find the correct byte filter value. Generally, if you can capture the frames you want to extract related CSI of in monitor mode on the extractor device, it should also be possible to extract the CSI if configured correctly. Apart from ping I can recommend using iperf to generate traffic. Also make sure none of the points described in the FAQ are causing your problem.

[ghost]

Thanks a lot @jlinktu With double checking the FAQ, I found the problem should happen to the configuration of "chanspec". What I get after keying "nexutil -k" looks like this:

admin@RT-AC86U:/jffs# ./nexutil -k __nex_driver_io: error chanspec: 0x6863, 85/160

From FAQ,

Returned chanspec 0x6863 85/160 probably means the chip or interface is not up.

So it seems I need to set up the interface. But I already set up the interface eth6 with:

wl -i eth6 up wl -i eth6 radio on ifconfig eth6 up wl -i eth6 monitor 1

I also tried set chanspec with nexutil -k, but got error again, as below:

admin@RT-AC86U:/jffs# ./nexutil -k11/20 __nex_driver_io: error

I think there should be the problem on interface setting. Could you kindly let me know what configuration I need to make at this stage?

[mzakharo]

there isn't necessarily a one to one relation and CSI are extracted from the Wi-Fi frames.

@jlinktu I found that there was a way to send ICMP ping or other data traffic, and CSI monitor not to capture anything. Converse is also true. with some AP's, you can send 1 ICMP ping, and capture 10+ CSI packets. All this QoS/WMM stuff maybe. This leads me to believe that CSI for data packets themselves is not available/extracted for some reason. Other frame types do work. It seems that not all Frame types/subtypes are able to be captured by the CSI capture interface: https://en.wikipedia.org/wiki/802.11_Frame_Types#Types_and_SubTypes

I dont have the full list of supported frametypes/subtypes, but adding a nexmon-monitor patch, along with the nexmon-csi, in wireshark/monitor mode, the chipset sees a lot more packet types in promiscuous/monitor mode than what appears through the CSI UDP port.

[jlinktu]

@PtOH03 Specify the interface when using nexutil on the AC86U, e.g.: nexutil -Ieth5 -k.

@mzakharo Interesting. Data frames should work, at least they did when I injected them. I'll keep this in mind to come back to when I got a bit more time.

[ghost]

@jlinktu With nexutil -Ieth6 -k, I can see my channel is set to 36 of 5GHz as below.

admin@RT-AC86U:/jffs# ./nexutil -Ieth6 -k chanspec: 0xd024, 36

I find that:

• It does not work to set channel with command nexutil -Ieth6 -k<channel/bandwidth>. I tried set channel to 165 with this command, but 'nexutil -Ieth6 -k' still returns channel 36, as below.

admin@RT-AC86U:/jffs# ./nexutil -Ieth6 -k165/20 admin@RT-AC86U:/jffs# ./nexutil -Ieth6 -k chanspec: 0xd024, 36

• The channel that the interface eth6 operates on is fixed to the chanspec configuration of the physical chip. With using the webUI to change 5GHz controlled channel from 36 to 157, I find the returned value of "./nexutil -Ieth6 -k" also changed to channel 157, as below.

admin@RT-AC86U:/jffs# ./nexutil -Ieth6 -k chanspec: 0xe29b, 157/80

• However, I cannot mount the interface eth6 to the 2.4GHz physical chip. Even after disabling 5GHz band, the interface will still be mounted to 5GHz channel, as below.

admin@RT-AC86U:/jffs# ./eth6Set wl: Radio Off admin@RT-AC86U:/jffs# ./nexutil -Ieth6 -k chanspec: 0xd024, 36

where eth6Set is just a script containing interface set configuration, as below

wl -i eth6 up wl -i eth6 radio on ifconfig eth6 up wl -i eth6 monitor 1

So far, I believe that if I can correctly mount an interface to a 2.4GHz channel, CSI extraction should work. But I know very less about this asuswrt wireless configuration (e.g. wl). So I'm expecting any possible command that I can try to make this config. Many thanks!

[jlinktu]

Try to use a different country code to allow tuning to channel 165. You can also use wl instead of nexutil to set the channel, e.g.:

wl -i eth6 up
wl -i eth6 radio on
wl -i eth6 country US # you can also try ALL
wl -i eth6 chanspec 165/20
wl -i eth6 monitor 1
ifconfig eth6 up

The AC86U has two interfaces, one for 2.4GHz and one for 5Ghz. The 2.4GHz one is probably called eth5.

[ghost]

@jlinktu With using eth5 for 2.4GHz, it works now, and it can extract CSI from packets triggered by ping or iperf.

As always, many thanks!