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 |
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
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
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
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
--- 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;