Linked but no IP: a network detective story

The symptom: you plug in a new device — a NAS, server, appliance — the switch shows the port is up (link light, 1 Gbps), but the device never gets a DHCP lease, never appears in your controller’s client list, and you can’t reach it. Is it a network problem, a static-IP problem, or a dead device? Here’s the triage order that answers it fast — and the one conclusion people miss.

---

Layer by layer, cheapest checks first

1. Is it a tracked client at all? (controller / DHCP)

Check your UniFi/router client list and DHCP leases for the MAC or a device-ish hostname (a NAS often shows as TNAS-xxxx, a vendor OUI, etc.). Not there → it isn’t getting a lease. Move on.

2. Is the switch port on the right VLAN?

A port silently assigned to the wrong VLAN (or a VLAN with no DHCP) will link up and go nowhere. Confirm the port’s native network matches where you expect the device (this alone explains a lot of “connected but no IP” cases).

3. Is it a static IP on a foreign subnet? (the “used device” trap)

A device configured elsewhere may keep a leftover static IP (e.g. 192.168.1.50) that isn’t valid on this LAN — linked, but unroutable. It’s L2-present but IP-invisible. To catch it, sniff the wire from a host on the same VLAN:

# who is ARPing for a gateway that doesn't exist here? the "tell X" is the device's real IP
tcpdump -i <iface> -nn arp | grep -i 'who-has'
#   e.g.  who-has 192.168.1.1 tell 192.168.1.50   <-- device is on 192.168.1.x, not yours

If you see it, add a temporary secondary IP on that subnet to your host, reach the device, and set it back to DHCP. mDNS also finds foreign-IP devices on the same segment (avahi-browse -at), since mDNS is link-local.

4. Is it even trying to talk? (the check people skip)

Capture DHCP + ARP from a same-VLAN host for a few minutes and look for the device’s MAC:

tcpdump -i <iface> -nne "arp or (udp and (port 67 or 68))"

• You see DHCP DISCOVER from an unknown MAC → it’s alive and trying; fix the DHCP/VLAN side.
• You see ARP from a foreign IP → static-IP trap (Step 3).
• You see nothing from it for 2–3 full minutes → this is the tell. Keep reading.

---

The conclusion everyone misses

PHY link up + total Layer-3 silence for 3+ minutes ⇒ suspect POWER or BOOT, not the network.

A device that’s electrically linked but emits zero ARP/DHCP for minutes usually isn’t actually running — a half-seated power connector, a PSU that gives just enough to light the NIC PHY but not boot the SoC, a boot hang, or a DOA unit. We chased a “network problem” on a brand-new NAS for a while; the box was linked but not truly powered on. Re-seating the power → it booted and DHCP’d instantly.

So once you’ve ruled out VLAN + static-IP + and confirmed it’s silent on the wire:

1. Re-seat power (and the NIC cable) firmly; check the device’s power/status LED for a real boot pattern.
2. Try it with its drives out (for a NAS) — used disks with a foreign OS can hang the boot; a diskless boot often comes up clean.
3. Use the vendor’s discovery tool (many NAS/appliances broadcast their own discovery that works even pre-IP).
4. Try a different port/cable to rule out the switch side.
5. Still silent + no LED activity → likely DOA → RMA.

---

Toolbox recap: controller client list → VLAN of the port → same-VLAN tcpdump for ARP/DHCP → avahi-browse for L2 discovery. Cheap, fast, and it separates “network misconfig” from “static-IP leftover” from “the device isn’t really on.” Don’t spend an hour on DHCP config for a box that was never awake.

Written from a real hunt: a new TerraMaster NAS, link up on the switch, dead-silent on the wire for 3 minutes across UniFi, mDNS, and packet captures — root cause was a power-seating issue, not the network. Re-power → instant lease.