UPnP检测延迟

Posted 2023-04-15

【中文标题】UPnP检测延迟

【英文标题】：UPnP detection delay

【发布时间】：2012-11-21 06:53:06

【问题描述】：

我在 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 分钟的延迟。然而，在过去的几周里，Pi 根本没有出现，除非我在其他服务（XBMC 或 UPnPlay）正在运行时重新启动它。我可以 ssh 和 sftp 到 Pi，并且可以从两个设备访问 RaspBMC 的 Web 界面，没有任何问题。

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

我愿意接受有关 UPnP 替代协议的建议 - 这是我遇到的第一个简单协议，并且在我之前的设置（桌面上的 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

我不知道如何解释，但是，从链接线程中的其他 cmets 来看，这似乎缺少多播条目。同样，按照链接线程的建议，我运行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 数据包。

【问题讨论】：

先打开 Android 或 Windows，然后再打开 RasPi，会发生什么情况？你的 RaspBMC 会立即弹出吗？

好点，我忘记测试了！是的，重新启动 RPi 会可靠地使其出现在 UPnP 设备列表中。但是，如果我关闭并重新打开客户端应用程序，RPi 就会从列表中消失。

我已经开始为您编写故障排除方法，但我仍然无法相信 RaspBMC 作者会忽略一些重要的东西。当您“唤醒” Pi，然后重新启动/运行另一个节点（XBMC/UPnPlay）时，Pi 现在会立即弹出吗？ Pi OS（我猜是一些Linux）在不使用时是否有可能以某种方式部分休眠其网络​​接口？ UPnP 发现通过多播 UDP 工作，这并不常见。

部分网络接口休眠是我的猜测，但令人费解的是它会立即响应 ssh 和 sftp。我对多播 UDP 一无所知，所以恐怕不能在那里发表评论。不在家里的自动取款机 - 我一回来就测试。

嗯，这正是我已经开始为您编写的故障排除程序，以检查这些数据包是否存在。但后来想，嘿，这绝对是 UPnP 的基本部分，老实说，这应该适用于公共产品......我显然错了。

【参考方案1】：

UPnP 网络发现/公告消息是否可能会丢失或以某种方式被阻止？

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

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

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

XBMC/UPnPlay 不发送此多播发现（不太可能，您说过 XBMC 曾经为您工作） RaspBMC 在第一次发现时阻塞并且不发送预期的单播响应，仅在稍后发现 XBMC/UPnPlay 不理解 RaspBMC 发送的响应并将其丢弃

我将如何调查？

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

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

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

【讨论】：

感谢您提供出色的故障排除指南！在我自己的调查中，我已经跳到了“最坏情况”的场景，并且发现 Wireshark 有点难以掌握 - 我也会查看您推荐的其他工具。尽管问题尚未解决，但我接受此作为答案，因为我怀疑在没有深入了解 RaspBMC 系统的情况下任何人都可以提供更多建议，并感谢您的辛勤工作！

哦，不客气。如果您真的对 UPnP 的工作原理感兴趣，总有 UPnP Forum documentation 比您对此类官方文档的预期更具可读性（例如，与 IETF RFC 相比）

希望您不要介意，但我正在撤销您的回答的“已选择回答”状态。尽管这是一个非常有用且内容丰富的回复，我对此表示赞赏，但我仍然没有解决这个问题。我希望将这个问题标记为“未回答”会吸引更多人关注这个问题。

嗯，这似乎是我最终获得自己的 RPi 的一个理由 :) 但我不会在 6 天内完成 :( 无论如何，这一切似乎都是 RPi OS 路由的错误配置，而不是特定的UPnP 软件。15 分钟的 NOTIFY 节奏是正常的。它可以在 RaspBMC 设置中进行配置，但无需更频繁地进行配置 - 即在正常工作的 UPnP 网络中。

顺便说一句：我发现最好的 WireShark 过滤器只看到 SSDP 数据包是这样的：(udp contains "HTTP/1.1") and ((udp contains 0a:53:54 :3a) or (udp contains 0a:59:54:3a)) 十六进制为行首的“ST:”和“NT:”。

【参考方案2】：

您可能想尝试将您的路由器与网络的其余部分断开连接（即所有其他设备可以互相看到但不能通过您的路由器） - 某些路由器会“干扰”UPNP 流量。这将告诉您您的路由器是否正在丢弃或阻止 UPnP 流量。 BT Homehubs 尤其应受责备。