soumya92
Feature request: RSSI for wlan module
Hi,
does anybody else miss signal quality value of wireless connection, in current wlan module? I find it quite common and practical, almost every status indicator AFAIK does support it (xmobar, i3status-rs), even original i3status from i3wm project itself.
Currently, wlan module uses netlink watcher to monitor changes on an interface(in Linux) to update its info. I didn't yet found equivalent watchdog API for signal strength changes. Doubt there is even any as it is a quite frequent event. I wrote a quick-hack solution using timing.Scheduler feeding linkSub.C channel in a given interval, like 5 seconds, to update status info.
Current Signal Level can be retrieved from iwconfig output (part of wireless_tools package like iwgetid), or from /proc/net/wireless virtual file, or even better from wifi client's StationInfo struct. RSSI is then calculated by linear interpolation, ie. 2 * (SignalLevel + 100) .
What approach would you suggest to implement above feature to fit best in current wlan module and for barista architecture?
I think the quickest solution for you here would be to maintain a wifi client in the main bar binary, and in the output func for the wlan module, fetch rssi from this client and then return a repeating output so that refreshed automatically. You can pick your polling frequency there, without requiring more config options on the wlan module.
The issue is that currently wlan module is very push-based, with no changes unless there is a meaningful change to the state. With RSSI varying wildly under normal operation, that would force us to switch to a polling model for wlan, and this inconsistency could be problematic later.
wlan already uses iwgetid for channel/frequency info, so adding rssi there is not a big deal. The problem is entirely around refreshes, since currently a stable connection would mean no work done by this module, but for rssi it would need to poll. I don't have a good solution, but I'll keep thinking about it
Thanks for the comprehensive reply.
I do appreciate push-based model of barista and can understand adding a polling--based feature would ruin it.
I've just discovered what I've been thinking as unlikely possible, is actually a part of Linux kernel API:
nl80211 signal strength minimal threshold attrs
Not sure how widely this is supported across various drivers, but that would be the solution - lightest on resources while kept push based. Would play with that for a while and see if I can bring some clean & reliable implementation.
I would also suggest stop relying on external programs and retrieve information directly from the OS when possible as the way to go..