抓包分析DLNA——（1）设备发现

UPnP协议将整个通信过程分为五个步骤，分别是：

Step0：地址分配，也就是设备通过DHCP等协议获取IP地址的过程。UPnP通信的前提条件。

Step1：设备发现（Discovery），controlpoint通过这一步骤找到感兴趣的UPnP设备。

Step2：设备描述（Description），control point获取设备描述信息，从而了解设备所能提供的服务类型等具体信息。

Step3：设备控制（Control）。

Step4：Eventing。

Step5：Presentation。

 

本系列实例中所使用的环境：

DMS：VMware + Ubuntu14 + MiniDLNA1.13。IP地址是192.168.159.129。

DMP： Win7 + Foobar + foo_upnp插件（0.99.48）。 IP地址是192.168.159.1。

 

设备发现是UPnP的第一个步骤。对应协议栈如图所示：

SSDP的Notification一共有三种类型——ssdp:alive，ssdp:byebye和ssdp:update。当一个新设备加入到网络中后，按照协议应向网络中的控制点广播ssdp:alive通告，即advertisement。

在我们的环境中，在关闭Foobar的情况下首先启动miniDLNA。这时DMS立即连续发送了24条SSDP报文，即广播的advertisement。目的IP为协议中定好的广播地址239.255.255.250，断口号则固定为1900（[1]文档1.2节），如下图所示：

这24条报文可以分为4组，每组6条。第1-6条报文与第7-12条报文的内容完全一致。第13-18条报文与19-24条报文的内容一致。其中第三组报文构成一套完整的ssdp:alive通告，向网络中的其它设备宣告自己存在。第一组报文是与第三组报文内容相对应的ssdp:byebye通告。这是为了确保在发布alive通告之前，清除control point上可能存有的关于本设备及服务的旧的状态信息。第二组与第四组报文分别是第一组与第四组报文的重复，这是因为SSDP是基于非可靠的UDP传输，UPnP协议允许设备在发布通告的时候重复一两遍，以确保感兴趣的control point能发现自己。

我们主要分析一下第三组报文。

前三条报文一起构成了device的通告，其中CACHE-CONTROL字段描述了这条alive通告的生存时间。网络中的设备在发送首条alive通告之后，会每隔一段时间重复发送一套alive通告，或者叫做心跳报文。此条报文中max-age等于1800，即UPnP协议推荐的默认值（1800秒即30分钟），如果control point超过半个小时仍然没有收到下一条心跳报文，则会认为这个设备已经挂掉，并将该设备从可用设备列表中移除。

LOCATION字段包含了一个绝对路径的URL。在UPnP通信的第二个步骤设备描述中，control point将通过这个URL获得设备的描述信息。

三条报文的NT/USN字段各不相同。UPnP协议规定对于rootdevice来说，每次通告共需要发送三条报文。对应的NT字段分别是rootdevice，UUID和设备类型。如果设备还包含有embedded device的话，每个embedded device则只需要继续发送后两种NT字段构成的报文。这一部分的协议具体见文档[1]的29页。

后三条报文则分别通告了该设备所支持的服务（service）。分别是ContentDirectory，ConnectionManager和微软自己的X_MS_MediaReceiverRegistrar。

ContentDirectory的详细描述见文档[3]。主要是定义了mediaserver提供的文件浏览服务。miniDLNA支持这一服务后，control point就可以通过ContentDirectory:Browse动作来进行文件目录浏览。

ConnectionManager的详细描述见文档[2]。定义了设备间的流媒体传输模型。这两个实际上是DLNA MediaServer必不可少的service。

X_MS_MediaReceiverRegistrar是微软自己定义的服务，miniDLNA较新的版本支持这一服务主要是为了提供对Xbox的支持。

miniDLNA启动之后，再启动安装了foo_upnp插件的foobar。这相当于在windows主机中启动了一个MediaRenderer和一个MediaServer（通过Notify报文内容分析，两者实际上是作为两个独立的rootdevice），提供自己对应的服务。这部分SSDP报文的内容与上面分析的类似，也是在发送一套完整的ssdp:alive报文之前先发送一套完整的ssdp:byebye报文，MediaRenderer和MediaServer两个设备分别独立通告自己的设备类型，uuid以及提供的service等等。不做具体分析了。

做为control point的MediaRenderer，在广播完自己的通告报文之后，向相同的广播地址发送了一条search请求。这部分报文格式的详细描述见文档[1]的1.3。报文内容如下：

其中第一行M-SEARCH * HTTP/1.1表明这是一条search request信息。

MX：5是请求的最大等待时间，单位是秒。UPnP协议规定网络中响应请求的设备应该随机在0~最大等待时间范围内作出响应。这是为了避免网络规模较大时，大家同时给响应造成网络拥塞。同理control point也可以跟据网络的规模大小设定适当的最大等待时间。

MAN字段是为了遵守HTTP  Ex tension  Framework的协议规范，在这里是一个固定值。

最重要的字段是ST字段，即search target。在本例中target是rootdevice，那么随后miniDLNA作为rootdevice将给出回应。

前文说作为rootdevice，miniDLNA一共需要三条报文来通告自己的device。那么为响应control point的searchrequest，它只需要把对应于search target的一条通告报文重新发送一遍即可。如下：

简单总结一下，设备发现过程其实很好理解：

DMS启动：

                     大家好，我来了，我是rootdevice，我的uuid是xxx，我是MediaServer哦

                     我还能支持A服务，B服务和C服务哦~

                     （此后每隔一段时间发送一遍，表明我还活着）

DMR启动：

                     大家好，我来了，我是rootdevice，我的uuid是xxx，我是MediaRenderer哦

                     我还能支持D服务E服务和F服务哦~

                     （此后也要每隔一段时间重复发送一遍，生怕别人以为它挂了）

DMR：        对了，我是controlpoint，是rootdevice的吱一声呗~

DMS：

                     吱~~

（OK，设备发现完成！）

 

[1], UPnP-arch-DeviceArchitecture-v2.0-20140901.pdf   

[2], UPnP-av-MediaServer-v1-Device-20020625.pdf  

[3], UPnP-av-ContentDirectory-v1-Service-20020625.pdf

[4], UPnP-av-ConnectionManager-v1-Service-20020625.pdf

http://upnp.org/resources/upnpresources.zip 
http://upnp.org/resources/upnpresources.zip