Background

@worr did great work on this PR #11 unfortunately because of my tardiness, the PR fell behind recent changes. We need someone to resume their great work and get OpenBSD support.

Acceptance Critieria

• Must pass the checks for the GitHub Workflow CI (we're going to phase out support for Travis CI).
• Add tests that don't require OpenBSD, alternative update the GitHub Workflow CI to include OpenBSD in the build matrix

Given : User is on linux, has no root privilege, has iw installed
When : User ask for scan
Then : User receive an empty list.

Expected behaviour : a specific error is returned.

iw require specific permission to launch scan subcommand.
quickfix suggest : after sending iw scan command, check exit status. It's 0 when scan has been operated properly and 255 when there is insuficient permission.

I have tried to run the example and the wifiscanner::scan() returns OK() without any vector WiFi type.

Also, I share the version of the iw tool is based this crate.

Does anyone can help me? 😃

Tried this on Linux (which I since figured is not meant to be supported yet), but the failure mode is a panic. I noticed that all operations which may fail are unwrap'd.

Would be nice to have a wifiscanner::Error type and return a Result<Vec<Wifi>> instead.

(thanks for the crate, hope to get this on Linux!)

#27

The only thing I can see is that that the PR author committed their changes directly to the master branch on their fork.

http://doc.crates.io/manifest.html

Hi there! Hope you are all well!
I stumbled over a very stupid problem/bug... for Windows (in my case win 10) this crate doesn't work but i want to fix it with your permission ;)

Trying to create something platform independent is hard. Fighting with the stupidity of windows is worst ;)
One of my test-setups is win10 and set to German language... and your crate cannot find ANY wifi. I Found the problem by comparing the output of netsh and the searched keywords in your crate and... TADA: win10 is shipped with a german version of netsh?!

I am refactoring your regex and creating a pull request

sincerely

Felix

Acceptance criteria

• Create a separate workflow called markdown.yml do not use an existing workflow if found.
• Call this workflow (if possible) from the main workflow CI.yml
• Bonus: if you can find a GitHub Action that does linting i.e. make sure it's valid Markdown/HTML. Doesn't need to be the same Action that does link checking.

Bit chonky, at the moment, there's some prior work suggested by #13, but will need some merging by hand because of v0.4.0 changes.

Acceptance criteria (please create a child issue for the module you’re working on and reference this as this tracking issue)

• macOS as a separate module
• linux as a separate module
• tests still passing

Related issues

• #5

Using iwlist scan

if you can help please attach sample output (as text no images) as a comment.

This library seems pretty old and untouched for years - but still works and does what I want (I would in fact prefer calling into libraries via FFI rather than a Command, but that's a different topic and probably not easy) - I was wondering would you be open to a PR to add the feature described below.

Is your feature request related to a problem? Please describe.
I would like to know which SSID in the list returned is the one currently being used.
I know there maybe corner cases that complicate it, but I don't care too much about those and what the "airport" returns is good enough for me.

Describe the solution you'd like
Add a field in the Wifi struct returned to indicate if that wifi (SSID) is the one currently being used, as reported by invoking "airport" command (on MacOS) with "-I" option (older versions had a "ssid" option I think).

On linux I don't know the equivalent, but hope it could be found

Describe alternatives you've considered
These alternatives would also be fine and in fact this first one maybe better - unless we could get the info in just one Command invokation, saving time.

• A separate function in the library in addition to scan()
• return a struct with the SSID name plus a vec or wifis in the scan() command

Hint: the URL format is https://github.com/<user>/<repo>/workflows/<name of workflow>/badge.svg

Acceptance criteria

• does not break the build (the CI GitHub Action Workflow)
• does not change the formatting of the README.md dramatically i.e. no auto-formatting, please

I will provide guidance and help (including how to use Git and/or GitHub) just @ me.

Recommend implementing Clone for Wifi. I'm having to create my own struct that copies data from this one instead.

#29

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.

Operation System: Pop_OS!

Download the repo and cargo run --example scan

It would be great if this crate contained a binary file that could be called from the commandline.
As a first step, we could use the example here and put that into src/bin/main.rs. This way, users could simple cargo install wifiscanner and call wifiscanner to get a list of networks.

No longer need to rely on 3rd party services like Travis, create a separate workflow file called ci.yml do not use any existing workflow if found.

See:

• https://github.com/actions-rs
• https://dev.to/booyaa/github-actions-rust-edition-46e5

Acceptance criteria

Runs the following cargo commands on Linux and macOS (-latest virtual environment is sufficient)

• check
• fmt
• test
• clippy

Background

Here's what the generic GitHub Open Graph logo looks like in Twitter:

Basically new users of wifiscanner have to endure my face to use the software. 😭

Let's give them something different!

Acceptance criteria

• Images should be at least 640×320px (1280×640px for best display).
• The visual theme can be around: WiFi, wireless access points, scanning, war driving, crabs, rustl(and) related
• Graphics are optional, a snazzy looking logo would suffice.
• Does not breach anyone's copyright, if in doubt provide a link to the reference material so we can make a call.

Taken from the GitHub settings section for "Social Preview", you can use this template to ensure the image doesn't get cropped: template

Acceptance criteria

• must be part of the existing CI GitHub Workflow
• should use GitHub Action secrets (no hard coding of API token)
• should generate GitHub releases

I'll need to work with you to add the secret token, so please @ me when you're ready to test

Right now wifiscanner::Error does not implement std::error::Error. There is no reason why it couldn't and it would help interoperability with other crates.

It looks like this is licenced under Apache 2.0, but Cargo doesn't pick up on it unless specified in the manifest. That's why it shows up as "license: non-standard" on crates.io . You may want to add a

license = "Apache-2.0"

or (for GPL compatibility):

license = "MIT/Apache-2.0"

under the [package] section in Cargo.toml.

• Write contribution guide
• Reference in README
• Create Makefile to simplify checks before submitting code

I was using 0.5.1 and tried to the example code

use wifiscanner;

fn main() {
    println!("{:?}", wifiscanner::scan());
}

and got the output

Ok([])

(while I know it can scan some APs)

So I started to look at the code and it looked good
then I cloned the repo and run the example code and got different (the expected one)

Err(CommandFailed(ExitStatus(ExitStatus(65280)), "command failed: Operation not permitted (-1)\n"))

So 0.5.1 has a bug that is fixed at main branch

This error seems to have appeared, since I upgraded to macos Sonoma 14.4.1

cargo run --example scan
warning: An explicit [[bin]] section is specified in Cargo.toml which currently
disables Cargo from automatically inferring other binary targets.
This inference behavior will change in the Rust 2018 edition and the following
files will be included as a binary target:

* /Users/andrew/workspace/wifiscanner/src/bin/main.rs

This is likely to break cargo build or cargo test as these files may not be
ready to be compiled as a binary target today. You can future-proof yourself
and disable this warning by adding `autobins = false` to your [package]
section. You may also move the files to a location where Cargo would not
automatically infer them to be a target, such as in subfolders.

For more information on this warning you can consult
https://github.com/rust-lang/cargo/issues/5330
warning: path `/Users/andrew/workspace/wifiscanner/src/bin/main.rs` was erroneously implicitly accepted for binary `wifiscanner`,
please set bin.path in Cargo.toml
    Finished dev [unoptimized + debuginfo] target(s) in 0.01s
     Running `target/debug/examples/scan`
Err(HeaderNotFound("BSSID"))

uname -a
Darwin amackenz-mac 23.4.0 Darwin Kernel Version 23.4.0: Fri Mar 15 00:12:49 PDT 2024; root:xnu-10063.101.17~1/RELEASE_ARM64_T6020 arm64

Tests pass though, so maybe if we do find a bug on this version we need to add a test also.

using netsh.exe wlan show networks mode=Bssid

if you can help please attach sample output (as text no images) as a comment.