Is your feature request related to a problem? Please describe.
Wifiscanner currently only returns a single channel number. This is not quite enough for "site surveys" (channel-picking), because WiFi channels overlap to variable degrees depending on the radio mode used.
For example, for the notoriously crowded 2.4 GHz, hotspots may decide nicely to use 20 MHz, though the more common default is 40-if-possible (and routers sure have a liberal definition of "possible"). Just knowing another hotspot is "channel 3" is not enough to ensure enough spacing for my 20 MHz "channel 7" hotspot, because it’s unknown whether the gentleman on 3 is 20-wide or 40-wide. (See also https://commons.wikimedia.org/wiki/File:NonOverlappingChannels2.4GHz802.11-en.svg)
Describe the solution you'd like
Wifiscanner adds a new field to the Wifi struct to indicate bandwidth. This is... easier said than done -- that's why all the site survey apps are system-specific and paid (or at least require registration).
On macOS, /blahblah/airport -s seems to already provide this information for 2.4G. For example, two of my neighbors' hotspots scan as channel 1,+1 and 6,-1. My fancy "Wifi Explorer" app says they are using 40 GHz: one starting from 1 and expanding up, the other starting from 6 and extending down. There is no similar indication for 5G, even though there are 80 MHz and 160 MHz hotspots around me.
On Windows, I am failing to find any of that indication for netsh. There is some neat information about channel utilization, but that's hardly relevant to our use case. I wonder what native API "inSSIDer" is calling for that.
On Linux,
2.4GHz stations with 40 MHz capabilities give a "HT20/HT40" readout in iw dev wlan0 scan, as far as I can tell. The "secondary channel offset" line corresponds to which way it extends.
5GHz stations might give its 160 capability in the VHT and HE sections, but the room my Linux box happens to be in is not in range of my neighbor's fancy 160 MHz hotspot.
Describe alternatives you've considered
Well, don't do it because it's out of scope. It might be. People will have to resort to system-specific ways of doing this stuff... which they already are. But on the other hand, some of that information is already in the output.
Additional context
Nothing for now.
Well, we also lack "maximum speed" indication, but that's also complicated:
Nothing on mac.
Windows has it, but it caps at 54.
Linux iw has it, but it caps at 54. It provides enough information about MAC and other weird things for you'd need to multiply the 54 into the real, actual maximum rate, but parsing it might be too much work.
Is your feature request related to a problem? Please describe.
Wifiscanner currently only returns a single channel number. This is not quite enough for "site surveys" (channel-picking), because WiFi channels overlap to variable degrees depending on the radio mode used.
For example, for the notoriously crowded 2.4 GHz, hotspots may decide nicely to use 20 MHz, though the more common default is 40-if-possible (and routers sure have a liberal definition of "possible"). Just knowing another hotspot is "channel 3" is not enough to ensure enough spacing for my 20 MHz "channel 7" hotspot, because it’s unknown whether the gentleman on 3 is 20-wide or 40-wide. (See also https://commons.wikimedia.org/wiki/File:NonOverlappingChannels2.4GHz802.11-en.svg)
Describe the solution you'd like
Wifiscanner adds a new field to the
Wifistruct to indicate bandwidth. This is... easier said than done -- that's why all the site survey apps are system-specific and paid (or at least require registration)./blahblah/airport -sseems to already provide this information for 2.4G. For example, two of my neighbors' hotspots scan as channel1,+1and6,-1. My fancy "Wifi Explorer" app says they are using 40 GHz: one starting from 1 and expanding up, the other starting from 6 and extending down. There is no similar indication for 5G, even though there are 80 MHz and 160 MHz hotspots around me.netsh. There is some neat information about channel utilization, but that's hardly relevant to our use case. I wonder what native API "inSSIDer" is calling for that.iw dev wlan0 scan, as far as I can tell. The "secondary channel offset" line corresponds to which way it extends.Describe alternatives you've considered
Well, don't do it because it's out of scope. It might be. People will have to resort to system-specific ways of doing this stuff... which they already are. But on the other hand, some of that information is already in the output.
Additional context
Nothing for now.
Well, we also lack "maximum speed" indication, but that's also complicated:
iwhas it, but it caps at 54. It provides enough information about MAC and other weird things for you'd need to multiply the 54 into the real, actual maximum rate, but parsing it might be too much work.