我在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：
在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数据包。
答案 0 :(得分：5)
UPnP网络发现/公告消息是否有可能以某种方式丢失或被阻止？
失去了，绝对不是。也许，在UPnP节点中，由于口语多播UDP的不正确实现而完全没有被发送的意义上被阻止。我经常在品牌认证的家庭娱乐设备中看到与RaspBMC类似的行为。
任何连接到UPnP网络的节点都必须通告自己：发送多播（即地址239.255.255.250）UDP数据包，其内容与HTTP非常相似，但操作为NOTIFY 。 RaspBMC 的这一部分显然效果很好 - 这就是我要求其他测试场景的原因。
然后，同一节点可以选择发现网络：再次发送带有动作M-SEARCH的多播UDP数据包，但与NOTIFY相反，它实际上等待来自其他网络的单播响应UPnP节点。 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地址。它会告诉你它是否发送了单播响应，你可以看到内容。
答案 1 :(得分：0)
您可能希望尝试将路由器与网络的其余部分断开连接（即所有其他设备可以相互看到但不能通过路由器看到） - 某些路由器会干扰＆＃39;与UPNP流量。这将告诉您路由器是否正在丢弃或阻止UPnP流量。 BT Homehubs特别有罪。