The home network, examined

I have a small... zoo of connected gadgets at home. Wifi mesh, smart speakers, smart lights, a robot vacuum, even the oven and the hob — and no real idea of what was actually talking to what. That is hardly unique: most Swedish households today have a plethora of connected devices, usually without anyone in the house having a full picture of what is actually connected. And who can reach it?

The point of this project was not to feed my paranoia, quite the opposite. It was to get three things straight: an overview of what is actually on the network, a list of what could simply be a bit better, and — most importantly — a clear line between that and what is actually a security issue.

So I asked Claude Code to build an audit: map everything, measure what the network actually delivers, and dig into the security. With clear ground rules — touch nothing, never guess a password, never send data anywhere beyond a MAC address lookup and my own public IP.

The result was a small dashboard of my own in plain Python without a single extra dependency, listening only on my own computer. It maps every device, measures throughput and latency live, and keeps an eye out for anything showing up that should not be there. Above all, it gives advice on what I can do.

The advice separates three levels: what actually needs fixing now (a backup that was never set up, a firewall that was off), what could simply be better (WPA2 instead of WPA3, no guest network), and what is already fine as it is. That division — not just a long list of scary-sounding things — is the whole point.

The most fun was when I tested the internet speed three times in one evening and got three different answers — 15, 94 and 805 Mbit/s download, on the same line, the same evening. The truth turned out to be the subscription I actually pay for, not any of the tests as such. A good reminder not to trust the first number that shows up, however impressive it is.

The page updates in real time, has a sharing mode that masks everything sensitive when I want to show it off, and always says clearly what is a fresh measurement and what is merely an assessment.

It is not something I monitor, but I still run it, mostly to double-check that I really did fix what it found.

Want to try something similar at home? Here is the prompt I actually used, shortened and generalised so it works for any home network — the same safety rules and structure, just without everything that was specific to my house.

Copy the text below and fire away.

Rules (most important — read before you start)

• My own home network only. If you see signs of a corporate or school network (domain login, management profiles, hundreds of devices), stop and ask before continuing.
• Read-only. Change no configuration. Write no file outside the project folder.
• No password attempts, no logins, no exploitation attempts. Noting that something answers without authentication is reconnaissance and fine. Logging in is not.
• No sudo/root.
• Send nothing off the machine except the MAC vendor lookup and a lookup of my public IP.
• Be gentle with the network — individual requests, not full port sweeps. Some IoT devices crash under heavy-handed scanning.
• Tell me what you are doing as you do it, with a rough time estimate.

What to examine

1. The network: interfaces, IP, gateway, DHCP, DNS, public IP, CGNAT, IPv6 (distinguish link-local/ULA/global). Ping the whole subnet to get silent devices into the ARP table.
2. The devices: look up MAC vendors, query mDNS/Bonjour for many service types (two rounds — sleeping devices get to answer on the second), SSDP/UPnP descriptions, light web-port knocking on unknown devices. Flag randomised (private) MAC addresses as exactly that, not as unknown devices.
3. Performance: measure idle latency BEFORE you saturate the link (otherwise you measure bufferbloat and think it is idle). Then throughput up/down, latency under load, packet loss, traceroute. Wi-Fi: channel, bandwidth, signal/noise, and a comparison with the neighbours' networks on the same channel.
4. Security: segmentation (can the devices reach each other freely?), device-by-device assessment of how long it will keep getting updates, IPv6 firewall status, UPnP and open ports, services without authentication, DNS (encrypted? filtered?), rogue DHCP/ARP anomalies, Wi-Fi security (WPA version, WPS, duplicate access points with the same name).
5. The computer you run from: firewall, disk encryption, which ports it listens on towards the network, sharing services, automatic updates, and whether backup is actually configured (not just "seems to exist").

Common pitfalls

• Match vendor names on word boundaries, otherwise "ring" inside a string matches a washing machine and you flag it as a camera.
• Tie every finding to the specific devices it concerns.
• Separate "not measured yet" from "not responding" in the interface.
• Never flag something harmless as a threat — shared MAC addresses are often a legitimate mesh system, not an intrusion. Check before you raise the alarm.

The dashboard

• A single language, standard library only, no external dependencies.
• Local server that ONLY listens on 127.0.0.1, never 0.0.0.0. Reject requests with the wrong Host header.
• Live updates (e.g. Server-Sent Events), everything bundled, works offline.
• Label every part of the interface as live, snapshot, or assessment — never unclear which.
• Never invent movement or data you have not actually measured.
• A sharing mode that masks public IP, MAC addresses, SSID and device names at the press of a button.

The analysis

Colour-code findings (red = fix, yellow = could be better, green = fine as it is — and say why). Each finding: raw data as evidence, what it means in practice, exactly what I do about it. Add a separate section for things I did not ask about but should think about (single points of failure, what happens in a power cut), an action plan sorted by benefit per effort, and a final section on what you could NOT see from here (the router's full config, devices that were off, etc).

Tone

Explain technical terms briefly the first time they appear. Be straight about what is bad without exaggerating. Assume I am not a network engineer.

Start the server and verify that it actually works before you say you are done.