Troubleshoot "no devices found"
Diagnostic steps when go-udap discover returns nothing
When go-udap discover returns nothing, work through this checklist
in order.
Steps
Confirm the device is powered on
The most boring cause. Plug it in, wait 30 seconds for it to come fully up, try again.
Confirm the device is in setup mode, not run mode
A configured Squeezebox in run mode — front LED steady, connected to
its music server, playing audio — does not answer UDAP at all, so
discover sees nothing even though the device is on the network and
answering pings. Why the firmware stops responding isn't confirmed;
the behaviour itself is consistent and reproducible.
Short-press the front button to drop it into setup mode (the LED flashes red). NVRAM is preserved, and UDAP starts responding again.
See Setup mode vs. run mode for the evidence behind this and the model-coverage caveat.
Confirm the device is on the same network segment
UDAP discovery is broadcast-based; broadcasts don't cross routers. The device and your dev machine need to be on the same VLAN / subnet.
If the device is unconfigured (no DHCP lease), it broadcasts from
source IP 0.0.0.0 — it doesn't have a subnet yet, but it must be
physically on the same Layer-2 segment.
Check UDP port 17784 isn't blocked
Some host firewalls block inbound UDP on non-standard ports. Test with tcpdump:
sudo tcpdump -i any -n -nn 'udp port 17784'In another terminal, run go-udap discover. You should see the
outbound broadcast (length 27) and the device's reply (length 61+).
If you see the outbound but no reply, the device isn't responding (check the two preceding steps again). If you see neither, your host firewall is dropping the outbound — find and fix it.
On a multi-homed laptop, try --bind-interface or --all-interfaces
If your host has Wi-Fi + Ethernet both up, default discovery only emits on the kernel's default-route NIC. If the device is on the other NIC's subnet, you'll see zero devices.