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@xxxxxxxxxxxxxxxxxx>
> ---
> 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
Attachment:
signature.asc
Description: This is a digitally signed message part.
