Network devices

The Network devices screen turns the app into a local‑network investigator: it lists the devices on your Wi‑Fi, lets you ping any one of them, and scans its ports to see what it exposes. It’s the natural companion to the Wi‑Fi radar when something on the network “feels off”.

Open it from the dashboard’s overflow menu (⋮ → Network devices). You need to be connected to Wi‑Fi — on mobile data there’s no local network to explore.

Discovering devices

When the screen opens it sweeps your Wi‑Fi subnet and merges several discovery methods so it finds and names as much as possible:

a fast parallel reachability sweep (ping plus TCP probes) across every address in the subnet;
mDNS / DNS‑SD (Bonjour) — Apple devices, Chromecast, printers, smart‑home kit;
SSDP / UPnP — routers, TVs, hubs such as a Hue bridge;
NetBIOS — Windows PCs and some NAS units.

Each device shows its IP, a name where one can be found, reachability latency, and tags for This device and Gateway. The header reads e.g. “9 devices · 254 addresses scanned” so the count is clearly the number of real devices, not the size of the subnet.

Names

Names come from whatever a device advertises over mDNS/SSDP/NetBIOS. Where a device only exposes a model code (for example a Hue bridge reporting BSB002), the app substitutes a friendly product label inferred from the service type — so you see “Hue Bridge” rather than the part number.

What we don’t show: MAC address and vendor. Some tools list a hardware MAC and vendor (“Apple”, “TP‑Link”). Modern Android (10+) restricts ARP, so a remote device’s MAC isn’t reliably available to an app. We deliberately show what we can obtain robustly — IP, name, reachability and latency — rather than promise vendor labels we can’t always deliver.

High vs low confidence

Some networks — particularly phone hotspots and certain routers — answer on behalf of every address in the subnet, which can make a network look like it has hundreds of devices. To keep the list honest, the app shows high‑confidence devices by default: anything that is named, has an open port, answered a ping, or is your phone or the gateway. The ambiguous remainder (addresses that only sent a bare TCP reset) are tucked behind a “Show N more (low confidence)” row, so nothing is hidden but the default view matches reality.

Pinging a device

Tap a device, then Start ping. You get continuous latency with last / average / minimum / maximum and packet‑loss figures. It uses TCP‑connect timing, so it still works against devices that block ICMP echo.

Scanning ports

On the device detail screen, choose Quick scan (a curated list of common ports) or Full scan (all 65,535). Open ports are listed with best‑effort service names.

A one‑time notice asks you to only scan networks you own or are permitted to test — port scanning can trigger intrusion‑detection alerts on networks you don’t control. Closed ports that actively refuse are scanned quickly; hosts that silently drop traffic (firewalled) make a Full scan slower, since each such port has to wait for a timeout.

What gets logged

The network tools are interactive and on‑demand — discovery, ping and port‑scan results are not written to the JSONL session log, so they don’t affect your drive‑test captures. (By contrast, the serving‑Wi‑Fi measurements — channel width, utilisation, MIMO estimate and Wi‑Fi standard — do flow into the log; see the Wi‑Fi metrics reference.)

Caveats

Wi‑Fi only — there’s no local network to sweep on mobile data.
Multicast — mDNS/SSDP rely on multicast; a few access points block client‑to‑client multicast, which can limit naming on those networks.
Proxy‑ARP networks — if a network answers for every address, lean on the low‑confidence toggle to separate real devices from the noise.