我在Raspberry Pi上安装了RaspBMC，在Windows笔记本电脑上安装了XBMC，并在我的Android设备上安装了UPnPlay。 Raspberry Pi始终处于打开状态，旨在用作系统的服务器。
涉及的IP地址:
当我将Android设备连接到WiFi并打开UPnPlay或在笔记本电脑上启动XBMC时，以前会有5到10分钟的延迟，Raspberry Pi才会出现在设备列表中。但是，在过去的几周中，除非我在其他服务(XBMC或UPnPlay)运行时重新启动它，否则Pi根本不会出现。我可以通过ssh和sftp到Pi，并且可以从两个设备访问RaspBMC的Web界面，而不会出现问题。
UPnP网络发现/公告消息是否可能因某种原因丢失或被阻止？我将如何调查？我对网络的了解仅限于端口转发。
我对UPnP替代协议(protocol)的建议持开放态度-这很简单，这是我遇到的第一个协议(protocol)，并且在我之前的设置(将媒体发送到Apple TV的桌面上的XBMC)上运行良好。
编辑:
对笔记本电脑上的Wireshark进行的一些分析表明，笔记本电脑的行为符合预期-在SSDP上定期发送M-SEARCH和NOTIFY数据包到239.255.255.250(我认为这是多播地址)。但是，RPi不仅不使用单播数据包响应这些数据包(如Wikipedia所建议的那样)，而且除了启动时，它也不发送任何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。因此，总结一下:
NOTIFY数据包，但是很少发送。有办法控制吗？ NOTIFY数据包(在正常情况下，而不是在引导过程中)，网络上的客户端也不会继续使用它。 M-SEARCH数据包。 最佳答案
输了，绝对没有。在任何一个UPnP节点中，可能是由于口头组播UDP的不正确实现而根本没有发送，因此被阻止了。我经常在品牌认证的家庭娱乐设备中看到与RaspBMC类似的行为。
连接到UPnP网络的任何节点都必须通告自己:发送多播(即到地址239.255.255.250)UDP数据包，其内容与HTTP非常相似，但操作为NOTIFY。 RaspBMC的这一部分显然运行良好-这就是为什么我要求其他测试方案的原因。
然后，同一节点可以选择发现网络:再次发送带有M-SEARCH Action 的多播UDP数据包，但与NOTIFY相反，它实际上等待来自其他UPnP节点的单播响应。 RaspBMC作为媒体服务器不需要这样做，因为它不需要知道其他节点。但是其他节点确实需要了解网络中的服务器，并且有些事情可能是错误的:
在Windows笔记本电脑上，从Intel UPnP Developer Tools安装DeviceSpy。一直认为它是UPnP控制点的最可靠实现。如果您的RasPi没有立即弹出，则是RaspBMC问题。它要么根本不发送单播响应，要么响应不正确。
如果确实弹出，请从同一工具集中运行“设备嗅探器”。启动XBMC或UPnPPlay并观察UPnP发现多播流量。如果有M-SEARCH来自Windows或Android的预期IP地址，但RaspBMC没有弹出，则是RaspBMC问题。不幸的是，该工具无法捕获来自RaspBMC的单播响应(如果有)
在最坏的情况下，请安装 Wireshark 并将捕获的内容过滤到RasPi的IP地址。它会告诉您是否发送了单播响应，您可以看到其内容。
关于UPnP检测延迟，我们在Stack Overflow上找到一个类似的问题：https://stackoverflow.com/questions/13689486/