An address answers. Nothing identifies it. Somebody wants to know what it is, and “unknown” is not an answer they will accept. Work through it in this order.
1. What the MAC prefix does and does not say
The first three octets identify the organisation that registered that block with the IEEE. That is genuinely useful and routinely over-read.
It tells you who made the network interface. A great many devices contain a network module from somebody else: an Espressif prefix means the device has an ESP32 in it, which describes half the IoT market. A Raspberry Pi prefix tells you the board, not what it was built to do.
Two specific traps:
- Randomised addresses. If the second-least-significant bit of the first octet is set, the address is locally administered — it was not assigned by any manufacturer, and looking it up in a vendor database produces a name that means nothing. Modern phones do this by default. Addresses starting
02,06,0A,0Eand so on through the pattern are all in this class. - Registrar blocks. Some prefixes, such as
00:50:C2, belong to the IEEE Registration Authority itself and are sub-delegated in smaller slices. Reporting “IEEE Registration Authority” as the manufacturer is worse than reporting nothing at all.
2. Ask it what it is
Many devices will simply tell you, over a protocol designed for the purpose. Try each in turn — they find different populations:
- mDNS. Apple hardware, printers, Chromecasts, most modern IoT. Often includes an explicit model string.
- SSDP. Media players, smart TVs, some cameras. Returns a URL that describes the device.
- WS-Discovery. Windows machines and ONVIF cameras. Frequently the only thing that finds a camera.
- NetBIOS. Old, and still the quickest way to get a name off a Windows box or a NAS.
3. Read the open ports as behaviour
What a device listens on describes what it is for. Port 9100 open means it accepts print jobs. 554 means it serves RTSP video. 1883 means MQTT, which usually means building automation or IoT. 445 with 139 means Windows file sharing.
Open a web interface if there is one. It is astonishing how often port 80 on a mystery device returns a page with the model number in the title.
4. Find it physically
When the network will not say, the building will. Two approaches:
Switch port mapping. Given a read-only SNMP credential, the switch will tell you which port that hardware address is behind. Follow the cable.
Unplug it. Cruder and often faster. Find Device watches the network while you disconnect something and tells you which address just stopped answering. It is the software equivalent of tracing a cable, and it works on a site you have never seen.
5. The TTL tells you the operating system family
The time-to-live on a reply is set by the sending system and decremented by each router in between. Common initial values: 64 for Linux, macOS and most embedded systems; 128 for Windows; 255 for a lot of network equipment. A reply arriving with TTL 63 has crossed one router from something in the 64 family.
It is a weak signal on its own, and a good one in combination. A device with TTL 255, SNMP open, and a Cisco or Ubiquiti prefix is network infrastructure, and you can say so.
6. Know when to stop
Some devices genuinely will not identify themselves, and no tool will change that. At that point the honest deliverable is a description rather than a name: this address answers, it has these ports open, it has this prefix, it appeared on this date, it is behind port 12 of the second switch.
That is a useful record. It gives the next person a starting point, and it does not require them to first disprove something you invented.