Steam Deck OLED: wpa_supplicant backend repeatedly joins an access point 50 dB weaker than another on the same SSID; iwd does not

未关闭
  • 哪里不对？
#3,059 1 条评论 1 个 reaction 已指派 0 人 在 GitHub 查看

还没有人认领这个 Issue。

评估

难度
4/5
预计耗时
3-5 天
新手友好度
45/100
Issue 类型
缺陷
描述清晰度
基本清楚
活跃度
活跃
技术栈
linux
领域
networking

调研方向

Compare SteamOS behavior with the forced wpa_supplicant backend and iwd using the reproduction steps and the journal observations in the report. Start by investigating how NetworkManager selects an access point and handles the pending scan and bgscan setting. Done means the Deck reliably chooses the stronger AP or moves to it when the current link is poor.

由索引模型根据 Issue 内容生成。

描述

Your system information
  • Steam client version: 1792618285
  • SteamOS version: 3.9.5, build 20261023.100
  • Opted into Steam client beta?: No
  • Opted into SteamOS beta?: No
  • Have you checked for updates in Settings > System?: Yes
Please describe your issue in as much detail as possible:

Two access points share one SSID and password, both WPA2-PSK with CCMP, with Ethernet backhaul:

  • AP A: ASUS RT-AC68U, Wi-Fi 5, channel 149, 80 MHz, -27 dBm at the Deck
  • AP B: GL.iNet GL-MT6000, Wi-Fi 6, channel 36, 80 MHz, -77 dBm at the Deck

With "Force WPA Supplicant WiFi backend" on (wpa_supplicant v2.12), the Deck joined AP B every time, at HE-MCS 0 with 17.2 Mbit/s send and 6 Mbit/s receive link rates. In an earlier session it stayed on AP B for 25 minutes at -79 dBm with no move recorded in the journal at default log level, even though NetworkManager listed AP A as stronger. NetworkManager passed bgscan "simple:30:-70:86400" and no BSSID lock. The journal also showed "Reject scan trigger since one is already pending".

With the setting off (iwd 3.12), in the same spot, the Deck joined AP A every time, at 866.7 Mbit/s send and 173.4 Mbit/s receive.

This differs from #2981 and #2992, where the connection fails. Here it connects, but to the far weaker access point.

Describe what you expected should happen and what did happen.

Expected: the Deck joins AP A, or at least moves to it when the link is poor.
Actual: the Deck joins AP B and stays there.

Steps for reproducing this issue:
  1. Set up two access points on one SSID, with a Wi-Fi 6 AP far away and a Wi-Fi 5 AP close by.
  2. Turn on "Force WPA Supplicant WiFi backend" and restart.
  3. Check the connected BSSID with iw dev wlan0 link.
  4. Turn Wi-Fi off and on three times, checking each time.
  5. Turn the setting off, restart and repeat.

Results: wpa_supplicant joined AP B 4 of 4 times. iwd joined AP A 7 of 7 times, with no connection failures.

Notes: tested at one site, with one Wi-Fi 5 and one Wi-Fi 6 AP, so I can't say whether the Wi-Fi standard is the deciding factor. The backend also switched to wpa_supplicant on entering Gaming Mode, which matches #3005. Since I turned the setting off, it has stayed on iwd through a restart and a round trip to Desktop Mode.

主要语言
没有语言数据
星标
2.7k
派生
89
30 天内没有已合并 PR

环境准备

这个项目没有提供开发容器、Dockerfile 或贡献指南，环境需要你自己搭建：先看它的 README，通用步骤见我们的新手贡献指南。

从这里开始

  1. 先读完整个 Issue，再读项目的贡献指南。
  2. 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
  3. Fork 仓库，在一个分支上完成修改。
  4. 提交 Pull Request，并在描述里引用这个 Issue 编号。

ValveSoftware/SteamOS 的其他 Issue

查看 ValveSoftware/SteamOS 的全部 Issue

相似的 Issue

更多 Networking Issue

把新 issue 发到你的邮箱

精选适合新手参与的 GitHub issue 摘要。