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.
Top comments (0)