KLANG:app | Device Discovery

How are KLANG devices discovered on the network?

Quickly find and manage KLANG devices on your network using the built-in discovery in KLANG:app.

This guide shows you how KLANG devices communicate, how they identify themselves, and how to troubleshoot visibility issues.

You’ll learn:

• How device discovery works over IP networks and OSC via UDP.
• How KLANG:app and KLANG:kontroller find processors.
• What to do when a device is missing.
• Why connections can work one day and fail the next — and why a second network adapter (e.g. Wi-Fi alongside Ethernet) is often the cause.
• Tips for using fixed IPs vs. DHCP.

1. Make sure the KLANG processor is powered and the display or status LED are lit.
2. Check that a network cable is plugged into the control network port and that the network activity LEDs are blinking.
3. On your computer, deactivate and unplug all network adapters that are not required to connect to your KLANG hardware. If you are connected via ethernet cable, make sure to disable WiFi for now.
4. If you want to connect to a KLANG:kontroller, make sure KLANG:app is in Show or Admin mode (Press and hold CONFIG for 3 seconds).

Check the Quick Start Guide for your KLANG hardware:

Most discovery and connection problems are not caused by the KLANG hardware, the switch, or the cabling. They happen when your computer has two active network connections in the same or overlapping IP address range — for example two adapters both using 192.168.x.y, or Wi-Fi and Ethernet on the same network. Typical symptoms:

• It worked yesterday, but today some devices won’t connect — and nothing visibly changed.
• It works on one laptop but not another, or on a PC but not a Mac.
• KLANG:app finds the device, but the connection still fails or drops.

The root cause: two connections in the same IP range

Your computer keeps a single routing table — one list that decides, for every destination, which network adapter to send through. When both adapters claim the same range (e.g. both 192.168.x.y/16), that list now holds two equally valid entries for every device you will ever talk to. Your computer cannot inspect the wiring and ask “which cable is this unit actually plugged into?” — it picks one adapter and commits all traffic for that range to it. For every device that is really on the other adapter, the traffic leaves the wrong port and is lost.

This breaks discovery and direct connections, for two different reasons:

• Discovery fails (broadcast): If the subnet masks don’t match, the broadcast address is calculated differently on each device, so the “Here I Am” broadcast is never received. No answer — KLANG:app doesn’t see the device.
• Direct connections fail too (unicast): Even when you set a fixed IP and connect directly, the routing table still has two valid routes for that range. The computer sends out the wrong adapter, and the connection silently fails. A fixed IP alone does not fix this — the overlapping range is the problem.

Common situations that cause this

• Two adapters in overlapping ranges — e.g. both set to 192.168.x.y/16, or one /16 and one /24 that overlap. A /16 mask covers a far wider range than people expect.
• Both adapters fall back to link-local — with no DHCP server and no fixed IP, each adapter self-assigns an address in 169.254.x.y/16. Two adapters both in this one large range is the same overlap trap. This needs no misconfiguration — just two cables plugged in with no DHCP present.
• Windows keeps a backup link-local address alongside a configured IP, which can create a second overlapping 169.254.x.y/16 route.
• Wi-Fi and Ethernet on the same network — both reach the same devices, so the computer again has two routes. Worse, control traffic can quietly travel over Wi-Fi instead of the cable until the wireless link congests and you hear dropouts. If you are connected by cable, disable Wi-Fi (see Troubleshooting Steps).
• Wi-Fi internet vs. wired audio network — e.g. Wi-Fi on a DHCP 192.168.1.x/24 while the wired side uses 192.168.x.y/16. Because the /16 range swallows the /24, these overlap.

In every case, it is up to the operating system to decide which network adapter to use — and it cannot always choose correctly.

Why it works one day and not the next

This is the part that causes the most confusion, because nothing looks like it changed:

• The “winning” adapter is decided by fragile tie-breakers — boot order, link speed, adapter priority, or a DHCP renewal. A reboot, a re-plugged cable, a switch restart, or a driver update can silently flip which adapter wins. Yesterday’s working adapter becomes today’s dead end.
• Windows and macOS behave differently. Windows is more forgiving and will sometimes accept replies arriving on the “wrong” adapter, so a broken setup limps along — until it doesn’t. macOS is stricter and quietly discards them. Identical setup, “works on the PC but not the Mac.” That is the operating system, not the unit.
• Existing connections mask the problem. A session that is already open can keep working for a while after routing has effectively gone wrong, then drop out minutes later with no obvious cause.

A device shows a 169.254 link-local address but still connects

This often works, and it can be confusing. The 169.254.x.y/16 range is special-cased by every operating system: it is always treated as directly reachable on the local cable, even when your computer has a normal DHCP or fixed IP. So a one-to-one conversation on the same cable can succeed without a second link-local address on your computer.

Don’t rely on it. A link-local address means the device did not get the address it was supposed to — it found no DHCP server and fell back. It won’t route across networks, discovery will be unreliable, and the moment a proper address appears (or a second link-local device joins), the behaviour changes. Treat a 169.254 address as a flag to fix the addressing, not as a working state.

How to avoid all of this

• Give each network its own distinct, non-overlapping range. Two separate /24 networks rather than two overlapping /16s. For example, the audio network on 192.168.10.x/24 and any other network on 192.168.20.x/24.
• Use the same subnet mask on every device in a network.
• Deactivate or unplug any adapter you don’t need for KLANG (including Wi-Fi when working on a wired audio network, and virtual adapters such as VMware or VirtualBox).
• If you can’t change the addressing, treat any working state as fragile.

For most setups we recommend DHCP. The majority of connection problems in this guide come from manual misconfiguration — mismatched subnet masks, overlapping ranges, or a stray fixed IP. A single DHCP server hands every device consistent, correct settings automatically and removes most of those errors before they happen.

• DHCP (recommended).
  Easiest to set up and the least error-prone: no per-device configuration, no chance of typing the wrong mask on one unit. The one rule that matters is exactly one DHCP server on the network. A second DHCP server, or DHCP running while another adapter holds a fixed IP in an overlapping range, recreates the overlap failures described above. One server, one range, and the rest takes care of itself. A dedicated router or managed switch usually provides this.
• Static / fixed IP (for IT experts).
  Gives predictable, documentable addresses, which suits some permanent installations. The trade-off is that every device must be configured by hand with a consistent range and the same subnet mask. That’s the step where most configuration errors occur. If you go this route, keep one range, one mask, and a written record of which device has which address.
• Link-local (169.254.x.y/16) (What you get when you configure nothing).
  If neither a DHCP server nor a static IP is present, each device assigns itself an address in this range automatically. You can rely on this for a quick network setup. An unexpected 169.254 address usually means DHCP failed, or your KLANG device has a fixed IP and an additional link-local backup IP.

If you do need fixed addressing, see How to Set a Fixed / Static Control IP Address.

KLANG:app communicates over IP network messages. KLANG:app sends OSC UDP messages to KLANG processors on port 9110 and to other KLANG:apps on port 9111. All KLANG:apps listen on port 9111. If this port can’t be opened because it is already used by another application, it uses the next free port.

The device running KLANG:app has to be in the same network and in the same IP address range as the KLANG hardware. If overlapping ranges or a second active adapter are in play, see Discovery Challenges above — that is the most common reason a device is found but won’t connect.

1. Otherwise, first check that the network cable is connected properly and that the connectivity and activity LEDs are blinking, and that the device running KLANG:app has proper Ethernet or Wi-Fi connectivity to the same network as the KLANG hardware.
2. If discovery still fails, temporarily disable your computer’s firewall — firewall rules can block the broadcast handshake.
3. In some cases, MS Windows prevents broadcast messages from being sent to all existing network adapters, so the handshake with KLANG:app cannot be completed successfully. As a workaround, deactivate unused adapters such as VMware or VirtualBox virtual adapters.
4. In case you know the IP address of your KLANG hardware, try to enter this directly in CONFIG > CONNECT > IP Connect

How KLANG devices handle their IP addresses

Understanding how a KLANG device assigns its own control IP address explains why a unit can sometimes be reachable on an address you didn’t expect and why a 169.254 link-local address on the device is often completely normal.

Default (no fixed IP): one address at a time

With no fixed IP configured, the control interface carries a single address, chosen automatically:

• If a DHCP server answers, the device uses the DHCP address and any link-local address it had is removed.
• If no DHCP server answers, the device falls back to a link-local address in 169.254.x.y/16.

So in the default state it is always one or the other, never both. A 169.254 address here simply means no DHCP server was reached.

With a fixed IP: the fixed address is added on top

When you set a fixed IP, it is added as an additional address and the automatic logic keeps running alongside it. So the interface ends up carrying:

• the fixed IP, plus
• a DHCP address if a server answers, or a link-local address if none does.

To prevent the device from overlapping with itself, its automatic addressing is configured to stay out of the fixed IP’s own subnet. With a wide mask this covers a large range — a fixed IP of 192.168.1.200 with mask 255.255.0.0 (/16) keeps the entire 192.168.x.y range clear of automatic addresses on that interface.

This is exactly the situation in the “Here I Am” example above: a device showing both 10.10.10.20/24 (fixed) and 169.254.2.3/16 (link-local) is in fixed-IP mode with no DHCP server present — so it added a link-local address alongside the fixed one. On a KLANG device this is expected, not a fault.

Why this matters for discovery: a single unit can be reachable on more than one address at once. If a device looks “missing,” it may simply be answering on an address in a different range than the one your computer is on — check that your computer shares a subnet (and the same subnet mask) with the address you expect to use.

Reading the addressing mode from the LED

On KLANG processors without a display, the status LED shows which addressing mode the unit is in before any KLANG:app or console connects, a quick way to confirm what a unit is doing on the network. Power-cycle the unit and observe the LED before connecting.

Once connected, the LED turns solid purple, or blinks purple/red if the audio clock is invalid. For full details on setting fixed IPs, the reset-button shortcuts, and the separate Dante address on :vier, :fabrik, :vokal and :kontroller units, see How to Set a Fixed / Static Control IP Address.

Private & Link-Local Address Ranges

These IP address ranges are reserved for private networking and local communication. They are not routable over the internet and are used for internal LAN configurations. The link-local range (169.254.0.0/16) is assigned automatically when a device fails to obtain an IP address via DHCP, defined in RFC 3927. The mechanism that performs this fallback is called APIPA on Windows and is part of the Zeroconf / Bonjour suite on macOS — but “link-local” refers specifically to the address range itself, which is how KLANG:app labels these addresses. The private address spaces are defined in RFC 1918. A clear understanding of these ranges is essential for secure, isolated and reliable local network setups.

Multicast Range

Multicast IP addresses are used for group communication, where one sender transmits data to multiple receivers simultaneously. This method is common in networked audio systems such as Dante.

Subnet Masks

Subnet masks define how IP addresses are grouped and routed within a network. By creating smaller, manageable subnets, you can isolate network segments to improve performance, security, and address efficiency.

Subnet Masks & CIDR Notation

CIDR (Classless Inter-Domain Routing) notation is a compact way to represent IP address ranges and their subnet masks. It appends a slash followed by a number (e.g. /24) to an IP address, indicating how many bits are used for the network portion of the address.

For example, 192.168.1.0/24 means:

• The first 24 bits are reserved for the network.
• The last 8 bits are for host addresses.
• This results in 254 usable IP addresses.

CIDR makes subnetting more flexible than traditional Class A/B/C networks and is now the standard for IP allocation and routing. It’s used in everything from home routers to large enterprise and cloud network setups.

For further reading and official definitions, see RFC 4632 – Classless Inter-Domain Routing (CIDR) and the Wikipedia article on CIDR.

Common Subnet Masks

More Specific Examples

Broadcast Address

Broadcast IP addresses play a key role in KLANG’s automatic device discovery process. When a device sends a broadcast message, it reaches all devices on the same subnet.

• Send only one message to reach all devices on the subnet.
• The broadcast address is calculated from the device’s own IP address and subnet mask.
• All receivers must have the exact same broadcast address as the sender.
• This requires using the same subnet mask on all devices.
• No mix of 255.255.255.0 and 255.255.0.0 is possible within the same subnet.
• In every subnet, the first address is the network address and the last address is the broadcast address; neither can be assigned to a device. In a /24 these are the .0 and .255 addresses — but in other subnet sizes they fall elsewhere. For example, in the /23 above (192.168.0.0 – 192.168.1.255) the broadcast is 192.168.1.255, so 192.168.0.255 is in fact a usable host address.
• Broadcasts can slow Wi-Fi networks down to their minimum transmission speed.
• Without additional configuration (e.g. IGMP), multicast traffic is handled as broadcast on most networks.

Glossary

• DHCP: Dynamic Host Configuration Protocol automatically assigns IP addresses and subnet masks from a server or router. Convenient for large or changing networks.
• Link-local: An address in the 169.254.0.0/16 range that a device assigns to itself when no DHCP server is available (RFC 3927). The fallback mechanism is called APIPA on Windows and is part of Zeroconf / Bonjour on macOS; KLANG:app labels these addresses simply as link-local.
• Static IPs / Fixed IPs: Manually configured IP addresses and subnet masks ensure predictable network routing and are often used in dedicated audio networks.
• Subnet Mask: Defines which portion of the IP address belongs to the network and which part identifies the host device. All devices must share the same subnet to communicate directly.
• Gateway: The network router address that forwards traffic to other subnets or to the internet. Usually not required for closed audio networks.
• Routing table: The list your computer uses to decide which network adapter to send each message through. Overlapping IP ranges place conflicting entries in this list, which is the root cause of most discovery and connection problems (see Discovery Challenges).
• Unicast: One-to-one communication between two specific IP addresses.
• Broadcast: One-to-all communication within the same subnet (e.g. used for device discovery).
• Multicast: One-to-many communication to subscribed devices only. Used in networked audio systems such as Dante for efficient data distribution.

_{updated pdi 2026-06-08}