抓包分析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能发现自己。

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

NOTIFY * HTTP/1.1
HOST:239.255.255.250:1900
CACHE-CONTROL:max-age=1800
LOCATION:http://192.168.159.129:8200/rootDesc.xml
SERVER: 3.13.0-32-generic DLNADOC/1.50 UPnP/1.0 MiniDLNA/1.1.3
NT:uuid:4d696e69-444c-164e-9d41-000c29955b1d
USN:uuid:4d696e69-444c-164e-9d41-000c29955b1d
NTS:ssdp:alive

NOTIFY * HTTP/1.1
HOST:239.255.255.250:1900
CACHE-CONTROL:max-age=1800
LOCATION:http://192.168.159.129:8200/rootDesc.xml
SERVER: 3.13.0-32-generic DLNADOC/1.50 UPnP/1.0 MiniDLNA/1.1.3
NT:upnp:rootdevice
USN:uuid:4d696e69-444c-164e-9d41-000c29955b1d::upnp:rootdevice
NTS:ssdp:alive

NOTIFY * HTTP/1.1
HOST:239.255.255.250:1900
CACHE-CONTROL:max-age=1800
LOCATION:http://192.168.159.129:8200/rootDesc.xml
SERVER: 3.13.0-32-generic DLNADOC/1.50 UPnP/1.0 MiniDLNA/1.1.3
NT:urn:schemas-upnp-org:device:MediaServer:1
USN:uuid:4d696e69-444c-164e-9d41-000c29955b1d::urn:schemas-upnp-org:device:MediaServer:1
NTS:ssdp:alive

NOTIFY * HTTP/1.1
HOST:239.255.255.250:1900
CACHE-CONTROL:max-age=1800
LOCATION:http://192.168.159.129:8200/rootDesc.xml
SERVER: 3.13.0-32-generic DLNADOC/1.50 UPnP/1.0 MiniDLNA/1.1.3
NT:urn:schemas-upnp-org:service:ContentDirectory:1
USN:uuid:4d696e69-444c-164e-9d41-000c29955b1d::urn:schemas-upnp-org:service:ContentDirectory:1
NTS:ssdp:alive

NOTIFY * HTTP/1.1
HOST:239.255.255.250:1900
CACHE-CONTROL:max-age=1800
LOCATION:http://192.168.159.129:8200/rootDesc.xml
SERVER: 3.13.0-32-generic DLNADOC/1.50 UPnP/1.0 MiniDLNA/1.1.3
NT:urn:schemas-upnp-org:service:ConnectionManager:1
USN:uuid:4d696e69-444c-164e-9d41-000c29955b1d::urn:schemas-upnp-org:service:ConnectionManager:1
NTS:ssdp:alive

NOTIFY * HTTP/1.1
HOST:239.255.255.250:1900
CACHE-CONTROL:max-age=1800
LOCATION:http://192.168.159.129:8200/rootDesc.xml
SERVER: 3.13.0-32-generic DLNADOC/1.50 UPnP/1.0 MiniDLNA/1.1.3
NT:urn:microsoft.com:service:X_MS_MediaReceiverRegistrar:1
USN:uuid:4d696e69-444c-164e-9d41-000c29955b1d::urn:microsoft.com:service:X_MS_MediaReceiverRegistrar:1
NTS:ssdp:alive

前三条报文一起构成了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
MX: 5
ST: upnp:rootdevice
MAN: "ssdp:discover"
User-Agent: UPnP/1.0 DLNADOC/1.50 Platinum/1.0.4.2-bb / foobar2000
Connection: close
Host: 239.255.255.250:1900

其中第一行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的一条通告报文重新发送一遍即可。如下:

HTTP/1.1 200 OK
CACHE-CONTROL: max-age=1800
DATE: Sat, 25 Oct 2014 04:13:26 GMT
ST: upnp:rootdevice
USN: uuid:4d696e69-444c-164e-9d41-000c29955b1d::upnp:rootdevice
EXT:
SERVER: 3.13.0-32-generic DLNADOC/1.50 UPnP/1.0 MiniDLNA/1.1.3
LOCATION: http://192.168.159.129:8200/rootDesc.xml
Content-Length: 0

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

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


版权声明:本文为linearhit原创文章,遵循 CC 4.0 BY-SA 版权协议,转载请附上原文出处链接和本声明。
THE END
< <上一篇
下一篇>>