# Vernet: a Flutter network scanner for the devices on your own Wi-Fi

> Vernet is a Flutter app that maps the network you are sitting on, listing devices, pinging hosts, scanning ports, running DNS lookups and a speed test, and it ships for Android, macOS, Linux and Windows. It is for checking a home or small office network, not for auditing someone else's.

**osociety/vernet** — Cross platform network analysis and monitoring tool 

- Repository: https://github.com/osociety/vernet
- Website: https://vernet-app.web.app
- Stars: 557 · Forks: 51
- Language: Dart
- License: Apache-2.0
- Published: 2026-10-22 · Updated: 2026-10-22 · Language: en
- Canonical page: https://hysenlabs.com/projects/osociety-vernet

## What Vernet is built to answer

The tagline is short: Know your network. The description calls it a cross platform network analysis and monitoring tool, and the eight numbered features in the README define the scope precisely.

The first feature is the local network identity: your Wi-Fi name, BSSID, local address, gateway and subnet. The second is finding devices connected to your local network, including automatic scans when the app opens. The third is checking whether a website or device responds with ping, even without internet access, which is a deliberately narrow and practical claim. The fourth is scanning popular ports, a custom range or a single port for reachable services. The fifth is forward and reverse DNS lookups. The sixth is a download and upload speed test. The seventh is your public IP and internet provider information. The eighth is the settings surface: internet access, location permission, scan ranges, ping count and timeouts.

What is not in that list is the giveaway. There is no exploitation, no credential testing, no packet capture and no report generation. Every item is a reachability or identification question.

The README states its own limits in a way that is worth repeating, that Vernet helps you spot possible connection and security concerns, that it does not replace a professional security audit, and that it gives you useful findings to review, such as devices and services that are reachable on your network. That is an accurate description of what a consumer network scanner is, and the screenshots table shows the shape of the output, with pages for Home, Connected Devices, Security Findings, Ping, DNS, Speed test and Settings.

The primary language is Dart, the licence is Apache-2.0, and the repository is built on the Flutter tooling, with per-platform directories for android/, ios/, linux/, macos/, windows/ and web/. The web directory exists in the tree but the README states that web is not currently supported, and the download table lists iOS as coming soon.

## The device discovery mechanism, and why the Linux install step matters

The device list is the feature people use Vernet for, and the mechanism behind it is what the platform support tells you about.

On a local network, finding other hosts is a matter of asking the gateway which devices it has seen, and on Linux that means the arp command. The README makes this dependency explicit in the Linux install instructions: install the net-tools package for the arp command, otherwise app will not run. That is an unusually honest statement of a hard requirement, and it is the kind of detail that separates a tool that works from one that silently shows an empty list.

```bash
sudo apt install net-tools
```

The net-tools package provides arp, and arp is what the device table is built from. The cache it returns is the neighbour table, which is why the device list is a statement about who has talked to your gateway recently rather than a guaranteed inventory of everything on the segment. A device that has been idle for longer than the neighbour table timeout will not appear, and a device that is present but has never communicated with your gateway will not either.

This is also the reason the settings screen exposes scan ranges. A device sitting on a different subnet is reachable but not in the local neighbour table, and scanning a wider range is how you would look for it.

The ping feature, which the README frames as checking whether a website or device responds with ping even without internet access, works against the local subnet without needing a name server or a route to the wider internet. The DNS section sits alongside it and does forward and reverse lookups, so you can turn an address into a name and a name back into an address.

The location permission in the settings is not for the scanning itself. It is because the Wi-Fi name and BSSID come from the platform's Wi-Fi API, and on Android that API requires a location permission, so a scanner that reports your SSID needs it even though it never moves.

## Port scanning, in three granularities

The port scanning feature is described with three levels of specificity: scan popular ports, a custom range, or a single port for reachable services. Three separate modes for one operation is a design choice, and it maps onto three different questions.

Popular ports answers the general one: what is exposed here that people normally expose, a web server, an SSH daemon, a file share, a printer. A custom range answers the targeted one, usually because you know something runs in a particular range and you want to see whether the service is there. A single port answers the diagnostic one, confirming that a port you have been told about is listening before you spend an afternoon chasing a firewall rule.

The custom range is the feature with the sharpest edge. A range scan on a large subnet is a lot of connection attempts, and the settings let you control the timeouts and the scan range, which is how you keep a broad scan from becoming a slow one. The scan ranges setting is not decoration; it is the difference between a targeted check and a sweep.

The Security Findings page is where the results of this and the device list converge. The README frames the output as things to review, such as devices and services that are reachable on your network, and the name of the page is a deliberate step short of calling them vulnerabilities. A service listening on port 22 is not a finding on its own; it becomes a finding when it is a service you did not expect on a device you do not recognise, and the app's job is to put those two facts next to each other.

The practical limit here is that reachability is not access. A closed port and an open port with a strong password look identical from outside, so a scan narrows the list of things worth attention rather than producing a verdict.

## Installing on each platform, and the rough edges

The download table lists five platforms and delivers four of them. Android comes from F-Droid and Google Play, macOS and Windows come from GitHub Releases as zip archives, Linux comes from the Snap Store, and iOS is marked as coming soon.

The macOS path is the one with a documented workaround. The README notes that the macOS build hasn't been notarized yet, and then walks through the manual override: download vernet-macos.zip from releases, extract it, copy the app to the Applications folder, then press cmd and left click on the app, and in the context menu click open. That bypasses Gatekeeper's block on unsigned builds, and it means every macOS user has to do this the first time.

```bash
wget https://github.com/osociety/vernet/releases/latest
```

Windows has a similar two-step. Download vernet-windows.zip from releases, extract it, run vernet.exe, then click on more info and tap on Run anyway, and give permission if asked. The SmartScreen warning on an unsigned executable is expected, not a sign of a bad download.

```bash
./vernet
```

Linux is a Snap, which handles the arp dependency path differently since the net-tools package is what the README tells you to install. It also says to go to the bundle folder and double click the vernet file, which is a slightly awkward instruction for a Linux desktop.

```bash
./vernet
```

Android is the smoothest path, since F-Droid and Google Play handle updates and the platform permissions are requested through the normal app flow. The F-Droid listing uses the package id org.fsociety.vernet, and the Play listing uses org.fsociety.vernet.store, which is a detail worth noting if you are automating a fleet install, since the identifiers differ between the two stores.

The archive names being documented individually is worth flagging for anyone automating installs, because the asset naming is what a provisioning script would have to match.

## Version scheme, release pace and the state of the project

The release numbering is unusual and worth understanding before you pin anything. The recent releases are v1.4.9+66, v1.4.8+65 and v1.4.7+64, all within a day and a half of each other in October 2026, and the last push was on 2026-10-20.

The trailing number after the plus sign is a build counter that increments on every release, so the semantic part of the version, 1.4.7 through 1.4.9, moves slowly while the build number moves fast. The consequence for an adopter is that many releases are essentially the same feature set, and a version comparison tool that only looks at the semantic part will see little difference between builds that are several hundred apart.

The pace itself is the headline: three releases on 2026-10-19 and 2026-10-20, on a repository that is not archived. This is an actively maintained project, and for a consumer app that is mostly what you want, since the network APIs it depends on change between OS versions and the maintainer has to keep up.

The repository layout gives a sense of the engineering setup. There is an ARCHITECTURE.md, an AGENTS.md, a repo-map.yaml, an analysis_options.yaml for the Dart analyser, a devtools_options.yaml, an android_integration directory, an integration_test/ directory, a test/ directory, a generate_coverage.sh script, a snap/ directory for the Snapcraft package, an installers/ directory and a fastlane/ directory for the Android release metadata. The codecov badge in the README indicates coverage is tracked.

The Apache-2.0 licence is the permissive end of the scale, so embedding the code in a commercial product is not a licensing obstacle. It is worth noting the project asks for support rather than selling anything: the README lists a Librepay donation link, a Ko-Fi link and a request to rate the app on Google Play. Those donation and rating requests are the project's actual funding model, and that is worth knowing if you plan to rely on it.

## Where it is the wrong tool

There are three limits, and the first is the one the project itself states plainly.

The first is scope. Vernet is not an audit tool, and the README says so. There is no vulnerability scanning, no configuration analysis, no service fingerprinting beyond what a port number and a banner tell you, and no reporting you could hand to an auditor. If your goal is to find out whether your network meets a standard, you need a tool built for that, and this one will tell you which ports are open without telling you whether that matters.

The second is that it only sees the network you are on. The device discovery depends on the local neighbour table, so a device on another VLAN, behind a router that does not proxy ARP, or on a wireless network that isolates clients will not appear. The scan ranges setting widens the search but does not defeat network segmentation, which is exactly the case where you most want to know what is there. Any claim about the network beyond the segment should be treated as unknown.

The third is that the results depend on the platform underneath, and the platforms are not equivalent. On macOS the app is not notarized, so it requires a manual override that a non-technical user will struggle with, and on Linux it requires net-tools to be installed or the device list is empty. On Android it is a normal store install with no caveats. That gradient is fine for a self-serve tool and awkward for a deployment across a team, especially since the mobile app is the smoothest path and the desktop apps are the roughest.

The honest alternative depends on the question. For a scripted, repeatable inventory of a network you administer, the usual choice is a command-line tool run over SSH from a machine on that segment, which has no GUI overhead, produces output you can diff between runs and does not require a user to keep an app open. For the reachability questions specifically, the ping and port scan that Vernet performs are a subset of what a general network scanner does from the command line. What Vernet adds is presentation: a device list, a security findings page and a speed test on one screen, which is the better interface when the person holding the phone is not the person who administers the network.

## Conclusion

Adopt Vernet if you want a quick read on the network you are on, especially the devices you did not install yourself, since the automatic scan on launch and the port checks cover that case well. Do not adopt it as a professional audit tool, because the README itself says it does not replace one. Before you rely on it, install the net-tools package on Linux so the arp command is available, and note the macOS build is not notarized yet, so it needs a manual override on first launch.

## FAQ

### What is Vernet and which platforms does it run on?

Vernet is a Flutter app for network analysis and monitoring, available on Android through F-Droid and Google Play, on macOS and Windows from GitHub Releases, and on Linux from the Snap Store. iOS is listed as coming soon and web is not currently supported.

### How do I install Vernet on Linux and why do I need net-tools?

Install the net-tools package for the arp command, otherwise the app will not run, because the device list is built from the arp neighbour table. The README then directs you to download vernet-linux.zip from releases and run the vernet file from the bundle folder, and a Snap Store build is also listed.

### Why does the macOS version of Vernet need extra steps to open?

The macOS build has not been notarized yet, so Gatekeeper blocks it on first launch. The documented workaround is to download vernet-macos.zip, extract it, copy the app into the Applications folder, then press cmd and left click on the app and choose open from the context menu.

### What can Vernet scan on a network?

It finds devices connected to your local network with automatic scans when the app opens, pings websites and devices, scans popular ports, a custom range or a single port for reachable services, performs forward and reverse DNS lookups, tests download and upload speed, and shows your public IP and internet provider information.

### Is Vernet a replacement for a professional security audit?

No, and the README states that directly. It helps you spot possible connection and security concerns and gives findings to review, such as devices and services that are reachable on your network, but it does not replace a professional security audit.

## Sources

- [License: Apache-2.0](https://github.com/osociety/vernet/blob/main/LICENSE)
- [osociety/vernet on GitHub](https://github.com/osociety/vernet)
- [Project website](https://vernet-app.web.app)
- [README](https://github.com/osociety/vernet/blob/main/README.md)
- [Releases](https://github.com/osociety/vernet/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/osociety-vernet