DEV Community: DeviceShelf

Who Is on My Wi-Fi? See Every Device and Spot Intruders

DeviceShelf — Wed, 19 Aug 2026 16:30:53 +0000

To see who's on your Wi-Fi, open your router's admin page and look at its connected-devices list, or run a network scanner that pings every address on your subnet. Each entry shows an IP, a MAC address, and often a hostname. From there you match each device to something you actually own, and whatever's left over is worth a closer look. If one of those leftovers turns out to be real, changing your Wi-Fi password disconnects everyone at once.

Start with your router's device list

Type your router's address into a browser (often 192.168.1.1 or 192.168.0.1, printed on a sticker on the box). Log in, then find a section called Attached Devices, DHCP Clients, or Connected Devices. You get a table of everything the router has handed an address to: IP, MAC, and sometimes a name.

This is the fastest free check, but router lists have limits. They often miss devices on a guest network or a second access point, they drop stale entries slowly, and the names are frequently blank or cryptic.

Read the MAC address and vendor (OUI)

Every network device has a MAC address, six pairs of hex like a4:83:e7:2b:19:0c. The first three pairs are the OUI (Organizationally Unique Identifier), assigned to the manufacturer. a4:83:e7 maps to Apple, for instance. Look the prefix up in any OUI database and an anonymous row becomes "some Apple device."

Vendor alone rarely finishes the job. A house full of Apple gear turns into a wall of "Apple, Apple, Apple," and you still have to work out which entry is the iPhone and which is the Apple TV.

Get real names with hostnames and mDNS

Hostnames close some of that gap. Many devices announce a name over DHCP or mDNS/Bonjour, like Christofs-MacBook or living-room-tv. NetBIOS does the same on older Windows networks. A scanner that queries all three resolves far more names than the router shows on its own.

Why randomized MAC addresses confuse things

Since iOS 14, Android 10, and recent Windows builds, phones use a random MAC per network by default, and some rotate it over time. The upside is privacy. The downside for you is that a phone can show up under a vendor prefix that no longer maps to its maker, and a device you already trust can look brand new after a rotation.

This is also the wrinkle most likely to fake an intruder. Before you assume the worst, test it directly: turn Wi-Fi off on a phone you suspect and watch whether the mystery entry disappears. Look at the vendor too. A randomized MAC often reads as "locally administered" or an unknown vendor rather than a clean Apple or Samsung block. And if an entry only shows up when one particular family member is home, it is theirs.

The broader fix is to match on hostname and behavior rather than MAC alone, and to name devices in a tool that remembers them across scans, so a rotated address doesn't reset your whole inventory. If the randomization itself is what puzzles you, we've covered why your phone shows a random MAC address separately.

Name everything in one pass with a scanner

Doing all of the above by hand is slow. A scanner sweeps the whole subnet, collects MAC/OUI vendor, hostname, an OS guess, and open ports, then hands you one labeled inventory. nmap does this from the command line (nmap -sn 192.168.1.0/24 for a quick host sweep). GUI tools do the same with less typing.

DeviceShelf is one such scanner. It discovers every device on your LAN or Wi-Fi, identifies each by vendor, hostname, and type, and lets you rename and pin the ones you recognize so the list stays meaningful next time. It runs locally, with no account and no data leaving your machine, which is why people looking for a private alternative to Fing tend to land on it. If you're weighing tools, our comparison of network scanners shows where each one fits.

Match every device against hardware you own

Now the tedious but decisive part. Walk through the place and count: phones, laptops, tablets, the TV, a streaming stick, the console, printer, robot vacuum, smart plugs, thermostat, doorbell, speakers, the router itself, and any range extenders. Write them down, then cross each one off the scan.

The MAC vendor is your best clue here. A prefix that resolves to Amazon is probably an Echo or Fire TV. Espressif or Tuya usually means a cheap smart-home gadget. Apple, Samsung, and Google cover most phones and laptops. Line up hostnames where you can. Smart-home gear is the hardest group to pin down, so there's a separate walkthrough on finding IoT devices on your network.

Once every entry is named, the unknowns stand out. Go one by one: power a suspect device off and see which row drops, or check the vendor against what you own. A camera vendor you don't recognize, an open Telnet port, or a host that only appears at odd hours all deserve a second look. Open ports are worth understanding before you judge them, and our guide to what an open port actually means covers which ones matter.

What to do if someone really is on your Wi-Fi

If a device survives all of that and you're confident it isn't yours, the fastest fix is to lock everyone out and let your own gear back in.

Change the Wi-Fi password. This kicks every device off instantly, the intruder included, and they can't rejoin without the new key. Reconnect your own hardware afterward.
Switch to WPA3, or at least WPA2-AES. Never run WEP or an open network. WPA3 makes offline password guessing far harder.
Disable WPS. Its 8-digit PIN is brute-forceable and a well-known way in.
Move IoT gadgets to a guest network. A cheap camera with weak firmware has no business sharing a subnet with your laptop.

Changing the password is the step that actually disconnects someone. The rest stops them from coming back. For the full pass over your router settings, work through the home network security checklist.

Why a one-time check isn't enough

A manual sweep only catches whoever is connected the moment you look. It says nothing about last night or next week. Someone who joins at 2am and is gone by morning never appears in a check you run at noon.

Continuous monitoring closes that gap. The network gets watched around the clock, you approve the devices you own once, and an alert fires only when a genuinely new one shows up. DeviceShelf does this on the desktop while your computer is awake, or 24/7 on a Raspberry Pi or NAS with the server edition. That always-on watch is one of the main things separating it from a pull-to-refresh phone app.

You can do every step here with free tools and some patience. If you'd rather get the labeled list and the alerts in one pass, DeviceShelf has a free 7-day trial, no account needed.

How to find a device by its MAC address

DeviceShelf — Wed, 19 Aug 2026 16:27:59 +0000

A MAC address is usually all your router gives you about a device: twelve hex digits like a4:cf:12:9b:00:01, maybe with a half-usable name next to it. The good news: those digits carry more information than they look like. The bad news is that they stop well short of "this is Lisa's tablet". Here is how far a MAC gets you, and how to cover the rest of the distance.

What the address contains

The first half of a MAC address names the manufacturer of the network chip. Those prefixes are assigned by the IEEE and public, so A4:CF:12 resolves to Espressif (smart-home gadgets and DIY boards), D8:3A:DD to Raspberry Pi. The second half is a serial number from the manufacturer's own pool; it identifies nothing publicly.

You can resolve the prefix with our free MAC address vendor lookup. It uses the official IEEE registries (all three of them, including the smaller MA-M and MA-S blocks), runs entirely in your browser, and flags randomised addresses for you.

When the vendor comes back empty

Modern phones, tablets and laptops invent a random MAC per Wi-Fi network by default. Those addresses are marked "locally administered" and deliberately match no registry entry. So an address with no vendor is rarely an intruder; it is usually a phone protecting its privacy. The same phone can even show up as several different devices over time.

If the lookup flags your address as locally administered, stop chasing the vendor. Identify the device by the other signals below instead.

From vendor name to actual device

A vendor name narrows things down, and sometimes that is enough: an Espressif device is almost certainly a smart plug, sensor or similar; a printer vendor is a printer. But "Hui Zhou Gaoshengda Technology" sits inside half the cheap smart-home hardware on the market, and Apple covers everything from a watch to a desktop. To get further you need the device to talk:

Hostname. DHCP and mDNS names like HS110 or MacBook-Pro-von-Lisa settle it immediately. Your router list often shows them.
Services. A printer answers on port 631, a camera streams on 554, a NAS offers file sharing on 445, a smart speaker announces itself via mDNS. Which doors are open tells you what lives behind them.
Behaviour over time. A device that appears every evening at seven and vanishes at midnight is somebody's phone, not a server.

You can collect all of that by hand, or let a scanner do it in one pass. DeviceShelf resolves vendor, hostname, services and open ports for every device on the network and turns them into an actual identification; the same IEEE data behind our lookup page ships inside the app. For the full detective story, see the guide on identifying an unknown device.

Finding the MAC in the first place

Router: the client list shows a MAC per device — the usual starting point.
Windows: ipconfig /all (Physical Address).
macOS/Linux: ifconfig or ip link; macOS also shows it under System Settings → Network → Details.
iPhone/iPad: Settings → Wi-Fi → ⓘ on the network (this is the per-network, usually randomised, address).
Android: Settings → About phone → Status, or in the Wi-Fi details.

What a MAC address will never tell you

No owner, no location, no serial number. The registry knows which company bought the prefix, and that is all. The claim that "this MAC belongs to this person" has no technical basis, which is also why sharing a MAC address is not the privacy catastrophe it is sometimes made out to be. On your own network, though, it remains the most stable handle a device offers, randomisation aside.

DeviceShelf for iOS is out of TestFlight and on the App Store

DeviceShelf — Tue, 21 Jul 2026 15:36:26 +0000

I'm the developer of DeviceShelf, a local-first network scanner for desktop, mobile and a headless server edition. Until this week the iOS app only existed on TestFlight. Apple has now approved version 1.3.0, so for the first time you can get it straight from the App Store: DeviceShelf on the App Store.

What the app does on a phone

The iOS app is not a companion viewer. It runs the same scanning engine as the desktop version: it scans the network you're on, identifies devices (vendor, type, OS fingerprint), shows open ports per device, builds a security report, and raises presence alerts when devices appear or drop off. You can export and share results from the phone.

The multicast entitlement

iOS restricts multicast traffic for ordinary apps, and SSDP/UPnP discovery depends on it. Apple grants the multicast entitlement on request, and DeviceShelf's App Store build has it. In practice, UPnP/SSDP devices show up in scans on the phone the same way they do on desktop.

Licensing

The download is free and comes with a trial. Full features unlock in one of two ways: activate a DeviceShelf license, which covers desktop, mobile and the server edition with a single purchase, or use the in-app purchase upgrade on iOS. Pricing is on the website if you want the details.

Local-first, on mobile too

Scans stay on the device. There is no cloud account, and the AI-assisted device identification is bring-your-own-key; no key is bundled or required.

The app is still young, and a phone is an unforgiving place for a network scanner. If it mislabels a device on your network or misses one entirely, I'd genuinely like to hear about it.

Website: deviceshelf.app

Wiring a local network scanner into an AI assistant with MCP

DeviceShelf — Tue, 14 Jul 2026 20:00:19 +0000

I build DeviceShelf, a local-first network scanner. Its Server edition is the headless, always-on one, and as of build 1.5.3 it speaks the Model Context Protocol (MCP). That means an assistant like Claude Desktop can answer questions about your network from your own live data: "what's online right now?", "anything new or offline since yesterday?", "which devices have certificates expiring soon?", "how does tonight differ from last week's snapshot?"

This post is about how that's wired, and more to the point how it's fenced in, because handing a language model a read of your network inventory is the sort of thing that deserves some paranoia. I'm the developer, so take the enthusiasm with the usual pinch of salt; the design choices below are the interesting part.

What the endpoint exposes

All told it's 22 tools (14 read-only, 8 opt-in actions), 3 guided prompts, 4 attachable resources, and an optional live mode that pushes changes to the client as they happen. MCP is the glue: the assistant discovers those tools and calls them, instead of you copy-pasting dashboard output into a chat window.

Everything stays on your LAN

The MCP endpoint runs inside the DeviceShelf Server, on the same port as the API, behind a bearer token, reachable only on your LAN. There's no DeviceShelf cloud connector and no remote OAuth. The only thing that ever leaves your network is whatever the AI client you chose to connect decides to send. It reads the same in-process data that backs the dashboard, so the model's view can't drift from what you see with your own eyes.

The read side

The 14 read tools cover the whole monitoring surface. Inventory is network_summary for the one-shot overview, list_devices with filters and pagination, find_device for free-text lookups ("the printer", "my NAS"), get_device for full per-host detail (open ports, OS, SNMP, TLS, matched CVEs, notes), and list_interfaces for multi-NIC collectors.

Monitoring adds list_changes, list_alarms, list_checks, get_device_history, get_device_uptime (per-device uptime over up to 90 days) and list_offline_devices. Security is one call: security_overview surfaces expiring and expired certificates, self-signed certs, and hosts with known CVEs grouped by severity, across the whole network without a lookup per host. And list_snapshots / diff_snapshots compare two named captures, or a capture against the live scan, so "what's new since the audit in May?" becomes a single question.

The write side is opt-in, twice

Writes are off by default. You turn them on with a second, separate switch (DEVICESHELF_MCP_ALLOW_ACTIONS=true), and only then does the assistant get action tools: rename or retag a device, acknowledge an alarm, create or delete monitor checks in plain language, save a named snapshot, trigger an on-demand scan or a TCP port check, or fire a test notification. The probing actions (scan_now, port_check) are restricted to your own locally-attached subnets and rate-limited.

If even that feels too loose, DEVICESHELF_MCP_CONFIRM_ACTIONS=true makes the impactful actions ask the client for a yes first, using MCP elicitation, so a scan never runs without you clicking confirm.

Prompts and resources

For people who don't want to learn tool names, the server ships three guided prompts that show up in the client's prompt picker: a security audit, a "what changed recently" report, and "identify unknown devices". One click, useful answer. It also exposes four read-only resources (deviceshelf://network/summary, deviceshelf://devices, deviceshelf://alarms, deviceshelf://security/overview) a client can attach as context without any tool call at all.

Live mode

By default the endpoint is stateless request/response. Set DEVICESHELF_MCP_LIVE=true and it switches to stateful sessions: clients can subscribe to the device, alarm and summary resources and receive resources/updated notifications when the inventory changes, so the assistant stays current without polling. Idle sessions close after 30 minutes.

Treating it as a security surface

An AI reading your inventory gets the same scrutiny as any other client:

/mcp is auth-required, exactly like the API. No token, no answer.
A scoped token (DEVICESHELF_MCP_TOKEN) is accepted for /mcp only, never for the admin API or metrics, so the AI client never holds an admin credential.
All tool calls are rate-limited (token bucket, default 300/min) and audit-logged by tool name and outcome, never by arguments.
Device-reported strings (hostnames, banners, cert subjects) are untrusted input: control and text-spoofing characters (bidi, zero-width) are stripped and values truncated before they reach the model, and the model is told to treat them as data.
An Origin allowlist guards against DNS rebinding from a browser.

That last group is the reason I'd trust this on my own network. Prompt-injection through a hostname a rogue device set to something clever is a real risk, and stripping the spoofing characters plus flagging the strings as data is the boring, correct answer.

Turning it on

In /etc/deviceshelf/server.env (or your Docker environment):

DEVICESHELF_MCP_ENABLE=true

Restart the server. The endpoint is served at http://<your-server>:8088/mcp with the bearer token. To connect Claude Desktop, bridge to it with mcp-remote. Keep --allow-http (it's plain http on your LAN) and pass the token via an env var, which sidesteps a Windows argument-quoting bug:

{
  "mcpServers": {
    "deviceshelf": {
      "command": "npx",
      "args": ["-y", "mcp-remote", "http://<your-server>:8088/mcp",
               "--transport", "http-only", "--allow-http",
               "--header", "Authorization:${AUTH}"],
      "env": { "AUTH": "Bearer <your-token>" }
    }
  }
}

Any MCP client that speaks Streamable HTTP can connect directly. It's available from deviceshelf-server 1.5.3 (Docker image ghcr.io/wealthwallet/deviceshelf-server:1.5.3, .deb, or later), off by default and fully additive, so existing servers are untouched until you set DEVICESHELF_MCP_ENABLE.

Where it stands

MCP is part of the Server edition rather than a separate purchase, and it works during the 7-day trial so you can evaluate it; the endpoint returns 402 once an unlicensed trial expires. The Server edition itself is still public beta, so treat it as early, and if a tool returns something wrong or a check behaves oddly I'd genuinely like the report. The full write-up with the client configs (Cursor, VS Code, Windsurf, Cline, Gemini CLI) is on the DeviceShelf blog, and the project lives at https://deviceshelf.app.

What a local network scanner actually knows about your devices

DeviceShelf — Sun, 12 Jul 2026 15:08:23 +0000

I build DeviceShelf, a local-first network scanner, so I spend a lot of time staring at the question "what is this thing on my LAN?" Turns out there's no single answer. A scanner guesses, using a handful of weak signals that each get one part of the picture right and one part wrong. This post walks through those signals and where each one lies to you.

Nothing here is specific to my tool. Any scanner works from roughly the same inputs, so this is meant to be useful whether you ever open DeviceShelf or not.

The MAC address and the vendor behind it

Every device on a local network has a MAC address, and the first three bytes are the OUI, the block assigned to a hardware vendor. Look that prefix up against the IEEE registry and you get a name: Apple, Ubiquiti, Espressif, Raspberry Pi Foundation. That one lookup is the cheapest and most reliable identifier you have. It's also the first one to fall apart.

Modern phones rotate their MAC per network to stop being tracked, so the vendor you see is a placeholder, not Apple or Samsung. Some cheap gear ships with a MAC from whatever reference-design chip is inside, so a smart plug reports as the Wi-Fi module maker rather than the brand on the box. And anyone can set a MAC to anything. A spoofed address means the OUI is simply a lie you can't detect from the outside. So: good for a first pass, wrong often enough that you can't stop there.

mDNS and Bonjour

Many devices announce themselves over multicast DNS. Printers, Apple gear, Chromecasts, a surprising number of IoT boxes. Ask the right multicast group and they'll tell you their hostname, service types, and sometimes a friendly model string. When a device participates, mDNS is the richest source you get for free, because the device is describing itself in its own words.

The catch is participation. A locked-down sensor or a random Linux box says nothing, and silence reads the same as absence. You also can't trust the self-reported name too far, since a user can rename a device to whatever they like, and some vendors put marketing text where a model number should be.

SSDP and UPnP

SSDP is the discovery half of UPnP, and it's how routers, media servers, smart TVs and game consoles advertise themselves. A scanner sends a multicast search, listens for responses, then fetches the device description XML each responder points at. That XML often carries a manufacturer, model name and model number straight from the firmware, which is more structured than a hostname.

UPnP has a reputation, mostly earned, for being chatty and inconsistent between vendors. Descriptions can be sparse, fields get left blank, and plenty of security-conscious setups disable it entirely. When it answers it's genuinely useful. You just can't count on it answering.

DHCP fingerprinting

When a device asks the network for an address, its DHCP request carries a fingerprint: the specific options it requests, in a specific order, plus fields like the vendor class identifier. Different operating systems and stacks produce recognizably different requests, so with a decent signature database you can often tell Android from an IoT RTOS from a desktop OS without the device volunteering anything.

Two honest limitations. You only see the request if you happen to be listening when the device renews its lease, which on a passive scan you usually aren't. And fingerprints drift as OS versions change, so a signature set goes stale and starts producing confident, wrong answers. It's a strong hint about device class, not proof of identity.

Open ports as a hint, not a verdict

What a device exposes says something about what it is. Port 9100 leans printer. 554 suggests a camera speaking RTSP. 445 points at a Windows or SMB host, 22 at something with SSH. Stack a few of these together and a rough device type appears.

I treat this as the softest signal of the set. A port tells you a service might be running, not what the box is for, and homelabbers run services on hardware that has nothing to do with the service's usual home. Aggressive probing also annoys fragile devices, so a scanner has to stay gentle, which means less data and more uncertainty. Useful for corroboration, weak on its own.

Optional AI identification, with your own key

When the mechanical signals disagree or come up thin, there's room for a model to weigh the messy evidence, the odd hostname, the vendor guess, the port pattern, the way a human would. DeviceShelf can do this, and it's strictly opt-in: you bring your own API key, nothing is bundled, and it does nothing unless you turn it on. Local-first means the default is that nothing about your network leaves your machine.

Being blunt about it, an AI guess is still a guess. It can be confidently wrong, it depends entirely on the quality of the signals underneath, and it's an assist, not an oracle. I'd rather it be honestly uncertain than smoothly incorrect.

Why identification is a best guess

Every signal here is partial. MACs get randomized and spoofed, half your devices stay silent, DHCP and port data show up late or not at all, and a good scanner combines the weak signals into something better than any one of them without pretending the result is certain. That's the honest frame: a network scanner narrows down what a device probably is, and tells you how sure it isn't.

DeviceShelf is a young project and I'm still improving how it fuses these signals. If it mislabels something on your network, or misses a device you can see with your own eyes, I'd genuinely like to hear about it. That kind of report is what makes the next version better. You can find it at https://deviceshelf.app.

Building a local-first network scanner in Go, Wails and Flutter

DeviceShelf — Thu, 09 Jul 2026 13:34:48 +0000

Most network scanners I tried wanted a cloud account and a subscription just to tell me what was sitting on my own LAN. That bugged me enough to build the opposite: a scanner that runs on your machine, keeps the data there, and still tells you what every device is. It's called DeviceShelf, and this is a short tour of how it's put together.

One core, three front-ends

The scanning and analysis live in a Go core: ARP/ping sweep, port checks, service probes, DHCP fingerprinting, SNMP, and the device-identification logic. On the desktop that core is wrapped with Wails — Go on the backend, a normal web UI on the front — so the same engine ships on macOS, Windows and Linux without three native rewrites. The mobile apps are Flutter, talking to the same concepts (a chunk of the identification logic is mirrored and unit-tested on both sides so behaviour matches). And there's a headless build of the core for a 24/7 server edition with no GUI at all.

Keeping one engine and swapping the shell is the only reason a solo project can cover desktop, mobile and server without drowning.

Local-first, and meaning it

"Local-first" is easy to put on a landing page and easy to quietly break. The rule here is simple: nothing about your network leaves the machine unless you switch something on. Device identification runs locally; the online fingerprint lookup is opt-in and off by default. If you want AI to help name a weird device, that's there too — but you bring your own key, so the calls are yours, not routed through a server I run.

The parts that were actually hard

Identification. Turning a MAC prefix, open ports, a DHCP fingerprint and an SNMP sysName into "this is a printer" is a pile of heuristics with sharp edges — a Nintendo Switch that looks like a network switch, say. It's ordered rules, not one magic classifier.
Live bandwidth. Per-device throughput means packet capture (Npcap on Windows, BPF on macOS), which is platform- and permission-dependent and needs care to stay light.
The server edition. Running unattended on a LAN changes everything: alert routing over ntfy/Gotify/webhook, threshold and dependency checks, and taming alert floods so it doesn't page you at 3am because Wi-Fi hiccuped.

Where it is now

Desktop and mobile are shipping; the server edition is an honest public beta. If you want to see what's on your own network without signing up for anything, that's the whole point.

Full write-ups and release notes: https://deviceshelf.app/blog