UPnP protocols scenario analysis

In this article, we present UPnP service and its protocols scenario between two UPnP devices (light, remote controler).

UPnP service:

Each UPnP device should get its own device ID(uuid) and offer some services (media player, printer, controller, etc) inside a network. Here we take the light device as an example.

The light’s information is stored in a XML file. We will not copy the XML here. But there are several important key values to know:

deviceType: urn:schemas-upnp-org:device:light:1
friendlyName: CyberGarage Light Device
modelName: Light
UDN: uuid: cybergarageLightDevice
serviceType: urn:schemas-upnp-org:service:power:1

uuid is the light’s ID inside the network, which can be recognized by other UPnP devices. serviceType describes the service offered by the light, which is “power”.

Check deeper, we can find all actions associated to the service “power”, which are: SetPower, GetPower, and light’s value state: 0 (on) or 1(off).

Protocols Scenario:

First of all, here is the UPnP stack presented by the official website:

Normally when a UPnP device (a light) presents in the network, it sends a broadcast message (SSDP) notifying others : “I’m a UPnP device” and offer some basic information, such as its uuid. After receiving the notify message, the remote controller (another UPnP device) sends back a request to get the light’s device description and all its available services. The light replies the controller with its XML description. Once these two devices are linked, and the remote controller knows every service available on the light device, the controller can send actions to the light. See the scenario presented below.

Protocols Scenario detected in Wireshark

In our test, IP address of the light is 10.77.5.19 and IP address of the remote controller is 10.77.5.17

Light (10.77.5.19) sends SSDP (broadcast, dst: 239.255.255.250) to notify its presents inside the network, which contains its uuid (cybergarageLightDevice). See the following figure.