UPnP detection delay

Question

I have RaspBMC installed on a Raspberry Pi, XBMC on a Window Laptop, and UPnPlay on my Android device. The Raspberry Pi is always on, and is intended to act as the server for the system.

IP Addresses involved:

• 192.168.0.18: RPi

• 192.168.0.13: Laptop

• 192.168.0.1: Router

When I connect the Android device to WiFi and turn on UPnPlay or start XBMC on the laptop, previously there would have been a delay of 5-10 minutes before the Raspberry Pi appeared in the list of devices. For the past few weeks, however, the Pi does not appear at all unless I reboot it while the other services (XBMC or UPnPlay) are running. I can ssh and sftp to the Pi, and can access RaspBMC's web interface, from both devices, with no problems.

Is it possible that UPnP network discovery/announcement messages are being lost or blocked somehow? How would I investigate this? My knowledge of networking is limited to port forwarding.

I am open to suggestions of alternative protocols to UPnP - it's simple the first one I've encountered, and it worked fine on my previous setup (XBMC on desktop sending media to an Apple TV).

---

EDIT:

Some analysis with Wireshark on the laptop shows that the laptop is behaving as expected - sending out M-SEARCH and NOTIFY packets at regular intervals over SSDP to 239.255.255.250 (which I believe to be the multicast address). However, not only is the RPi not responding to these packets with unicast packets (as Wikipedia suggests it should), but it is also not sending out any SSDP packets, except on boot.

I'm very new to Wireshark and network analysis in general, but I'd really appreciate any guidance or advice that you can give.

The Wireshark filter that I used was "(udp.dstport == 1900 or ip.addr == 192.168.0.18) and !(ip.src == 192.168.0.1)", where 192.168.0.18 is my RPi's address - I believe this to be correct, but, as I said, I'm very new to Wireshark - please correct me if I have erred! In particular, I have assumed that the RPi's multicast response to M-SEARCH would have ip.src = 192.168.0.18, but I'm not certain of that (it could conceivably be 192.168.0.1 or 239.255.255.250)

---

EDIT 2:

Guided by this post, I ran /sbin/route -n, and obtained the following output.

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

I don't know how to interpret this, but, judging from other comments in the linked thread, this appears to be missing an entry for multicast. Again, following this advice from the linked thread, I ran sudo route add -net 239.0.0.0 netmask 255.0.0.0 eth0, added this to /etc/rc.local, and restarted the RPi - however, the Pi still does not appear on the list of network devices for UPnP clients. I also tried using 239.255.255.250 as the multicast address (see Edit 1, above), which gave the error route: netmask doesn't match route address.

Again, guided by the linked post, I ran installed tshark and ran sudo tshark -i et0 multicast | grep 192.168.0.18 (I added the grep since I was seeing a lot of traffic between other devices on the network).

Here is the output.

The RPi does send out a cluster of NOTIFY packets, but very infrequently (this record covers nearly 20 minutes and only two clusters are sent out). I believe the ARP packets are as described here, implying that some devices are missing MAC addresses for other devices on the network. Although this is potentially worrying (certain devices ask for the same address more than once - why are they "forgetting" this?), perhaps more worrying are the infrequencies with which these packets are sent, and the fact that, even when they are sent, clients on the network still do not pick up the RPi.

So, to summarise:

• RPi is sending out NOTIFY packets, but very infrequently. Is there a way to control this?

• Even when the RPi sends out NOTIFY packets (in the normal course of events, not at boot), clients on the network do not pick up on its existence.

• RPi does not appear to be responding to M-SEARCH packets sent from other devices.

Answer 1

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

Lost, definitely not. Blocked, perhaps, in the sense of not being sent at all due to incorrect implementation of the spoken multicast UDP, in either UPnP node. I am regularly seeing similar behavior to RaspBMC in brand certified home entertainment devices.

Any node connecting to UPnP network must advertise itself: send multicast (that is, to address 239.255.255.250) UDP packet with contents very similar to HTTP, but the action is NOTIFY. This part of RaspBMC apparently works well - that's why i asked for the other test scenario.

The same node can then optionally discover the network: again send multicast UDP packet with action M-SEARCH, but contrary to NOTIFY, it actually waits for unicast responses from other UPnP nodes. RaspBMC as media server doesn't need to do this, because it doesn't need to know other nodes. But other nodes do need to know about servers in the network, and several things may be wrong:

• XBMC/UPnPlay does not send this multicast discovery (unlikely, you said that XBMC used to work for you)
• RaspBMC chokes and does not send the expected unicast response at first discovery, only at some later
• XBMC/UPnPlay does not understand the response RaspBMC sent and throws it away

How would I investigate this?

On your Windows laptop, install DeviceSpy from Intel UPnP Developer Tools. It is consistently observed as the most reliable implementation of UPnP control point. If your RasPi does not pop up immediately, then it's RaspBMC problem. It either didn't send the unicast response at all, or the response is incorrect.

If it does pop up, run Device Sniffer from the same toolset. Start up either XBMC or UPnPPlay and observe the UPnP discovery multicast traffic. If there is M-SEARCH originating from the expected IP address of Windows or Android but RaspBMC does not pop up, then it's RaspBMC problem. The tool unfortunately can't catch the unicast response from RaspBMC (if there is any)

In the worst case, install Wireshark and filter the capture to IP address of RasPi. It will tell you whether it sent the unicast response or not and you can see the content.