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.

Stotts

What happens when you turn on Android or Windows first, and only then RasPi? Does your RaspBMC pop up immediately? – Cateran

Good point, I'd forgotten to test that! Yes, restarting the RPi reliably causes it to appear on the list of UPnP devices. If I close and reopen the client applications, however, the RPi has then disappeared from the list. – Stotts

I already started writing a troubleshooting howto for you, but i still can't believe that RaspBMC author would overlook something as important. When you "wake up" Pi, and THEN restart/run again the other node (XBMC/UPnPlay), does Pi pop up immediately now? Isn't it possible that the Pi OS (some Linux i guess) somehow partially hibernates its network interface when not in use? UPnP discovery works over multicast UDP which is not that common. – Cateran

Partial network interface hibernation was my guess, but it's puzzling that it responds instantly to ssh and sftp. I don't know anything about multicast UDP so can't comment there, I'm afraid. Not at home atm - I'll test as soon as I get back. – Stotts

ssh and sftp is unicast and most probably TCP too. In other words, something what Pi OS may be more correct to in handling. – Cateran

Interesting, thanks. I'll investigate further when I'm home. – Stotts

Thank you for your help and advice. I've ascertained that the RPi isn't sending out the NOTIFY packets, and nor is it responding to the laptop's M-SEARCH packets as it should be. I've directed to the question to the RaspBMC forums, since they will probably be able to provide more specialised advice. – Stotts

Well, that was exactly what i already started writing as a troubleshooter for you, to check existence of those packets. But then thought hey, it's absolutely basic part of UPnP, honestly this should be working for a public product... i was wrong apparently. – Cateran

I think i will post the troubleshooter anyway, regardless of whether you accept it or not. It might be useful for anyone googling a relevant knowledge. – Cateran

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.

Cateran

Thank you for this excellent troubleshooting guide! I'd already jumped to the "worst case" scenario in my own investigation, and was finding Wireshark a little difficult to get to grips with - I'll check out your other recommended tools as well. Although the problem's not fixed yet, I'm accepting this as the answer both because I doubt there's any more advice anyone could give without in-depth knowledge of the RaspBMC system and in thanks for your hard work! – Stotts

Oh, you're welcome. And if you are really interested how UPnP works, there's always the UPnP Forum documentation which is way more readable than you would expect from such official document (compared to IETF RFCs for example) – Cateran

I hope you don't mind, but I'm revoking the "chosen answer" status for your answer. Although it was a very helpful and informative response, which I appreciate, I still haven't fixed the issue. I'm hoping that having this question marked as "unanswered" will attract more eyes to the problem. – Stotts

Hmm, seems like a reason to get my own RPi finally :) But i won't make it in 6 days :( Anyway it all seems like misconfiguration of the RPi OS routing, not of the particular UPnP software. NOTIFY cadence of 15 minutes is normal. It might be configurable in RaspBMC setup, but there is no need to do it more often - that is, in a correctly working UPnP network. – Cateran

Just an aside: The best WireShark filter I have found to see just the SSDP packets is this: (udp contains "HTTP/1.1") and ((udp contains 0a:53:54:3a) or (udp contains 0a:59:54:3a)) The hex is "ST:" and "NT:" at the beginning of the line. – Chromaticness

Answer 2

You might want to try with your router disconnected from the rest of your network (i.e. all other devices can see each other but not through your router) - some routers 'interfere' with UPNP traffic. This will tell you if your router is dropping or blocking the UPnP traffic. BT Homehubs are particularly culpable.

Corposant