Failed to open the device... (/dev/CSI_dev)

[pmssantos]

Hi everyone,

I'm quite curious about this tool. I have a couple of Dell laptops (a Latitude E6320 and a Latitude 13), both with a Compex WLE600VX Wifi module (Atheros QCA 9882) and Ubuntu 14.04.06 with the modified kernel (both report kernel version to be 4.1.10+). I've set up one of these as AP and connected the other to the first; I also realize there's a recvCSI and sendData applications to trigger a data exchange. However, nothing happens when I try to run them. Inspecting the source code of 'csi_fun.c' under the 'recvCSI/' folder, the code will try to open a '/dev/CSI_dev' that does not exist (in any of the computers).

Any clues about what I might have missed? Any help would be appreciated; thank you!

[Geosearchef]

The /dev/CSI_dev is created by the driver when loaded. Are you sure you installed the driver / modified kernel correctly? What files does /dev contain? You can also try modifying the kernel code to print a statement to dmesg for debugging after it created the device.

Beware though, that it might be impossible to receive CSI with the chip you're using (I think it's too recent): https://github.com/xieyaxiongfly/Atheros_CSI_tool_OpenWRT_src/issues/35

[pmssantos]

Hi Geosearchef, Thanks a lot for the speedy reply!

The /dev/CSI_dev is created by the driver when loaded.

Yes, I presumed as much. That's why I was surprised to not finding it.

Are you sure you installed the driver / modified kernel correctly? What files does /dev contain?

I followed the steps in the installation guide, and the installed kernel is reported to be 4.1.10+ as expected (and, as you said, I presume I don't have to do 'insmod'). /dev contains all the usual list of 'devices' (tty, etc.), just not CSI_dev.

You can also try modifying the kernel code to print a statement to dmesg for debugging after it created the device.

Yes, 'dmesg' was one of the first things I checked, to little result. As for altering the kernel code, I'll have to look around to find where the module insertion happens (I have no idea in which piece of code that is done).

Beware though, that it might be impossible to receive CSI with the chip you're using (I think it's too recent): #35

Thanks for the pointer, I searched the existing posts but ended up not checking this particular one. Yes, that's a possibility. I was hoping the Compex WLE600VX (QCA 9882) would work because the main page of the Atheros CSI Tool shows a Compex WLE900VX (QCA 9880), and I believe they're probably the same chip, just with the WLE600 supporting only 2 antennas and the WLE900 supporting 3. But... I never saw a reference to QCA 9880 in the page, just older models like the AR9580 (which possibly Compex used in previous models, hence the image).

Not sure if it makes sense to me to go through all the effort of inspecting the kernel operation. Because I'm using old laptops with mini-PCI slots, I can just buy some older known-to-work WiFi modules. Nevertheless, I'd be happy if you could give me a pointer of where in the kernel code could I start trying to the debug the module insertion. I've seen your efforts to have newer Atheros chips working with the tool (as reported in #35), and maybe I can provide a new insight on this.

Thank you very much, and a happy 2021!

[Geosearchef]

The CSI tool modifications are located in /drivers/net/wireless/ath/ath9k. (https://github.com/xieyaxiongfly/Atheros-CSI-Tool/tree/master/drivers/net/wireless/ath/ath9k)

The call on receiving a packet is hooked here: https://github.com/xieyaxiongfly/Atheros-CSI-Tool/blob/master/drivers/net/wireless/ath/ath9k/ar9003_mac.c#L611 and forwarded to the csi tool. The sounding flag on the TX side is set here: https://github.com/xieyaxiongfly/Atheros-CSI-Tool/blob/master/drivers/net/wireless/ath/ath9k/ar9003_mac.c#L172

This is the csi tool code: https://github.com/xieyaxiongfly/Atheros-CSI-Tool/blob/master/drivers/net/wireless/ath/ath9k/ar9003_csi.c When the csi tool is loaded you should see the following message in dmesg: https://github.com/xieyaxiongfly/Atheros-CSI-Tool/blob/master/drivers/net/wireless/ath/ath9k/ar9003_csi.c#L125

To modify the code when building the openwrt firmware, you can find the csi tool here: https://github.com/xieyaxiongfly/Atheros_CSI_tool_OpenWRT_src/tree/master/package/kernel/mac80211/csi and the modification of the original driver as a patch here: https://github.com/xieyaxiongfly/Atheros_CSI_tool_OpenWRT_src/blob/master/package/kernel/mac80211/patches/556-ath9k_CSI_ar9003mac.patch

Not sure if it makes sense to me to go through all the effort of inspecting the kernel operation.

I did that :) . The relevant line for investigating newer devices is this method: https://github.com/xieyaxiongfly/Atheros-CSI-Tool/blob/2288dcf91da81365c388b23a0f6cc113e41dde2b/drivers/net/wireless/ath/ath9k/ar9003_csi.c#L233 In my case, I got the sounding flag set, but rx_hw_upload_data, rx_hw_upload_data_valid and rx_hw_upload_data_type had invalid values (see data sheet of the chip). I assume this is due to the newer chips not supporting beamforming anymore.

When switching to older, supported devices it worked flawlessly for me.

Because I'm using old laptops with mini-PCI slots, I can just buy some older known-to-work WiFi modules.

I know that the QCA9880 doesn't work, so I guess the QCA9882 won't either. I can confirm that the AR9380 (SoC, 2,4+5Ghz), AR9462 (mPCIe) and AR9580 (5 GHz) work. I have heard somewhere that the QCA9558 will work as well (TP Link Archer C7 v1-v3, beware though, only internal antennas). The QCA9563 didn't work in my tests (Archer C7 v4-v5).

I was using the TP-Link WDR-4300 (N750, contains AR9344 (the 2 outer external antennas, 2,4Ghz), contains AR9580 (the 3 outer external antennas, 5 GHz), both chips in there work fine. I also used the TP-Link WR2543ND (contains AR9380, 2,4 and 5 GHz using 3 external antennas). For mPCIe cards, I'd recommend trying to get an AR9462, I had two of them, both worked fine. This one is very common to find in older Laptops under the rebranded name of AR5B22, actually found one of those in my old laptop after ordering another one.

[pmssantos]

Hi Geosearchef,

Thanks a lot. You clearly have been looking at this for way longer than I have. I really appreciate all the pointers. :)

The CSI tool modifications are located in /drivers/net/wireless/ath/ath9k. (https://github.com/xieyaxiongfly/Atheros-CSI-Tool/tree/master/drivers/net/wireless/ath/ath9k)

Browsing through this, I'm surprised to see how many model-specific source files there are (all those 'ar9XXX.c/h' files). That already tells you there's a lot of fiddling to get each new model to work, and that it is perhaps a better idea to stick to one of these modules.

When the csi tool is loaded you should see the following message in dmesg: https://github.com/xieyaxiongfly/Atheros-CSI-Tool/blob/master/drivers/net/wireless/ath/ath9k/ar9003_csi.c#L125

This is great. Thanks for the indication.

To modify the code when building the openwrt firmware, (...)

Not going there yet, maybe later.

I assume this is due to the newer chips not supporting beamforming anymore.

I'd say that's unlikely. They have to support it, it's part of the standard; and the new chips have to be retro-compatible with the older WiFi generations (a, b, g, n).

I know that the QCA9880 doesn't work,(...)

Look, I'm not sure about what I'm about to say next; I'd need more time to research this, and it's possible that I'm going to say something stupid, but let me say it anyway: Aren't these newer chips using ath10k? QCA 988X are 802.11ac (they support downlink multi-user (MU) MIMO, while 802.11n was downlink single-user MIMO [and 802.11ax will support MU downlink and uplink MIMO]), and I believe they use ath10k. Doing lsmod in my PCs, it's ath10k that is loaded. Perhaps we should be looking into porting the CSI tool into the ath10k implementation to add support for the newer chips (perhaps those that support IEEE 802.11ac).

For mPCIe cards, I'd recommend trying to get an AR9462 (...)

I really appreciate the suggestion. I'll for sure look into these. If you're interested on this let's keep in touch, even if (only very) occasionally I can look into this.

Best, Pedro

[Geosearchef]

Hi Pedro,

I'd say that's unlikely. They have to support it, it's part of the standard; and the new chips have to be retro-compatible with the older WiFi generations (a, b, g, n).

That's the issue, it isn't part of the standard. Beamforming has only been mandatory since 802.11ac. In the n standard, it's optional and defines multiple different methods, being the reason a lot of manufacturers didn't implement it or just implemented a part of it.

Aren't these newer chips using ath10k?

AHHH, of course, yeah, you're right, they're running ath10k, my fault, it's been some time since I worked on that.

If you're interested on this let's keep in touch, even if (only very) occasionally I can look into this.

Sure!

Geo