8

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

涉及的 IP 地址：

  • 192.168.0.18：树莓派

  • 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：

在这篇文章的指导下，我运行/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从其他设备发送的数据包。

4

2 回答 2

5

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

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

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

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

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

我将如何调查这个？

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

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

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

于 2012-12-05T09:49:48.960 回答
0

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

于 2014-07-18T20:26:40.977 回答