This adds the single missing compatible supported by the mt76 driver,
which is used by a bunch of ramips mt7628an devices.
Signed-off-by: Andre Heider <a.heider@gmail.com>
Some device have embedded wifi card that are not connected with usb or
internall with pci. Such device have fake device_id and only the
vendor_id actually reflect something real but internally they don't have
any id and are just matched by the node compatible binding in DT.
We currently match this with a big if-else to match the single devices
but this can be improved and be matched directly in devices.txt
Rework this so that we can drop the big if-else and move the matching
to devices.txt
When a device is matched using compatible in iwinfo the hardware will be
flagged as embedded and won't print empty ids.
Update devices.txt by migrating all the compatible matching device from
fake id to compatible matching.
Tested-by: Christian Marangi <ansuelsmth@gmail.com> # ipq4019
Co-developed-by: Christian Marangi <ansuelsmth@gmail.com>
Signed-off-by: Jo-Philipp Wich <jo@mein.io>
Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
Tested-by: Robert Marko <robimarko@gmail.com> # ipq8074
Reviewed-by: Andre Heider <a.heider@gmail.com>
The "chan_width" var contains an index, not a value.
While at it, make the 40 and 2040 description shorter and clearer.
Signed-off-by: Andre Heider <a.heider@gmail.com>
Match by frequency and not by channel as the radio might have the same
channel on multiple bands:
$ iwinfo radio0 freqlist
[snip]
* 2.432 GHz (Channel 5)
[snip]
* 5.975 GHz (Channel 5)
[snip]
Signed-off-by: Andre Heider <a.heider@gmail.com>
Some defines/enums use bits, while some functions only set a single one.
Make it less painful to get to a name for those.
This avoids hardcoding bit lists for consumers.
Signed-off-by: Andre Heider <a.heider@gmail.com>
Unify how hwmodes are displayed, e.g.:
"802.11ac/ax/b/g/n" instead of "802.11bgnacax".
Luci currently uses a natural sort order, but that probably doesn't work
as intended once "be" is added, so let's do this here.
Signed-off-by: Andre Heider <a.heider@gmail.com>
Use a hyphen for the WEP cipher names, just as the others. Not that
anyone cares anymore, but this let's us use this array instead of
everyone fixing it up on their own.
Signed-off-by: Andre Heider <a.heider@gmail.com>
Repurpose the IWINFO_FREQ_NO_2160MHZ define for that, which was
introduced but never used. nl80211 doesn't have such a flag either.
Signed-off-by: Andre Heider <a.heider@gmail.com>
Just use the already provided info instead of mapping frequencies.
Fixes mapping lower frequencies of the 6G band, which starts at 5935MHz.
Signed-off-by: Andre Heider <a.heider@gmail.com>
Required for NL80211_BAND_6GHZ and NL80211_FREQUENCY_ATTR_NO_HE.
Taken from the v5.15.74 release, which is the current version of the
used mac80211 package.
Signed-off-by: Andre Heider <a.heider@gmail.com>
Update using current linux sources, which this was apparently
based on.
Signed-off-by: Andre Heider <a.heider@gmail.com>
[don't fail if no ieee80211ax option is present]
Signed-off-by: Jo-Philipp Wich <jo@mein.io>
It's too slow to do it all over again and again, especially with e.g.
luci constantly polling.
Before:
$ time iwinfo phy0 info
real 0m 0.54s
$ time iwinfo radio0 info
real 0m 0.70s
$ time ubus call luci-rpc getWirelessDevices
real 0m 0.67s
After:
$ time iwinfo phy0 info
real 0m 0.04s
$ time iwinfo radio0 info
real 0m 0.09s
$ time ubus call luci-rpc getWirelessDevices
real 0m 0.17s
Signed-off-by: Andre Heider <a.heider@gmail.com>
Add USB PID/VID as found on e.g. Comfast CF-953AX.
Signed-off-by: Andre Heider <a.heider@gmail.com>
[rebase onto current master]
Signed-off-by: Jo-Philipp Wich <jo@mein.io>
Treat USB vendor and product IDs like PCI subsystem vendor and device IDs
respectively to allow describing USB devices as `0000 0000 $vid $pid` in
the hardware database.
As a side effect, this also skips potentially expensive MTD lookups on
embedded devices with plugged in USB radios.
With a 5.15 kernel, such MTD lookups even spam dmesg with:
mtdblock: MTD device 'factory' is NAND, please consider using UBI block devices instead.
This fix speeds up iwinfo considerably on affected systems:
Before:
sys 0m 3.56s
After:
sys 0m 0.09s
Suggested-by: Andre Heider <a.heider@gmail.com>
Signed-off-by: Jo-Philipp Wich <jo@mein.io>
This isn't required nor used anymore, and it's been +8 years.
See
"735a03be: iwinfo: adjust for changed wpa_supplicant control socket path"
on the main repository.
Signed-off-by: Andre Heider <a.heider@gmail.com>
No data at all can currently be read from the control socket.
Set up the permission exactly like hostapd's wpa_cli utility to fix it.
Among other this fixes a mesh's encryption being shown as "None".
Signed-off-by: Andre Heider <a.heider@gmail.com>
Increase buffer sizes to get rid of e.g.:
iwinfo_nl80211.c:797:41: note: 'snprintf' output between 24 and 279 bytes into a destination of size 64
Signed-off-by: Andre Heider <a.heider@gmail.com>
Remove the assumption that phy names follow the format phy%d and instead look
up the phy index from sysfs properly
Signed-off-by: Felix Fietkau <nbd@nbd.name>
Don't assume a fixed naming pattern. Check all options in this order:
- netdev
- phy name
- wifi device in uci
Use the first one that matches
Signed-off-by: Felix Fietkau <nbd@nbd.name>
`iwinfo.h` says:
#define IWINFO_KMGMT_COUNT 5
...
extern const char *IWINFO_KMGMT_NAMES[IWINFO_KMGMT_COUNT];
Though only only 3 items are defined. The other two were forgotten
when adding WPA3 support. The `auth_suites` table exposed via Lua
never included the items "SAE" and "OWE" until this commit.
Fixes: f8ef450652 ("iwinfo: Add support for WPA3")
Signed-off-by: Tjeu Kayim <15987676+TjeuKayim@users.noreply.github.com>
Don't add the hwmode A for radios which do not support 5GHz operation.
Before, this hwmode was added to all non-VHT radios regardless of their
supported bands.
Fixes commit 562d015326 ("iwinfo: nl80211: fix hwmode parsing for multi-band NICs")
Signed-off-by: David Bauer <mail@david-bauer.net>
In case a NIC supports multiple frequency bands, the supported
hw-modelist might not contain all valid hwmodes, as B/G/AD hwmodes are
only included based on the last parsed supported frequency.
In case a radio supports multiple bands, this might result in these
hwmodes not being flagged as supported.
Circumvent this by tracking all seen frequency bands using a bitmask
which later determined which HW modes are listed as supported.
Signed-off-by: David Bauer <mail@david-bauer.net>
