Dante Device Discovery: Fix Devices Missing from Controller

TL;DR — Dante devices normally advertise their identity and channels automatically, but discovery depends on the Controller computer using the intended network interface and sharing the correct discovery scope. Start with power and physical link, then verify Controller interface selection, computer and device addressing, primary-versus-secondary wiring, VLAN or subnet boundaries, firewall policy, and managed-network login. Fix the earliest failed boundary before changing routes, names, clocks, or audio settings.

Discovery happens before routing

Dante Controller can route audio only after it discovers the endpoints. A device advertises its name, channels, capabilities, and format information; Controller enumerates that information and presents it in Network View.

If the device is absent, subscription edits are not the first task. The failure is earlier: physical connectivity, computer interface choice, address compatibility, discovery traffic, network scope, or management enrollment.

Use a fixed discovery workflow

1. Prove power and physical link

Check the endpoint's power, network LEDs, correct Dante port, cable, switch port, and negotiated speed. Confirm the switch port is enabled and assigned to the intended network. Compare against a working device on the same switch.

Do not begin by rebooting every switch. One failed device usually calls for one-device evidence first.

2. Check the Controller interface

Dante Controller remembers its selected primary and secondary computer interfaces. A laptop can therefore join the correct Ethernet network while Controller continues using Wi-Fi, a dock adapter, a VPN interface, or another NIC.

Open the interface selector and identify the adapter by name, link, and address. For an ordinary primary-only network, select the wired interface connected to that network. If the computer has multiple wired adapters, avoid placing two of them in the same IP subnet.

The Dante Controller network interface guide covers multi-NIC and redundant-network choices.

3. Compare address schemes

The computer and endpoints must have compatible addressing for the network design. On a standalone primary network without DHCP, link-local addresses normally use 169.254.x.x. With DHCP, the computer and devices should follow the approved DHCP scope. Static addresses must use the intended subnet, mask, and gateway policy.

Use Device Info when any devices are visible, and check the operating system's interface address. Do not treat one 169.254 address as proof of failure; link-local addressing is valid on a single standalone network.

Follow the Dante IP addressing guide before changing DHCP or static settings.

4. Separate primary and secondary networks

On redundant Dante systems, primary and secondary are separate physical networks. Do not connect the two switches together. Connect the computer's primary Dante interface to the primary network and, when two NICs are available, its secondary interface to the secondary network.

With only one computer NIC, use the primary network for normal control. Moving to the secondary network during a failure also requires changing Controller's interface selection. Secondary-only access can expose limited identity while preventing full control of devices that exist only on primary.

5. Respect VLAN and subnet boundaries

Unmanaged discovery is normally a local-network function. A device placed in another VLAN or IP subnet may be perfectly healthy yet outside the Controller computer's discovery scope. Do not add an ad hoc mDNS reflector or flatten production VLANs simply to make an icon appear.

Multi-subnet systems require an intentional managed design, such as Dante Domain Manager or Dante Director, with routing, discovery, clocking, enrollment, and permissions owned by the network administrator. Link-local addressing and local mDNS are appropriate for simpler single-subnet systems; they are not a substitute for routed-network architecture.

6. Check host security and competing software

Confirm that the operating system firewall and endpoint-security policy allow the approved Dante applications and discovery traffic on the selected network profile. Temporarily disabling all protection is not an acceptable production fix. Capture the blocked rule, apply the narrow approved exception, and restore the baseline.

Also check VPN software, virtualization adapters, Internet sharing, and manufacturer utilities that may change interface priority or share the selected Dante interface.

7. Confirm managed-network access

In a managed environment, verify that Controller is connected to the correct Dante Domain Manager domain or Dante Director site and that the operator has permission to view or configure the device. Distinguish an unmanaged local device awaiting enrollment from an enrolled device the current account cannot manage.

Do not factory-reset a device to bypass ownership. Escalate to the named domain or site administrator.

Diagnose by scope, not guesswork

Use working comparisons to shrink the fault:

1. Does the same computer see another device on this switch?
2. Does another approved computer see the missing device?
3. Does the device appear when placed on a known-good port in the same VLAN?
4. Is the fault limited to primary, secondary, one subnet, or one site?
5. Did it begin after a dock, VPN, DHCP, VLAN, firmware, or management change?

Change one variable and record the result. If discovery returns, verify the device name, channel inventory, address, clock status, and real audio before declaring recovery.

Document the discovery handoff

Record:

• device name, model, firmware, MAC address, and physical location;
• primary and secondary ports, switches, VLANs, and address schemes;
• Controller computer, adapter name, and selected interface role;
• DHCP, static, or link-local ownership;
• managed domain or site and responsible administrator;
• working discovery scope and known limitations;
• tested failure, recovery, spare, and rollback procedure.

Keep credentials and sensitive network details outside a public rider. Put the operational summary and ownership boundary in the digital audio network tech rider.

Dante discovery checklist

• Endpoint power, link, cable, port, and negotiated speed are healthy.
• Controller is using the intended wired network interface.
• Computer and endpoint addresses match the approved design.
• Primary and secondary networks remain physically separate.
• VLAN and subnet scope matches the management architecture.
• Firewall, VPN, and virtual adapters are checked without broad disabling.
• Domain or site login and permissions have a named owner.
• Device identity, real audio, recovery, and rollback are verified.

Common mistakes

Editing subscriptions before the endpoint is visible. Routing cannot repair a discovery boundary.

Assuming link-local means broken. 169.254.x.x is expected on a primary network without DHCP.

Bridging primary and secondary. Redundant networks must remain separate.

Reflecting discovery traffic without a design. Cross-subnet Dante requires managed routing, clocking, enrollment, and security—not only forwarded announcements.

Resetting an enrolled device. A permission problem needs the system owner, not erased configuration.

FAQ

Why is Dante Controller not showing devices?

Common causes are the wrong computer interface, missing physical link, incompatible addressing, an incorrect VLAN, a discovery boundary between subnets, firewall policy, or missing access to the managed domain or site.

How does Dante device discovery work?

Dante endpoints automatically advertise identity, channels, and capabilities on the network. Controller listens on its selected Dante interface and lists devices within the applicable local or managed discovery scope.

Does Dante discovery work across subnets?

Ordinary unmanaged discovery is local in scope. Multi-subnet operation needs an intentional routed design and a supported management platform with the required DNS, enrollment, routing, clocking, and permissions.

Why can I see a Dante device but not configure it?

The computer may be connected only to a secondary path, or the device may be enrolled in a managed domain or site where the current account lacks configuration permission.

How do I troubleshoot a missing Dante device?

Check power and link, Controller interface selection, computer and device addresses, primary/secondary wiring, VLAN and subnet scope, host security, then managed-network login. Fix one boundary at a time and confirm real audio afterward.

Make discovery ownership visible

Missing devices become faster to recover when the rider names the network, interface role, address owner, management owner, and tested fallback. Build that handoff in Techrider.live so the latest network notes, input list, stage plot, and recovery evidence stay in one rider that collaborators can edit, save, and inspect through history.