The link light is on, the device is drawing power, and nothing on the network will admit it exists. You have pinged the subnet, read the router’s client list, run the vendor’s discovery tool twice. Nothing. Almost every page answering this question assumes the device pulled a DHCP lease and is sitting one subnet away — if that were true you would have found it in the lease table five minutes ago.
Two situations actually produce a vanished device. Either it never asked for DHCP, because it holds a static address from a previous installation or has reverted to a factory address like 192.168.1.64, or it asked and nobody answered, leaving it on a link-local address or none at all. Both are recoverable from where you are sitting, provided you work up from the wire rather than down from the IP layer.
- Works with no IP at all
- ARP, LLDP/CDP, vendor L2 discovery, serial console
- Link-local ranges
- 169.254.0.0/16 and fe80::/10
- Broadcast discovery
- Crosses subnets, never crosses a router
- Needs hands on the kit
- Console header, reset button, PoE injector swap
Start at the wire
Establish there is something to scan for before you spend an hour scanning. A flickering port LED proves very little. A managed switch tells you considerably more.
Switch# show interfaces status
Port Name Status Vlan Duplex Speed Type
Gi1/0/12 cam-loading-bay connected 30 a-full a-100 10/100/1000BaseTX
Gi1/0/14 err-disabled 30 auto auto 10/100/1000BaseTXAn err-disabled port is badly under-diagnosed. Port security learned a different MAC when the device was swapped, or BPDU guard fired because somebody plugged a desk switch into the wall, and the port has been shut ever since. It will never appear in any scan, at any layer. show interfaces status err-disabled names the reason; show errdisable recovery tells you whether the port will come back on its own or needs a shutdown / no shutdown.
Power is the other silent one. A PoE device that boots, draws more than its negotiated class, browns out and reboots has a distinctive signature: its MAC appears in the address table for ten or fifteen seconds every couple of minutes, then vanishes. Compare show power inline against the device’s rated draw, and check the switch’s total budget rather than just the port. Cameras with heaters are frequent winter offenders.
The five-pound switch
Take the device out of the building’s network entirely: a cheap unmanaged switch, the device, your laptop, nothing else. That one move removes VLANs, port security, 802.1X, DHCP snooping and every ACL at a stroke, turning a site-wide question into a two-node one. It resolves more of these calls than any software tool.
Let the device tell you where it is
A device that has just booted is loud. Before it does anything useful it announces itself: a gratuitous ARP claiming its address, a DHCP DISCOVER, mDNS, an ONVIF hello if it is a camera, LLDP if it speaks it. You do not need to find the device. You need to be listening when it shouts.
$ sudo tcpdump -i en0 -nn -e -s0
'arp or icmp6 or udp port 67 or udp port 68 or udp port 5353 or ether proto 0x88cc'
00:40:8c:3f:9c:11 > ff:ff:ff:ff:ff:ff, ARP, Request
who-has 192.168.1.1 tell 192.168.1.64, length 28That one line is the whole answer. The MAC is 00:40:8c:3f:9c:11, an Axis OUI; the device believes it is 192.168.1.64; and it is hunting for a gateway at 192.168.1.1 that does not exist on this network. You now know exactly which subnet to put yourself on. A DHCP DISCOVER is nearly as good — it carries the MAC, and usually a hostname and a vendor class identifier naming the model.
Power-cycle the device while the capture runs. Passive waiting can take minutes; a reboot gives you everything in ten seconds. On Windows, Wireshark with the display filter arp || dhcp || mdns || lldp does the same job, though builds older than Wireshark 3.0 want bootp in place of dhcp.
On a switched network you see broadcast and multicast frames only, never unicast conversations between other hosts — fine here, because everything a lost device says on boot is broadcast or multicast by definition. Wireless is the real limitation: client isolation and the nature of a managed Wi-Fi link mean you will often see nothing at all. Do this on copper.
What the switch already knows
Your own machine keeps a short memory of anything it has spoken to: arp -a on macOS and Windows, ip neigh show on Linux. Worth thirty seconds if you touched the device before it vanished. The switch keeps a far better memory. Know the port, ask what MAC is on it; know the MAC, ask which port it is on.
Switch# show mac address-table interface GigabitEthernet1/0/12
Mac Address Table
Vlan Mac Address Type Ports
30 0040.8c3f.9c11 DYNAMIC Gi1/0/12
Switch# show lldp neighbors detail
Local Intf: Gi1/0/12
System Description: AXIS P3245-LV Network Camera
Management Addresses - IP: 192.168.1.64LLDP and CDP sometimes hand you the management address outright, shortcutting everything below. Most managed switches, cameras, access points and IP phones run one or the other by default. Consumer gear almost never does.
If all you have is a MAC, the first three octets identify the manufacturer, which at least tells you whose discovery tool to run. This works far better on infrastructure than on laptops and phones: embedded devices use their real burned-in address, because MAC randomisation is a client-privacy feature and not something a camera does.
Scanning the subnet you are on
If the device is on your subnet and simply not answering ping, scan at layer 2. A host firewall can drop ICMP, but the stack answers ARP below the point where that filtering happens, so an ARP sweep sees things a ping sweep misses.
$ sudo arp-scan --interface=en0 --localnet
192.168.1.1 f4:f2:6d:11:22:33 TP-LINK TECHNOLOGIES CO.,LTD.
192.168.1.64 00:40:8c:3f:9c:11 AXIS Communications AB
$ sudo nmap -sn 192.168.1.0/24Run as root on a local segment, nmap uses ARP for host discovery automatically; -PR forces it. Either tool is fine — ARP is not optional for anything that wants to speak IPv4.
The link-local corner
A device that wanted DHCP and did not get it usually self-assigns from 169.254.0.0/16. Windows and macOS do this unprompted; Linux often needs avahi-autoipd or explicit configuration, which is why an Ubuntu laptop can end up with no address at all on a link where a camera has one. Vendors have been moving this way: from AXIS OS 12.0 an Axis device has no factory IP address and falls back to 169.254, where earlier firmware shipped on 192.168.0.90.
Scanning a /16 sounds unreasonable and is not — sudo arp-scan --interface=en0 169.254.0.0/16 is about 65,000 requests and a couple of minutes at default rates. IPv6 is quicker, since almost every modern embedded stack brings up an fe80:: address whether or not IPv4 ever worked.
$ ping6 -c 3 ff02::1%en0 # all-nodes, link-local
$ ip -6 neigh show # Linux
$ ndp -an # macOSBrowsing to a link-local address
The zone index needs percent-encoding, so fe80::240:8cff:fe3f:9c11%en0 becomes http://[fe80::240:8cff:fe3f:9c11%25en0]/ — square brackets around the address, %25 in place of %. Get it wrong and the browser reports an invalid address rather than a connection failure, which sends people down entirely the wrong path.
When it is on a subnet you are not
Told to reach 192.168.1.64 while holding 10.20.0.15/24, your machine consults its routing table, concludes the destination is not on-link, and hands the packet to its default gateway — which has no route to that network and drops it. Your laptop never sends a single ARP request onto the wire the camera is sitting on, even though the camera is four metres away on the same switch.
Three variations, in rising difficulty. Same broadcast domain, different subnet: fixable from your seat, and that is the next section. Different VLAN on the same switch: you need a port in that VLAN, a tagged sub-interface, or an SVI. Genuinely behind a router: you need a route towards it.
That last case carries a trap that catches experienced people. Adding a route on your side is half the job — the device needs a return path. A freshly reset unit has no default gateway, or one pointing at an address that does not exist, so it can receive your packet perfectly well and be structurally incapable of answering. Which is exactly why the second-address approach works where routing does not: on-link traffic involves no gateway at either end.
Giving yourself a second address
Adding an alias to your existing interface is non-destructive, takes one command and reverses with a second. Pick something unlikely to collide, and ping it first to confirm nothing answers.
- Linux.
sudo ip addr add 192.168.1.50/24 dev eth0, and afterwardssudo ip addr del 192.168.1.50/24 dev eth0. The original address stays up throughout. - macOS.
sudo ifconfig en0 alias 192.168.1.50 255.255.255.0, removed withsudo ifconfig en0 -alias 192.168.1.50. Aliases added this way do not survive a reboot, which is usually what you want. - Windows.
netsh interface ipv4 add address name="Ethernet" address=192.168.1.50 mask=255.255.255.0 skipassource=yes. Remove it withnetsh interface ipv4 delete address name="Ethernet" address=192.168.1.50. - Reach it. Ping the device’s address to confirm it answers on-link, then open the management page.
Windows carries a constraint the others do not: extra addresses can only be added to an adapter whose primary address was set manually. On an adapter still taking DHCP, netsh refuses and the GUI greys the button out. A cheap USB Ethernet adapter configured statically sidesteps that and keeps the two networks on separate interfaces. skipassource=yes matters on a machine that stays plugged into production — without it, Windows may start sourcing outbound traffic from the temporary address.
Cover every likely default at once
Take 192.168.0.50 with a /16 mask instead of a /24 and you are on-link for everything from 192.168.0.0 to 192.168.255.255 at once — 192.168.0.90, 192.168.1.1, 192.168.1.64, 192.168.1.108 and 192.168.88.1 covered in one command. Only on an isolated switch or a spare adapter, though — a /16 on a live corporate NIC swallows every other 192.168.x subnet the machine needs to route to.
Two things that will bite
An alias duplicating an address already in use elsewhere will break that host, and the complaint arrives long after you have forgotten you did it. Remove aliases when you finish. And if you reach the device but the management page hangs or renders blank, stop treating it as a discovery problem — that is a different fault with its own causes.
Vendor discovery tools, and what they are actually doing
Knowing what these tools send tells you exactly when they will work. Almost all of them broadcast or multicast a probe across a layer 2 segment and collect the replies. Because the exchange never leaves the broadcast domain, a device holding an address in a completely unrelated subnet still answers — which is why SADP finds a camera at 192.168.1.64 while your laptop sits on 10.0.0.0/8, and why none of them see anything past a router.
| Tool | Transport | Different subnet, same wire | Across a router |
|---|---|---|---|
| AXIS IP Utility | Broadcast and link-local multicast | Yes | No — same physical segment only |
| Hikvision SADP | UDP 37020, broadcast and 239.255.255.250 | Yes | No |
| Dahua ConfigTool | UDP 37810 | Yes | Only by probing a known IP directly |
| Ubiquiti Device Discovery | UDP 10001 | Yes | Yes, if you unicast to a known IP |
| MikroTik Winbox / MNDP | UDP 5678 | Yes | No |
| ONVIF WS-Discovery | UDP 3702 to 239.255.255.250 | Yes | No |
When a tool shows an empty list on a segment where a capture clearly shows the device’s ARP traffic, the culprit is usually your own host firewall dropping the inbound replies. Windows Defender Firewall does this to unsolicited UDP on a network profiled as Public. Switch the profile to Private, or allow the tool explicitly, and the list populates.
Two are worth singling out. Winbox connects to a MikroTik device by MAC over raw layer 2, with no IP at either end — one of the very few ways to configure a device that is not speaking IP at all. And because Ubiquiti’s discovery service answers unicast probes as well as broadcast, you can confirm a suspected address across a routed link, where the broadcast-only tools are useless.
Older advice has you plant a static ARP entry and ping the device into adopting that address. The ARP/Ping method is largely gone: Axis removed it in AXIS OS 7.10 and advises disabling it on older firmware that still has it, an unauthenticated way to set a device’s address being exactly what you do not want listening on a network.
Console, and the honest last resort
If the device has a serial header, none of the above matters. You get a shell regardless of what the network stack is doing, and you can read the current address instead of guessing at it. Baud rate is the thing people get wrong. Eight data bits, no parity, one stop bit and no flow control is near-universal; the speed is not. Try 115200 on anything recent and 9600 on older enterprise switches and routers, where 9600 8N1 has been the Cisco default for a very long time. A screenful of garbage rather than silence is encouraging — the wiring is right and only the speed is wrong, so step through 57600, 38400 and 19200. The physical side, from rollover RJ45 to USB-C and bare UART headers on kit with no external port, is covered in getting a serial console onto a device.
With no console and no discovery, reset it again and go in on the documented factory address. A reset is only useful because the result is predictable, and that depends on knowing what the manufacturer actually ships. Our list of default management IP addresses by vendor covers the addresses; the A–Z index of default credentials covers what to type once the login page loads. Check both before the reset rather than after — several vendors, Cisco and Hikvision among them, ship different defaults across firmware generations, and returning a device to a default you cannot log into is a miserable way to spend an afternoon.
