diff mbox series

[RFC] wifi: intel: incorrect RSSI values on beacons from APs using legacy rates

Message ID 20241125164034.2712936-1-ih@simonwunderlich.de
State New
Headers show
Series [RFC] wifi: intel: incorrect RSSI values on beacons from APs using legacy rates | expand

Commit Message

Hamdi Issam Nov. 25, 2024, 4:40 p.m. UTC 
We identified an issue where the RSSI values for beacons from
legacy rates AP are incorrect, consistently showing -128.

This issue was identified on the Intel AX210 WiFi chip with
firmware version "89.202a2f7b.0 ty-a0-gf-a0-89.ucode op_mode iwlmvm"

To reproduce this issue :
    - Setup an AP with legacy rates on the frequency 2422Mhz
    - And on the device with Intel AX210 chip run:
        iw phy0 interface add mon0 type monitor
        ip link set mon0 up
        iw dev mon0 set freq 2422
        tcpdump -i mon0 -v

After debugging, we discovered that the RSSI values become
correct when a printk() statement is added to the RX path
in the iwlwifi driver, as shown the patch below.

Alternatively, adding udelay() instead of printk() also corrects
the incorrect RSSI values; however, this approach leads to
firmware warnings and errors:

````

base-commit: 2b94751626a6d49bbe42a19cc1503bd391016bd5

Comments

Simon Wunderlich Dec. 3, 2024, 3:10 p.m. UTC | #1 
Hi Johannes, all,

just wanted to bump on this issue one more time. We basically want to 
passively receive packets and evaluate the signal strength, and getting bogus 
signal strength (-128) for DSSS packets makes this unusable for this 
application. At the same time, we would like to be able to use the 6 GHz band, 
but we can only do that when we scan to have the firmware detect the country 
code and enable the 6 GHz band.

We have found a way to get the RSSI reporting working, but only if we don't 
scan, as Issam explained in more detail.

This looks like a firmware bug to us, it seems the firmware writes the RSSI too 
late. We don't have the means to debug this further, though.

Is this mailing list even the right place to report this kind of issue, or 
should we contact somebody else?

Thank you,
        Simon

On Monday, November 25, 2024 5:40:34 PM CET Issam Hamdi wrote:
> We identified an issue where the RSSI values for beacons from
> legacy rates AP are incorrect, consistently showing -128.
> 
> This issue was identified on the Intel AX210 WiFi chip with
> firmware version "89.202a2f7b.0 ty-a0-gf-a0-89.ucode op_mode iwlmvm"
> 
> To reproduce this issue :
>     - Setup an AP with legacy rates on the frequency 2422Mhz
>     - And on the device with Intel AX210 chip run:
>         iw phy0 interface add mon0 type monitor
>         ip link set mon0 up
>         iw dev mon0 set freq 2422
>         tcpdump -i mon0 -v
> 
> After debugging, we discovered that the RSSI values become
> correct when a printk() statement is added to the RX path
> in the iwlwifi driver, as shown the patch below.
> 
> Alternatively, adding udelay() instead of printk() also corrects
> the incorrect RSSI values; however, this approach leads to
> firmware warnings and errors:
> 
> ````
> --- a/drivers/net/wireless/intel/iwlwifi/pcie/rx.c
> +++ b/drivers/net/wireless/intel/iwlwifi/pcie/rx.c
> @@ -1543,7 +1543,7 @@ restart:
>          }
> 
>          IWL_DEBUG_RX(trans, "Q %d: HW = %d, SW = %d\n", rxq->id, r, i);
> -
> +        udelay(500);
>          rxb = iwl_pcie_get_rxb(trans, rxq, i, &join);
>          if (!rxb)
>              goto out;
> ````
> 
> Additionally, we found that deleting all existing interfaces on
> the PHY and then creating a monitor interface resolves this issue:
>     iw dev wlan0 interface del   # In case we have wlan0 as the existing
> interface. iw phy0 interface add mon0 type monitor
>     ip link set mon0 up
>     iw dev mon0 set freq 2422
> 
> However, in this case, it will not be possible to execute the scan
> command with the monitor interface to prompt the firmware to
> trigger the country code.
> 
> Has anyone encountered this issue before or have any insights
> into the potential root cause ?
> 
> Signed-off-by: Issam Hamdi <ih@simonwunderlich.de>
> ---
>  drivers/net/wireless/intel/iwlwifi/pcie/rx.c | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/drivers/net/wireless/intel/iwlwifi/pcie/rx.c
> b/drivers/net/wireless/intel/iwlwifi/pcie/rx.c index
> afb88eab8174..b0ce71e6260b 100644
> --- a/drivers/net/wireless/intel/iwlwifi/pcie/rx.c
> +++ b/drivers/net/wireless/intel/iwlwifi/pcie/rx.c
> @@ -1544,6 +1544,8 @@ static int iwl_pcie_rx_handle(struct iwl_trans *trans,
> int queue, int budget)
> 
>  		IWL_DEBUG_RX(trans, "Q %d: HW = %d, SW = %d\n", 
rxq->id, r, i);
> 
> +		printk(KERN_DEBUG "Got new packet\n");
> +
>  		rxb = iwl_pcie_get_rxb(trans, rxq, i, &join);
>  		if (!rxb)
>  			goto out;
> 
> base-commit: 2b94751626a6d49bbe42a19cc1503bd391016bd5
Hamdi Issam Feb. 11, 2025, 4:58 p.m. UTC | #2 
Hello,

I have opened a ticket 
(https://community.intel.com/t5/Wireless/wifi-intel-incorrect-RSSI-values-on-beacons-from-APs-using/m-p/1647584#M57080) 
on the intel support community about this issue, but the Linux OS is 
unsupported by them.

Does anyone have any ideas on how to further debug this issue or what 
might be causing it?

Regards,

Issam

On 11/25/24 17:40, Issam Hamdi wrote:
> We identified an issue where the RSSI values for beacons from
> legacy rates AP are incorrect, consistently showing -128.
>
> This issue was identified on the Intel AX210 WiFi chip with
> firmware version "89.202a2f7b.0 ty-a0-gf-a0-89.ucode op_mode iwlmvm"
>
> To reproduce this issue :
>      - Setup an AP with legacy rates on the frequency 2422Mhz
>      - And on the device with Intel AX210 chip run:
>          iw phy0 interface add mon0 type monitor
>          ip link set mon0 up
>          iw dev mon0 set freq 2422
>          tcpdump -i mon0 -v
>
> After debugging, we discovered that the RSSI values become
> correct when a printk() statement is added to the RX path
> in the iwlwifi driver, as shown the patch below.
>
> Alternatively, adding udelay() instead of printk() also corrects
> the incorrect RSSI values; however, this approach leads to
> firmware warnings and errors:
>
> ````
> --- a/drivers/net/wireless/intel/iwlwifi/pcie/rx.c
> +++ b/drivers/net/wireless/intel/iwlwifi/pcie/rx.c
> @@ -1543,7 +1543,7 @@ restart:
>           }
>
>           IWL_DEBUG_RX(trans, "Q %d: HW = %d, SW = %d\n", rxq->id, r, i);
> -
> +        udelay(500);
>           rxb = iwl_pcie_get_rxb(trans, rxq, i, &join);
>           if (!rxb)
>               goto out;
> ````
>
> Additionally, we found that deleting all existing interfaces on
> the PHY and then creating a monitor interface resolves this issue:
>      iw dev wlan0 interface del   # In case we have wlan0 as the existing interface.
>      iw phy0 interface add mon0 type monitor
>      ip link set mon0 up
>      iw dev mon0 set freq 2422
>
> However, in this case, it will not be possible to execute the scan
> command with the monitor interface to prompt the firmware to
> trigger the country code.
>
> Has anyone encountered this issue before or have any insights
> into the potential root cause ?
>
> Signed-off-by: Issam Hamdi <ih@simonwunderlich.de>
> ---
>   drivers/net/wireless/intel/iwlwifi/pcie/rx.c | 2 ++
>   1 file changed, 2 insertions(+)
>
> diff --git a/drivers/net/wireless/intel/iwlwifi/pcie/rx.c b/drivers/net/wireless/intel/iwlwifi/pcie/rx.c
> index afb88eab8174..b0ce71e6260b 100644
> --- a/drivers/net/wireless/intel/iwlwifi/pcie/rx.c
> +++ b/drivers/net/wireless/intel/iwlwifi/pcie/rx.c
> @@ -1544,6 +1544,8 @@ static int iwl_pcie_rx_handle(struct iwl_trans *trans, int queue, int budget)
>   
>   		IWL_DEBUG_RX(trans, "Q %d: HW = %d, SW = %d\n", rxq->id, r, i);
>   
> +		printk(KERN_DEBUG "Got new packet\n");
> +
>   		rxb = iwl_pcie_get_rxb(trans, rxq, i, &join);
>   		if (!rxb)
>   			goto out;
>
> base-commit: 2b94751626a6d49bbe42a19cc1503bd391016bd5
Ben Greear Feb. 12, 2025, 1:26 a.m. UTC | #3 
On 2/11/25 8:58 AM, Hamdi Issam wrote:
> Hello,
> 
> I have opened a ticket (https://community.intel.com/t5/Wireless/wifi-intel-incorrect-RSSI-values-on-beacons-from-APs-using/m-p/1647584#M57080) on the intel 
> support community about this issue, but the Linux OS is unsupported by them.
> 
> Does anyone have any ideas on how to further debug this issue or what might be causing it?

I'm not sure about this specific issue, but if you feel like using out-of-tree patches
that are never likely to make it upstream, you can find patches in our tree that disables
the Intel firmware's beacon filtering (and beacon RSSI reporting)
and then does the RSSI calculation in the driver.  It is not a small change and might
have some weird dependencies on other stuff in our tree.

That fixed some inaccuracies that we found, but it may have draw-backs that I'm
not aware of.

https://github.com/greearb/linux-ct-6.13

Thanks,
Ben
Hamdi Issam Feb. 12, 2025, 12:19 p.m. UTC | #4 
Hello,

On 2/12/25 02:26, Ben Greear wrote:

> On 2/11/25 8:58 AM, Hamdi Issam wrote:
>> Hello,
>>
>> I have opened a ticket 
>> (https://community.intel.com/t5/Wireless/wifi-intel-incorrect-RSSI-values-on-beacons-from-APs-using/m-p/1647584#M57080) 
>> on the intel support community about this issue, but the Linux OS is 
>> unsupported by them.
>>
>> Does anyone have any ideas on how to further debug this issue or what 
>> might be causing it?
>
> I'm not sure about this specific issue, but if you feel like using 
> out-of-tree patches
> that are never likely to make it upstream, you can find patches in our 
> tree that disables
> the Intel firmware's beacon filtering (and beacon RSSI reporting)
> and then does the RSSI calculation in the driver.  It is not a small 
> change and might
> have some weird dependencies on other stuff in our tree.
>
> That fixed some inaccuracies that we found, but it may have draw-backs 
> that I'm
> not aware of.
>
> https://github.com/greearb/linux-ct-6.13
>
Thank you for the hint.

We prefer an upstream fix, but we will look into this workaround.

Best regards,

Issam
diff mbox series

Patch

--- a/drivers/net/wireless/intel/iwlwifi/pcie/rx.c
+++ b/drivers/net/wireless/intel/iwlwifi/pcie/rx.c
@@ -1543,7 +1543,7 @@  restart:
         }

         IWL_DEBUG_RX(trans, "Q %d: HW = %d, SW = %d\n", rxq->id, r, i);
-
+        udelay(500);
         rxb = iwl_pcie_get_rxb(trans, rxq, i, &join);
         if (!rxb)
             goto out;
````

Additionally, we found that deleting all existing interfaces on
the PHY and then creating a monitor interface resolves this issue:
    iw dev wlan0 interface del   # In case we have wlan0 as the existing interface.
    iw phy0 interface add mon0 type monitor
    ip link set mon0 up
    iw dev mon0 set freq 2422

However, in this case, it will not be possible to execute the scan
command with the monitor interface to prompt the firmware to
trigger the country code.

Has anyone encountered this issue before or have any insights
into the potential root cause ?

Signed-off-by: Issam Hamdi <ih@simonwunderlich.de>
---
 drivers/net/wireless/intel/iwlwifi/pcie/rx.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/net/wireless/intel/iwlwifi/pcie/rx.c b/drivers/net/wireless/intel/iwlwifi/pcie/rx.c
index afb88eab8174..b0ce71e6260b 100644
--- a/drivers/net/wireless/intel/iwlwifi/pcie/rx.c
+++ b/drivers/net/wireless/intel/iwlwifi/pcie/rx.c
@@ -1544,6 +1544,8 @@  static int iwl_pcie_rx_handle(struct iwl_trans *trans, int queue, int budget)
 
 		IWL_DEBUG_RX(trans, "Q %d: HW = %d, SW = %d\n", rxq->id, r, i);
 
+		printk(KERN_DEBUG "Got new packet\n");
+
 		rxb = iwl_pcie_get_rxb(trans, rxq, i, &join);
 		if (!rxb)
 			goto out;