Do you know all your Dishwashers?

Dear JDisc friends,

we are constantly adding new protocols to improve device detection. The upcoming version (5106) will add two new main protocols to discover IoT devices:

  • mDNS (Multicast DNS)
  • UPnP (Universal Plug and Play)

What is mDNS and UPnP?

Home automation and IoT devices often support the mDNS and UPnP protocols to publish their services on the network and can be easily identified by mobile apps controlling these devices. Examples are smart TVs, home automation devices such as heating controls, dishwashers, alarm clocks, and some printers or even NAS devices. The purpose of these protocols is to integrate new devices into network environments quickly. You may have already experienced this when connecting your home automation devices to apps on your smartphone. Your smartphone performs these mDNS and UPnP multicast queries to find the devices it can connect to.

How does Discovery use the mDNS and UPnP protocols?

It is important to understand how these two protocols can be used to obtain device information. This works different from direct IP address based discovery using a number of different protocols to get information from a device.

UPnp and mDNS communication uses multicast messages. Whenever a device within a subnetwork sends an mDNS or UPnP discovery multicast message, all devices within the same subnetwork that support mDNS or UPnP respond with another multicast, sending a list of the services they offer and some basic device information (usually manufacturer, model, possibly serial number). This allows creating a list of devices including the services they offer and basic device information per subnetwork.

But there is one really important limitation: Typically, such multicast messages are not forwarded by routers. This means that only devices within the same subnetwork respond to multicast messages. UPnP and mDNS enabled devices in other subnetworks are unreachable and will not respond. Therefore, you will only get the devices that are on the same subnetwork as the discovery server.

We wouldn’t be discovery specialists if we couldn’t overcome this limitation :-). Remember we have our zero-footprint remote login agent (see The Remote Login Agent is deployed on Windows computers for the duration of the scan and allows to locally execute commands, query information, or read configuration files. We can use our zero-footprint agent to send mDNS and UPnP discovery messages to remote subnetworks on behalf of the discovery server. The JDisc Discovery server instructs the zero footprint agent to send an mDNS and UPnP discovery multicast message to its local subnetworks (red line). The agent then sends the discovery multicast messages to its local subnetworks (orange lines) and all devices that support these protocols respond to the agent (blue lines within the home or branch box). Finally, the agent collects the information from all devices responding to multicast messages and sends it back to the discovery server (blue line from desktop to JDisc Discovery server).

UPnP and mDNS together with the zero-footprint agent

Our approach is a major advantage over other solutions that either only get information from devices on the local network or require a permanently installed agent on remote networks. JDisc Discovery only needs access to any Windows computer on the remote network, which it often has anyway when scanning Windows computers.

How to configure mDNS and UPnP Discovery?

There is actually nothing special to configure. Both protocols are enabled by default, and whenever the discovery has access to a Windows computer on a remote network, it can run these queries remotely through the zero-footprint agent.

However, you can disable these protocols if you don’t want to use them for any reason. Just open the Protocols tab in the Discovery Configuration and disable mDNS and UPnP. The mDNS and UPnP timeouts define how long to wait for dicovery multicast responses from devices on each subnetwork.

Enable/Disable mDNS and UPnP protocol

How to deal with Home Office?

With Corona, working from home has become the norm in many organizations. Employees sit at home on the company laptop, but in many cases also use private devices such as monitors, printers, etc. For a discovery tool, it is impossible to understand whether a device is privately or company owned. When a laptop is scanned and the laptop is connected to an external display, information about that device is also collected – regardless of whether it is a personal or company-owned device. This can pollute a CMDB or confuse IT asset management systems. Also, you don’t want to include personal dishwashers, washing machines, TVs, or other home automation devices in your inventory database. Both for data protection reasons and to avoid confusing connected ITAM or CMDB solutions.

So we added a new option. Starting with build 5106, the Discovery can determine whether or not a PC or laptop is connected via a VPN.

Policy setting whether to scan attached devices when connected to VPN or not.

If this option is enabled and JDisc Discovery detects that a device is connected via VPN, no connected devices are collected and no mDNS and UPnP multicast discovery messages are sent. This avoids polluting your inventory database with privately-owned home and IoT devices.

What can you expect?

With mDNS and UPnP, you can expect to identify devices that were previously unknown. As an example, I’ve added a sample scan result from the JDisc home office. As you can see, Philips Hue Bridge, devices like Apple TVs, a Siemens dishwasher, and others have been discovered.

A sample report listing devices that replied to mDNS

The following report lists devices that responded to UPnP. Some devices respond to both protocols, but some only respond to one – like my Denon AVR1713 audio receiver.

Devices replying to UPnP.

Why do we need your help?

This feature is fairly new and we will surely need your help to cover as many devices as possible. Technically, the problem is that each UPnP and mDNS capable device returns a set of properties that depend on the manufacturer. There is either no or just little standard information. Therefore, we might need to create patterns to detect a set of models or devices.

We’ve added new reports listing unknown patterns that are similar to the existing unknown SNMP devices. By default, these reports are always part of the support zip. They do not contain IP addresses but only device-specific information. These reports are also available via Troubleshooting > Devices > Unknown UPnP Devices and Troubleshooting > Devices > Unknown mDNS devices.

If you find entries there, export the report as CSV and send it to us via a ticket (mail to or send it via the ticketing website:

A sample report for unknown mDNS devices

A final Warning!

With mDNS and UPnP JDisc Discovery will we get much more information about other devices when scanning a single device (Windows computer). Therefore, writing devices to the database may take a little longer. While this is not usually a big problem, we have customers who are scanning 200-300 devices in parallel and then the database operations can become a bottleneck. For these customers, we recommend disabling mDNS and UPnP unless really needed.


We hope you enjoy this new feature and we look forward to your list of unknown UPnP and mDNS devices! If there are any, please send them to us!


About The Author

Thomas Trenz
I own and manage JDisc and its network inventory and discovery products. Before I started JDisc, I worked quite a long time for Hewlett-Packard developing software for network assessments and inventory projects. Feel free to contact me on Linked-In or Xing.

Leave A Comment

The reCAPTCHA verification period has expired. Please reload the page.