iwinfo: add device id for Atheros AR9287 PCIe wifi card This card is identified by lspci as: 01:00.0 Network controller [0280]: Qualcomm Atheros AR9287 Wireless Network Adapter (PCI-Express) [168c:002e] (rev 01) Subsystem: Qualcomm Atheros Device [168c:30a4] Signed-off-by: Pali Rohár <pali@kernel.org>
iwinfo: add missing HT modename for HT-None Commit bf2c1069a7f1 ("nl80211: add htmode to iwinfo_ops") increased IWINFO_HTMODE_COUNT but left the size of the IWINFO_HTMODE_NAMES array untouched, leading to a segmentation fault when trying to get the HT modelist from Lua. Add a dummy NOHT modestring to make the array size fit the size declaration. Fixes: bf2c1069a7f1 ("nl80211: add htmode to iwinfo_ops") Signed-off-by: David Bauer <mail@david-bauer.net>
Revert "iwinfo: add BSS load element to scan result" This reverts commit a6914dc0dc3cba65e245fbe40076626ea2bcd5a3. iwinfo currently misses ABI version tracking in OpenWrt, potentially breaking other packages unintentionally. Revert this commit for now until this is implemented. Otherwise, we are not able to safely bump iwinfo at the moment. Signed-off-by: David Bauer <mail@david-bauer.net>
iwinfo: add BSS load element to scan result This adds support for the BSS load information element. With this patch, the BSS load information is visible when using the CLI as well as when accessing scan results using the LUA binding. Signed-off-by: David Bauer <mail@david-bauer.net>
nl80211: align path to phy mapping logic with mac80211.sh The mac80211.sh implementation of the uci "path" option compares the readlink() results of each /sys/class/ieee80211/*/device link to find the proper phy directory while iwinfo so far tried to construct a full path out of the uci value. The iwinfo approach appears to fail under certain circumstances, e.g. with Hyper-V systems utilizing PCI passthrough for the radio devices. This commit mimicks the behaviour of mac80211.sh more closely to achieve the same results. Signed-off-by: Jo-Philipp Wich <jo@mein.io>
nl80211: keep awaiting wpa_supplicant scan results on busy response When wpa_supplicant responds with FAIL-BUSY in response to the SCAN command, a scan process is already in process. Instead of failing in this case, simply keep awaiting the result list. This also significantly speeds up the scan operation in many cases. Signed-off-by: Jo-Philipp Wich <jo@mein.io>