i3status-rust
i3status-rust copied to clipboard
net block: No SSID and signal strength for wifi device
- Version:
0.22.0 - Kernel:
5.19.4-arch1-1 - Block configuration:
[[block]]
block = "net"
device = "wlp2s0"
format = "{ssid} {signal_strength} {speed_down;K}"
interval = 5
nmcli dev wifi listshows SSID and strengthiwis installed andiw dev wlp2s0 infoshows info, but no SSIDiw dev wlp2s0 linkshows the SSID
The net block with the above configuration doesn't show the SSID or signal strength. The down speed is shown, however. I use a very similar setup and config on other laptops and it works there. Just installed it on a new laptop, where it doesn't work. Any ideas?
I can confirm on the latest master. I believe it's due to a kernel update, not i3status itself.
What kernel are you running? I'm running 5.19.
5.19.4-arch1-1
I run 5.19.1 on another laptop and there it works. Will update this one and report.
This happened for me when I upgraded from 5.18.19.hardened to 5.19.5.hardened (I think?). I haven't tried downgrading.
iw dev wlp2s0info shows info
Does it show the SSID too? It stopped working for me and some other people after linux 5.18 -> 5.19 update.
Both v0.22 and latest master grab the info like SSID and signal strength via the same protocol that is used by iw dev, but v0.22 doesn't show signal strength if SSID is not available. This is fixed on master.
iwgetidworks`.iw dev wlp170s0 linkshows the SSID.iw dev wlp170s0 infodoesn't, but I'm not sure if it's supposed to?
but I'm not sure if it's supposed to?
Well, it used to... If iw dev ... link shows the SSID on linux 5.18 and earlier, then to some extent it is our bug.
On 5.18.16-arch1-1 both iw dev ... info and iw dev ... link show SSID.
So the SSID that is printed by iw dev ... info (and i3status-rs) comes from this attribute:
* @NL80211_ATTR_SSID: SSID (binary attribute, 0..32 octets)
Whereas iw dev ... link extracts SSID from
* @NL80211_BSS_INFORMATION_ELEMENTS: binary attribute containing the
* raw information elements from the probe response/beacon (bin);
* if the %NL80211_BSS_BEACON_IES attribute is present and the data is
* different then the IEs here are from a Probe Response frame; otherwise
* they are from a Beacon frame.
* However, if the driver does not indicate the source of the IEs, these
* IEs may be from either frame subtype.
* If present, the @NL80211_BSS_PRESP_DATA attribute indicates that the
* data here is known to be from a probe response, without any heuristics.
Can confirm here, on 5.19.4-arch1-1, iw dev ... info doesn't show the SSID, whereas iw dev ... link does show it.
Also, after updating my other laptop from 5.19.1 to 5.19.5, it also stopped showing ssid & signal strength. Interestingly, the device name on that machine changed from the usual wlp3s0 scheme to the old school wlan0 scheme.
Are there no upstream bug reports or discussions at all? Surely someone would have said something by now?
Probably relevant: https://bugs.archlinux.org/task/75709
Probably relevant: https://bugs.archlinux.org/task/75709
This bug report is WPA3-specific, whereas I experience this problem with all types of wifi networks, on multiple laptops.
@MaxVerevkin any new thoughts on this? I see this marked as an upstream bug, but have we clearly identified the bug? Is there an upstream bug report yet?
have we clearly identified the bug?
Kernel doesn't send NL80211_ATTR_SSID anymore (the command is NL80211_CMD_GET_INTETFACE).
Is there an upstream bug report yet?
I couldn't find anything besides the link I've already posted. I didn't have time/motivation to report it or fix it. And I don't even know where to report it.
FWIW, noting my observations if it helps.
After trying out master, since the network manager block got dropped, I landed on this issue after switching to net block. SSID and signal strength were not showing up. This made me think of switching to iwd somehow. Right now, I only have iwd + systemd-networkd on my system. No network manager and wpa supplicant. Both SSID and signal strength seem to be working.
Relevant output if it helps.
#: i3status-rs --version
i3status-rs 0.30.0 (commit 6510a913 2022-10-04)
#: uname -a
Linux core-endeavour 5.19.12-arch1-1 #1 SMP PREEMPT_DYNAMIC Wed, 28 Sep 2022 13:21:25 +0000 x86_64 GNU/Linux
#: iw dev wlan0 info
Interface wlan0
ifindex 4
wdev 0x2
addr 2c:db:07:58:f2:f5
ssid AsusAIMesh_5G
type managed
wiphy 0
channel 48 (5240 MHz), width: 80 MHz, center1: 5210 MHz
txpower 22.00 dBm
multicast TXQ:
qsz-byt qsz-pkt flows drops marks overlmt hashcol tx-bytes tx-packets
0 0 0 0 0 0 0 0 0
#: iw dev wlan0 link
Connected to 3c:7c:3f:62:f8:54 (on wlan0)
SSID: AsusAIMesh_5G
freq: 5240
RX: 723750259 bytes (502436 packets)
TX: 42856476 bytes (45997 packets)
signal: -66 dBm
rx bitrate: 585.1 MBit/s VHT-MCS 6 80MHz short GI VHT-NSS 2
tx bitrate: 650.0 MBit/s VHT-MCS 7 80MHz short GI VHT-NSS 2
bss flags: short-slot-time
dtim period: 3
beacon int: 100
With Network manager and wpa supplicant, interface name was wlp4s0 and now it is wlan0. Not sure if that makes any difference. iw dev wlp4s0 info was not showing SSID earlier.
Is there a workaround that can be implemented until the upstream bug is fixed? Or perhaps i3status-rust can incorporate a fallback method for obtaining this network information if the default method fails.
Is there a workaround that can be implemented until the upstream bug is fixed?
Yes, we can follow iw dev ... link and parse NL80211_BSS_INFORMATION_ELEMENTS. Or we can just parse the output of iw dev ... link. The first workaround is preferable, but the second is the easiest one.
Is anyone working on a fix for this ? @MaxVerevkin (Still hitting this issue on Kernel 6.0.x)
Is anyone working on a fix for this ? @MaxVerevkin (Still hitting this issue on Kernel 6.0.x)
I don't think anyone is working on this.
Is this even a problem with this repository? It works with kernel 5.15.74-1-lts and breaks with 6.0.2 on the exact same computer. Iirc, any changes in the kernel that break userspace are considered bugs.
So @msrd0 should we open a bug issue upstream on the kernel Bugzilla and link it here ??
Or report it to your distros bug tracker first
I think someone already did for arch Linux
So @msrd0 should we open a bug issue upstream on the kernel Bugzilla and link it here ??
I think this does make sense. This is clearly not a distro-specific bug but a change in the kernel API, so a upstream kernel bugzilla report should be the best way forward.
hello, i also want to say that after updating i also had the issue where neither SSID nor strength show up for i3status-rust
im using latest stable version of i3status-rust on void linux on swaywm
kernel is 5.19.16, wifi is configured using wpa_supplicant
the down and up speed indicators work tho
This appears to be the upstream kernel bug report (prompted by a similar network issue in another project):
https://bugzilla.kernel.org/show_bug.cgi?id=216711
This appears to be the upstream kernel bug report (prompted by a similar network issue in another project):
https://bugzilla.kernel.org/show_bug.cgi?id=216711
Thanks for finding this! They specifically talk about WPA3 though, but the problem we all are facing seems to be independent of the Wifi connection type. E.g. I have this problem on a WPA2 network. So is it really the same problem?
Although I can say that networkctl status wlp2s0 does indeed show (null) for me as well. edit: I don't use systemd-networkd but NetworkManager.
This appears to be the upstream kernel bug report (prompted by a similar network issue in another project):
https://bugzilla.kernel.org/show_bug.cgi?id=216711
I also have this problem but I'm not using systemd but network manager for connecting to wifi. nmcli is very well capable of displaying the SSID, but i3status-rust shows N/A.
@sebastianst and @msrd0 you're right. I hadn't thought about that. Perhaps this bug is related to the deeper issue going on in the kernel, but it is indeed not the specific source of what is going on with i3status-rust. I actually found a lot of networking bug reports for the new 6.x kernel series when I was looking for the one I linked to above. There must have been some significant network changes made to the kernel recently (with some oversight clearly included in those commits). Thus, the search for the offending kernel code is still on.