KLANG:app does not discover any devices
- Make sure the KLANG processor is powered and the display or status LED are lid
- Check that a network cable is plugged into the control network port and that the network activity LEDs are blinking
- On your computer, deactivate and unplug all network adapters that are not required to connect to your KLANG hardware
The discovery process in more detail…
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 cannot 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. Firstly, check that the network cable is connected properly and the network connectivity and activity LEDs are blinking. Check that the device running KLANG:app has proper ethernet or WLAN connectivity and that it is connected to the same network as the KLANG hardware.
As a second troubleshooting step, make sure to temporarily disable firewalls.
KLANG:vier, :fabrik, :kontroller and :vokal use internally two different IP addresses. One for Dante connectivity and one for control data of the 3D in-ear mixing processor. Depending on the Dante switch configuration for fabrik: and :vier the two network ports are internally combined (default) or separated (redundant, switch separate control) or VLANs might be configured on :vokal or :kontroller.
In some cases, MS Windows prevents broadcast messages to be sent to all existing network adapters, so the handshake with KLANG:app cannot be completed successfully.
Workaround: Try to deactivate unused adapters like VMware or VirtualBox virtual adapters.
It might be necessary to check Firewall settings. Workaround: temporarily deactivity your computer’s firewall.
DHCP, Zero Conv, static / fixed IPs, Subnet masks, Gateway, Unicast / Broadcast / Multicast
IP Address Ranges
Private IP Address Range:
- 10.0.0.0 – 10.255.255.255 /8
- 172.16.0.0 – 172.31.255.255 /12
- 192.168.0.0 – 192.168.255.255 /16
Link Local Address Range (Auto IP)
- 169.254.0.0 – 169.254.255.255 /16
- 188.8.131.52 – 184.108.40.206
- Smaller, manageable subnets
- Restrict direct communication
The usual subnet masks:
- Class A: 255.0.0.0 CIDR: /8 16M devices
- Class B: 255.255.0.0 CIDR: /16 65k devices
- Class C: 255.255.255.0 CIDR: /24 256 devices
More specific examples…
- /20: 192.168.0.0 – 192.168.15.255 255.255.240.0 4096
- /28: 192.168.0.0 – 192.168.0.15 255.255.255.240 16
- Send only ONE message to ALL devices on the subnet
- It is calculated from own IP address and subnet mask
- Receivers need to have exact same broadcast address
- Exactly the same subnet mask
- No mix of 255.255.255.0 and 255.255.0.0 possible!
- Broadcasts can slow WiFi down to minimum speed
- Without further configuration e.g. IGMP multicasts are handled as broadcasts!
WHAT ARE DISCOVERY CHALLENGES?
- Partly overlapping subnets / not identical subnet mask
- Broadcast is not received. No answer. KLANG:app doesn’t see device.
- Check IPs and Subnet and correct.
- Two different subnets that overlap
- 2+ network interfaces e.g. on zero-conf auto-ip 169.254.0.0/16
- Windows PCs configure backup auto-ip although other IP configured
- WiFi interface might have additional auto-ip
- WiFi Internet DHCP server 192.168.1.0/24 vs. hardwired 192.168.0.0/16
- It is up to Operating System to decide on which network interface it sends out the broadcast connect request!