802.11mc Support (Rivet Device 1672) on Linux

[CVTech]

I am trying to test/confirm functionality of 802.11mc with Intel Wireless on Linux.

Device info

sudo lspci -v

0000:00:14.3 Network controller: Intel Corporation Alder Lake-P PCH CNVi WiFi (rev 01)
Subsystem: Rivet Networks Device 1672
Flags: bus master, fast devsel, latency 0, IRQ 16, IOMMU group 11
Memory at 603c2b4000 (64-bit, non-prefetchable) [size=16K]
Capabilities: [c8] Power Management version 3
Capabilities: [d0] MSI: Enable- Count=1/1 Maskable- 64bit+
Capabilities: [40] Express Root Complex Integrated Endpoint, MSI 00
Capabilities: [80] MSI-X: Enable+ Count=16 Masked-
Capabilities: [100] Latency Tolerance Reporting
Capabilities: [164] Vendor Specific Information: ID=0010 Rev=0 Len=014 <?>
Kernel driver in use: iwlwifi
Kernel modules: iwlwifi


uname -a

6.2.0-34-generic #34~22.04.1-Ubuntu SMP PREEMPT_DYNAMIC Thu Sep 7 13:12:03 UTC 2 x86_64 x86_64 x86_64 GNU/Linux

modinfo iwlwifi
filename:       /lib/modules/6.2.0-34-generic/kernel/drivers/net/wireless/intel/iwlwifi/iwlwifi.ko

I have valid 802.11mc FTM responder multiple access point network, as verified by 2 separate Android OS devices (samsung S Tab, and Google Pixel) providing valid ranging results. When I attempt to run ranging on my laptop with above detailed kernel and driver, I get strange results. Here is the command I am using and results (as an example to one AP)

$cat conf80
d0:4d:c6:b6:c6:90 bw=80 cf=5620 cf1=5610 lci ftms_per_burst=8 asap

$sudo iw dev wlp0s20f3 measurement ftm_request conf80
dev 0x1 (phy #0): Peer measurements (cookie 45):
  Peer d0:4d:c6:b6:c6:90: status=2 (TIMEOUT) @187037284286706 tsf=0
    FTM
      BURST_INDEX: 0
      NUM_BURSTS_EXP: 0
      BURST_DURATION: 0
      FTMS_PER_BURST: 0
      RSSI_AVG: 4294967176
      RSSI_SPREAD: 0
      RTT_AVG: 0
      RTT_VARIANCE: 0
      RTT_SPREAD: 0
      LCI: 3d 00 08 00 10 01 60 68 26 18 2c 00 00 00 00 4c 
      LCI: 0b 00 a0 00 42 04 06 1c 00 17 00 00 7f 06 01 01 

In this case, which is common occurrence, the output reports nothing of use related to ftm due to the status code 2 "Timeout". This happens around 50% of the time the command is executed.  At other times, the following or similar result will occur with status code "0" success:

wdev 0x1 (phy #0): Peer measurements (cookie 46):
  Peer d0:4d:c6:b6:c6:90: status=0 (SUCCESS) @187211827826185 tsf=0
    FTM
      BURST_INDEX: 0
      NUM_BURSTS_EXP: 0
      BURST_DURATION: 0
      FTMS_PER_BURST: 0
      RSSI_AVG: 4294967244
      RSSI_SPREAD: 0
      RTT_AVG: 88294
      RTT_VARIANCE: 4462851
      RTT_SPREAD: 6286
      LCI: 3e 00 08 00 10 01 60 68 26 18 2c 00 00 00 00 4c 
      LCI: 0b 00 a0 00 42 04 06 1c 00 17 00 00 7f 06 01 01 

In this case note that an RTT_AVG is reported, along with a variance and spread. However, note that there are several other values marked "0" where is would be expected at least to regurgitate the input request, for example "FTMS_PER_BURST" was requested to be "8" and above shows "0".  Notwithstanding the above, if taking the RTT_AVG value as an outcome in ps, it is off by a large amount from the expected value, which should correspond to around 4m (13342 ps), and again Android OS devices noted above are provided correct RTT ranging values from the same test location to the same test access points.

My questions are as follows:

-Is there a suggested improved linux driver for intel wireless or linux kernel that I should test with?

-Would a low latency kernel be suggested for the timeout issue?

-Am I interpreting the output incorrectly? I note that the output is not documented in the iw dev man page or help.

-Why are some output values "0"  for input parameters, and even when successful, the RTT (interpreted in ps) is off but such a large factor (7x - 10x) on this platform vs android devices, which in the same test setup are achieving 0.5m (+/- 1700 ps) accuracy to true expected distance/time values?

[Jose_Intel]

Hello @CVTech

Thank you for posting on the Intel️® communities.

We understand you are experiencing some issues with a wireless adapter. We will be more than happy to assist you.

What is the exact adapter you are using?

Please make sure you have the latest Ubuntu version. Linux drivers are part of the upstream Linux* kernel. They're available through the regular channels, distributions, or the Linux* kernel archives.

Let us know any improvement.

Best regards,

Jose B.

Intel Customer Support Technician

[CVTech]

This is an Killer Wireless AX211 (a few more details reported on the device):

lspci -nn -s 0000:00:14.3
0000:00:14.3 Network controller [0280]: Intel Corporation Alder Lake-P PCH CNVi WiFi [8086:51f0] (rev 01)
$ sudo lspci -vv -s 0000:00:14.3
0000:00:14.3 Network controller: Intel Corporation Alder Lake-P PCH CNVi WiFi (rev 01)
	Subsystem: Rivet Networks Device 1672
	Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+
	Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
	Latency: 0, Cache Line Size: 64 bytes
	Interrupt: pin A routed to IRQ 16
	IOMMU group: 11
	Region 0: Memory at 603c2b4000 (64-bit, non-prefetchable) [size=16K]
	Capabilities: [c8] Power Management version 3
		Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA PME(D0+,D1-,D2-,D3hot+,D3cold+)
		Status: D0 NoSoftRst+ PME-Enable- DSel=0 DScale=0 PME-
	Capabilities: [d0] MSI: Enable- Count=1/1 Maskable- 64bit+
		Address: 0000000000000000  Data: 0000
	Capabilities: [40] Express (v2) Root Complex Integrated Endpoint, MSI 00
		DevCap:	MaxPayload 128 bytes, PhantFunc 0
			ExtTag- RBE- FLReset+
		DevCtl:	CorrErr- NonFatalErr- FatalErr- UnsupReq-
			RlxdOrd+ ExtTag- PhantFunc- AuxPwr+ NoSnoop+ FLReset-
			MaxPayload 128 bytes, MaxReadReq 128 bytes
		DevSta:	CorrErr- NonFatalErr- FatalErr- UnsupReq- AuxPwr+ TransPend-
		DevCap2: Completion Timeout: Range B, TimeoutDis+ NROPrPrP- LTR+
			 10BitTagComp- 10BitTagReq- OBFF Via WAKE#, ExtFmt- EETLPPrefix-
			 EmergencyPowerReduction Not Supported, EmergencyPowerReductionInit-
			 FRS-
			 AtomicOpsCap: 32bit- 64bit- 128bitCAS-
		DevCtl2: Completion Timeout: 16ms to 55ms, TimeoutDis- LTR+ OBFF Disabled,
			 AtomicOpsCtl: ReqEn-
	Capabilities: [80] MSI-X: Enable+ Count=16 Masked-
		Vector table: BAR=0 offset=00002000
		PBA: BAR=0 offset=00003000
	Capabilities: [100 v1] Latency Tolerance Reporting
		Max snoop latency: 0ns
		Max no snoop latency: 0ns
	Capabilities: [164 v1] Vendor Specific Information: ID=0010 Rev=0 Len=014 <?>
	Kernel driver in use: iwlwifi
	Kernel modules: iwlwifi

I cloned the iwlwifi firmware from  https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/ with no improvement to the issue in my report above.

$ modinfo iwlwifi
filename:       /lib/modules/6.2.0-34-generic/kernel/drivers/net/wireless/intel/iwlwifi/iwlwifi.ko

I will check against recently released linux 6.5 kernel in a few days, but look for community suggestions if the 802.11mc feature has been tested and confirmed functional on this wireless adapter on ANY available kernel / driver combination. 802.11mc (FTM) now seems quite functional and accurate on android devices but I would like to test it with intel wireless for wider applications support on various systems.

[Jose_Intel]

Hello CVTech

Thank you for your reply, we appreciate the information provided.

Allow us to check the issue internally, we will post any update here as soon as we have one.

Best regards,

Jose B.

Intel Customer Support Technician

[Jose_Intel]

Hello CVTech

Thank you for patiently waiting.

Based on the information provided, we want to inform that our wireless products are mainly a STA/ client solution on PCs.

For other usages such as designing the FTM or Wi-Fi AP mode, please contact your Intel representative directly (Intel FAE) or check with Linux forums/communities. e.g. https://www.winlab.rutgers.edu/~gruteser/projects/ftm/Setups.htm

Please keep in mind that this thread will no longer be monitored by Intel. Thank you for understanding.

Best regards,

Jose B.

Intel Customer Support Technician