Wi-Fi network tools — feature brief
Feature set: local-network diagnostics (device discovery → ping → port scan) plus richer serving-Wi-Fi metrics. Inspired by WiFiMan. Status: Exploration / design. Not started. Home: the Wi-Fi data menu / workspace — not iPerf. iPerf is throughput-to-a-server; these are Wi-Fi/LAN-domain tools and belong with the Wi-Fi radar and Wi-Fi status.
1. What it is and why
When the Wi-Fi “feels bad”, users want to investigate locally: is the router/NAS/printer reachable? what’s the latency to it? what’s it exposing? how busy is the channel? This adds:
- A. LAN device discovery — list the devices on the current network.
- B. Per-device ping — latency / jitter / loss to a chosen device.
- C. Port scan — what’s open on that device (fast, all-ports).
- D. Richer serving-Wi-Fi metrics — channel width, channel utilisation, MIMO/spatial streams (things WiFiMan shows that we don’t yet).
A–C are interactive/ad-hoc (run on demand, save/share the result) — they do not touch the v3 per-tick log. D is continuous measurement and flows through the normal metric pipeline + v3 log.
2. Information architecture (placement)
Group everything under Wi-Fi, alongside the existing radar:
- Wi-Fi status (existing
wifi.status) — enhanced with width / utilisation / MIMO (feature D). - Wi-Fi radar (existing
wifi.neighbours) — unchanged. - Network devices (new) — the LAN device list; tap a device → Ping and Port scan.
So the user finds it where they’re already looking at Wi-Fi, not buried in the testing/iPerf flow.
3. Feature A — LAN device discovery
Combine three discovery methods and merge results by IP:
- Subnet sweep — read IP + prefix from
LinkProperties; probe every host in the /24 in parallel (TCP-connect to a common port and/or ICMP). Reachable = a device. Fast when parallelised. - mDNS / DNS-SD (
NsdManager) and SSDP/UPnP multicast — pick up devices that advertise friendly names/services (Chromecast, printers, NAS, routers). - Reverse DNS / NetBIOS — best-effort hostnames.
Show per device: IP, hostname/mDNS name (if any), reachable + latency, and tags (“This device”, “Gateway”).
The honest parity gap with WiFiMan — MAC & vendor. WiFiMan shows MAC + vendor (“Apple / TP-Link”). On modern Android (10+), ARP is restricted (/proc/net/arp no longer readable by normal apps) and you can’t get a remote host’s MAC without it — so the polished vendor list isn’t reliably reproducible. We can show IP / name / reachability / latency robustly; MAC/vendor only opportunistically (e.g. gateway). Set this expectation rather than promising vendor labels we can’t always deliver.
4. Feature B — per-device ping
- ICMP via the system
pingbinary (Runtime.exec("ping -c …")), parsed for min/avg/max/loss — works without root (raw-socket ICMP would need root). - TCP-connect time to a known-open port as a complement — survives ICMP-blocking devices and reflects “can I actually reach the service”.
- UI: live latency + jitter + loss with a sparkline; continuous or fixed-count.
5. Feature C — port scan (fast, all-ports)
WiFiMan scans the full range quickly, and that’s reproducible: a TCP connect scan with high concurrency + short timeouts. On a low-latency LAN, all 65535 ports finish in seconds.
- Engine: non-blocking sockets via a
java.nioselector (scales to thousands of in-flight connects efficiently), or coroutines bounded by a large semaphore. Short connect timeout (~200–500 ms). Cancellable. - Modes: Quick (curated common-ports list — 22, 80, 443, 8080, 445, 139, 21, 23, 3389, 5000…) and Full (1–65535). Default Quick; Full one tap away.
- Result: open ports + best-effort service names; closed/filtered collapsed.
- UDP scanning is unreliable — omit or mark experimental.
Ethics gate: port scanning can trip IDS on networks you don’t own — show a one-time “only scan networks you control” notice, and keep concurrency tunable so we don’t hammer fragile gear.
6. Feature D — richer serving-Wi-Fi metrics
These are continuous; they extend the existing Wi-Fi status and ride the normal metric pipeline / v3 log (new keys or extra wifi.status rows). Feasibility varies — be honest per metric:
| Metric | How | Feasibility |
|---|---|---|
| Channel width (20/40/80/160 MHz) | ScanResult.channelWidth for the connected BSSID | Good (API 23+) |
| Channel utilisation (airtime %) | Parse the BSS Load information element (id 11) from ScanResult.informationElements | Moderate — API 30+, only where the AP advertises BSS Load |
| MIMO / spatial streams (e.g. 2×2) | Not directly exposed; infer from Wi-Fi standard + max supported link speed (getMaxSupportedRx/TxLinkSpeedMbps, API 30+) vs per-stream rate | Approximate — present as “estimated”, not exact |
| Wi-Fi standard (4/5/6/6E) | WifiInfo.getWifiStandard() | Good (API 30+) |
Channel width and standard are easy wins; utilisation is a real win where APs support BSS Load; MIMO is an honest estimate. These slot straight into the existing Wi-Fi status tile and the v3 log as additive metrics — no schema disruption.
7. UX / screens
- Network devices screen (in the Wi-Fi workspace): scanning progress + device list; pull-to-refresh; tags for gateway/self.
- Device detail: ping panel (live) + Quick scan / Full scan buttons + open-ports list; Save / Share the result (via the existing share sheet).
- Wi-Fi status tile: add width / utilisation / standard / estimated MIMO rows.
8. Libraries / APIs
| Need | Choice |
|---|---|
| Subnet / gateway | ConnectivityManager + LinkProperties (DhcpInfo deprecated) |
| Service discovery | NsdManager (mDNS) + SSDP multicast |
| Ping | system ping binary via Runtime.exec + TCP-connect timing |
| Port scan | java.nio selector (or bounded coroutines) — no external dep |
| Wi-Fi details | WifiManager / WifiInfo / ScanResult (+ IE parsing for BSS Load) |
| Service-name / OUI lookups | small bundled tables (best-effort) |
No heavy dependencies; it’s standard Android networking.
9. Logging
- A–C (LAN tools): interactive, not per-tick logged — results are saved/shared on demand. Keeps the v3 pipeline untouched.
- D (Wi-Fi metrics): additive metrics through the existing pipeline + v3 log (e.g.
wifi.channel_width,wifi.utilisation,wifi.spatial_streams,wifi.standard) — NUMBER/TEXTValueKind, no schema break.
10. Effort, risk, phasing
Low-to-moderate effort, low risk, well-understood tech — a strong quick win vs the indoor survey’s research-grade build.
- Phase 1: subnet sweep + device list (IP/name/latency) → device ping → Quick port scan. Save/share.
- Phase 2: Full (all-ports) scan with NIO + concurrency tuning; mDNS/SSDP enrichment; service names.
- Phase 3 (parallel/independent): serving-Wi-Fi metrics D (channel width + standard first; utilisation via BSS Load; estimated MIMO).
D is independent of A–C and could ship on its own as a small, satisfying Wi-Fi-status upgrade.
11. Caveats
- MAC/vendor not reliably available on modern Android (the main WiFiMan parity gap) — manage expectations.
- Port-scan ethics/IDS — gate with a clear notice; tune concurrency.
- BSS Load / MIMO are AP-dependent / inferred — label honestly (consistent with our “no false precision” ethos).
- Battery/time on full sweeps + full-port scans — parallelise, cap, allow cancel.