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 替代协议(protocol)的建议 - 这是我遇到的第一个简单的协议(protocol)，并且在我之前的设置(桌面上的 XBMC 将媒体发送到 Apple TV)上运行良好。

编辑:

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

总的来说，我对 Wireshark 和网络分析非常陌生，但我真的很感激您提供的任何指导或建议。

我使用的 Wireshark 过滤器是“(udp.dstport == 1900 or ip.addr == 192.168.0.18) and !(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:

由 this post 指导，我跑了 /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，因为我看到网络上其他设备之间的流量很大)。

Here是输出。

RPi 确实发送了一组 NOTIFY数据包，但很少(此记录涵盖近 20 分钟，仅发送两个集群)。相信 ARP数据包如描述 here ，这意味着某些设备缺少网络上其他设备的 MAC 地址。尽管这可能令人担忧(某些设备不止一次请求相同的地址 - 为什么他们“忘记”了这一点？)，但也许更令人担忧的是这些数据包的发送频率不高，以及事实上，即使它们被发送，网络上的客户端仍然不拿起 RPi。

所以，总结一下:

RPi 发出 NOTIFY包，但很少。有没有办法控制这个？

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

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

Answer 1

Is it possible that UPnP network discovery/announcement messages are being lost or blocked somehow?

输了，绝对不是。在任一 UPnP 节点中，由于口语多播 UDP 的不正确实现，可能在根本没有被发送的意义上被阻止。我经常在品牌认证的家庭娱乐设备中看到与 RaspBMC 类似的行为。

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

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

XBMC/UPnPlay 不发送这个多播发现(不太可能，你说 XBMC 曾经为你工作)

RaspBMC 阻塞并且在第一次发现时不发送预期的单播响应，只有在稍后才会发送

XBMC/UPnPlay 无法理解 RaspBMC 发送的响应并将其丢弃

How would I investigate this?

在您的 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 地址。它会告诉你它是否发送了单播响应，你可以看到内容。