Access and Discovery

In order to easily access and discover MKC devices in a network, a combination of the two protocols mDNS and DNS-SD is used.


The mDNS protocol allows to access the device over a human readable name instead of it's IP address without a central DNS server. This protocol uses broadcast packages to advertise its address to the local network. For more information about mDNS, please see the RFC 6762.

The human readable name of a MKC device consists of the device name in lowercase (enetcube, enetvario, enetmini, etc.), a hyphen, the last 6 hexadecimal digits of the MAC address and the mDNS top-level domain ".local". The digits of the MAC address ensure a unique mDNS address for each device.

the mDNS address of an eNetCube device with MAC address XX:XX:XX:1A:4B:8C

The mDNS name can be also found on the label on the device itself.

eNetCube label with mDNS address
Not all operating systems have mDNS address resolution built-in. For example Linux or Android. In this case a third party tool for mDNS has to be used.


The DNS-SD protocol is used to find devices/services in a local network. It uses broadcast messages to find and advertise the services. For more information on the protocol see the RFC 6763.

MKC devices will register and advertiste a _http._tcp service.

Example finding MKC devices using the dns-sd.exe tool on windows
> dns-sd.exe -B _http._tcp
Browsing for _http._tcp
Timestamp A/R Flags if Domain Service Type Instance Name
8:43:42.782 Add 2 9 local. _http._tcp. enetcube-ffffff

Using the instance name and domain from previous command we can resolve it to the IP address using the dns-sd tool:

> dns-sd -G v4 enetcube-ffffff.local
Timestamp A/R Flags if Hostname Address TTL
8:53:31.734 Add 2 9 enetcube-ffffff.local. 120

Since there could be multiple devices on the network, which advertise a _http._tcp service, an HTTP GET request can be made on the /api/v1/device endpoint of the REST API. This should return a hardware information structure, which identifies the device.