Richard J Green

The Anatomy of UPnP Device Discovery

Richard Green

Since my Cisco ICND1 training last week, I’ve become somewhat obsessed. I’ve previously been looking at NETGEAR routers to replace my current FVG318 as I am hitting the concurrent connection limit on it almost daily. Due to now seeing a little piece of Cisco, I figured why not look at getting a Cisco router so that the router will be more reliable and also will help give me some on the job training.

Everything was looking good until I thought about UPnP. I use UPnP quite heavily at home: Not for the port forwarding but for the internal advertisement of network services (namely media streaming to the PlayStation 3).

I discovered a few articles which outlined that Cisco doesn’t support UPnP on any of its devices and that it looks like there is no plan to add support for it either which is a bad thing if you are an SME looking for easy to deploy networking products but good from a security standpoint I suppose.

To test, on the FVG318, I disabled UPnP and had Nicky test the media streaming, however it didn’t work so today I took it upon myself to test this to ensure I can actually achieve full functionality using a Cisco 2651XM.

Firstly, I started my PC and PS3 so that they both got a DHCP lease from the router as Auto-IP is not to be relied upon even for this little test. After acquiring a lease on each of them, I moved the router into a different non-routed VLAN on the my switch, and a ping confirmed that the router was unavailable.

With Wireshark running, on my Windows 7 laptop, I opened the Network Sharing Center and enabled Media Streaming. Within thirty seconds of enabling this, the PS3 listed my laptop as a new media device on the XMB and I was able to browse the available media.

Here is the portion were interested in from the Wireshark trace:

The image above shows a Multicast packet from my laptop (00:1f:e2:c2:3d:c2) to the IPv4 Multicast address of 01:00:5e:7f:ff:fa (239.255.255.250) on port 1900 which is referred to as SSDP.

The contents of the packet is a HTTP NOTIFY and if you refer to the payload of the HTTP packet you can see that my laptop is advertising itself via HTTP on port 2869 and then advertising a path to a DLL file called udhisapi.dll.

Port 2869 is listed as ICSLAP with the port registrar and Port 1900, the port used by the original multicast broadcast is listed as SSDP. Both of these ports are what complete the UPnP connection process to must be available in both directions for things to work.

udhisapi.dll can be found in the %WinDir%System32 directory and has a file description of UPnP Device Host ISAPI Extension from Microsoft Corporation.

As per the image below, my laptop actually issues six Multicast packets to the same Multicast address all on Port 1900 however each one advertises a different service. They are as follows:

As per the UPnP Device Architecture document at http://www.upnp.org/specs/arch/UPnP-arch-DeviceArchitecture-v1.1.pdf a UPnP advertisement packet must contain a root device or embedded device discovery message.

As per the document, a root device issues three discovery messages, an embedded device issues two discovery messages and then finally one discovery message per service for that device. This information is on Page 27 of the upnp.org document referenced above.

The packets shown above are of the following types:

If this device is a new device on the network, the packets should contain the NTS:ssdp:alivern flag which can be seen in all six example packets, and is shown in the expanded view of the first packet above.

Although I cannot find anything concrete on the matter I’m guessing that the PlayStation 3 is acting upon the device:MediaServer advertisement. Upon receiving the Multicast packet for the media server advertisement, the PlayStation displayed the icon for the media server in the XMB, however the PlayStation nor any other devices on the network ACK the receipt of the Multicasts so you cannot confirm from the trace is this is the case.

Upon selecting the media server icon on the XMB for my laptop, the trace starts to show packets from the PlayStation (192.168.100.17) to my laptop (192.168.100.16). As I mentioned earlier, that packets for a UPnP session are sent to the destination computer on Port 2869. The source port is dynamic as to be expected.

Here is a sample packet from the PlayStation 3 to the laptop:

I’m going to be saving this trace as one for the archives. I will try to strip out the packets not related to the UPnP session and then put it up on my SkyDrive Public share for anyone to look at.

I had a great deal of trouble finding any important about UPnP transactions with the exception of the official document from the UPnP Forum, so if anyone has any questions about my findings then please let me know and I’ll do my best to help out.

Exit mobile version