UPnP检测延迟

Question

我在Raspberry Pi上安装了RaspBMC,在Window笔记本电脑上安装了XBMC,在我的Android设备上安装了UPnPlay.Raspberry Pi始终处于打开状态,旨在充当系统的服务器.

IP地址涉及:

• 192.168.0.18:RPi

• 192.168.0.13:笔记本电脑

• 192.168.0.1:路由器

当我将Android设备连接到WiFi并打开UPnPlay或在笔记本电脑上启动XBMC时,之前在Raspberry Pi出现在设备列表中之前会有5-10分钟的延迟.然而,在过去的几周里,除非我在其他服务(XBMC或UPnPlay)运行时重启它,否则Pi根本不会出现.我可以ssh和sftp到Pi,并且可以从两个设备访问RaspBMC的Web界面,没有任何问题.

是否可能以某种方式丢失或阻止UPnP网络发现/通知消息？我该怎么调查这个？我对网络的了解仅限于端口转发.

我对UPnP的替代协议的建议持开放态度 - 我遇到的第一个很简单,它在我之前的设置(桌面上的XBMC将媒体发送到Apple TV)上工作得很好.

---

编辑:

在笔记本电脑上使用Wireshark进行的一些分析显示笔记本电脑的行为符合预期 - 通过SSDP定期发送M-SEARCH和NOTIFY数据包到239.255.255.250(我认为是多播地址).但是,RPi不仅没有响应这些带有单播数据包的数据包(正如维基百科建议的那样),而且除了在启动时它也没有发送任何SSDP数据包.

我对Wireshark和网络分析一般都很陌生,但我真的很感激你能给出的任何指导或建议.

我使用的Wireshark过滤器是"(udp.dstport == 1900或ip.addr == 192.168.0.18)和!(ip.src == 192.168.0.1)",其中192.168.0.18是我的RPi地址 - 我相信这是正确的,但正如我所说,我对Wireshark很新 - 请纠正我,如果我犯了错误!特别是,我假设RPi对M-SEARCH的多播响应会有ip.src = 192.168.0.18,但我不确定(可能是192.168.0.1或239.255.255.250)

---

编辑2:

在这篇文章的指导下,我跑了/sbin/route -n,并获得了以下输出.

pi@raspbmc:~$ /sbin/route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         192.168.0.1     0.0.0.0         UG    0      0        0 eth0
192.168.0.0     0.0.0.0         255.255.255.0   U     0      0        0 eth0

我不知道如何解释这个,但是,从链接线程中的其他注释来看,这似乎缺少多播条目.再一次,根据链接线程的建议,我运行sudo route add -net 239.0.0.0 netmask 255.0.0.0 eth0,添加了这个/etc/rc.local并重新启动了RPi - 但是,Pi仍然没有出现在UPnP客户端的网络设备列表中.我还尝试使用239.255.255.250作为多播地址(参见上面的编辑1),这给出了错误route: netmask doesn't match route address.

再次,在链接的帖子的指导下,我运行了已安装的tshark并运行sudo tshark -i et0 multicast | grep 192.168.0.18(我添加了grep因为我看到网络上其他设备之间的大量流量).

这是输出.

RPi确实发送了一组NOTIFY数据包,但很少发生(这条记录覆盖了近20分钟,只发出了两个集群).我相信ARP包作为描述在这里,这意味着缺少某些设备的MAC地址在网络上的其他设备.虽然这可能令人担忧(某些设备不止一次要求相同的地址 - 为什么他们"忘记"这个？),也许更令人担心的是这些数据包被发送的不足之处,以及即使它们被发送的事实,网络上的客户仍然没有拿起RPi.

所以,总结一下:

• RPi正在发送NOTIFY数据包,但很少发送.有没有办法控制这个？

• 即使RPi发送NOTIFY数据包(在正常的事件过程中,而不是在启动时),网络上的客户端也不会发现它的存在.

• RPi似乎没有响应M-SEARCH从其他设备发送的数据包.

Answer 1

是否可能以某种方式丢失或阻止UPnP网络发现/通知消息？

失去了,绝对不是.也许,在UPnP节点中,由于口语多播UDP的不正确实现而完全没有被发送的意义上被阻止.我经常在品牌认证的家庭娱乐设备中看到与RaspBMC类似的行为.

连接到UPnP网络的任何节点都必须通告自己:发送多播(即,地址239.255.255.250)UDP数据包,其内容与HTTP非常相似,但操作是NOTIFY.RaspBMC的这一部分显然效果很好 - 这就是我要求其他测试场景的原因.

然后,同一节点可以选择性地发现网络:再次发送带有动作的多播UDP数据包M-SEARCH,但与此相反NOTIFY,它实际上等待来自其他UPnP节点的单播响应.RaspBMC作为媒体服务器不需要这样做,因为它不需要知道其他节点.但是其他节点确实需要知道网络中的服务器,有些事情可能是错误的:

• XBMC/UPnPlay不发送此多播发现(不太可能,您说XBMC曾经为您工作)
• RaspBMC在第一次发现时扼流并且不发送预期的单播响应,仅在稍后发生
• XBMC/UPnPlay不理解RaspBMC发送的响应并将其丢弃

我该怎么调查这个？

在Windows笔记本电脑上,从Intel UPnP Developer Tools安装DeviceSpy.它一直被认为是UPnP控制点最可靠的实现.如果您的RasPi没有立即弹出,那么就是RaspBMC问题.它要么根本没有发送单播响应,要么响应不正确.

如果确实弹出,请从同一工具集运行Device Sniffer.启动XBMC或UPnPPlay并观察UPnP发现多播流量.如果M-SEARCH源自Windows或Android的预期IP地址但是RaspBMC没有弹出,那么就是RaspBMC问题.遗憾的是,该工具无法捕获RaspBMC的单播响应(如果有的话)

在最坏的情况下,安装Wireshark并将捕获过滤到RasPi的 IP地址.它会告诉您它是否发送了单播响应,您可以看到内容.