Ich habe RaspBMC auf einem Raspberry Pi, XBMC auf einem Windows-Laptop und UPnPlay auf meinem Android-Gerät installiert. Der Raspberry Pi ist immer eingeschaltet und soll als Server für das System dienen.
Betroffene IP-Adressen:
192.168.0.18: RPi
192.168.0.13: Laptop
192.168.0.1: Router
Wenn ich das Android-Gerät mit WiFi verbinde und UPnPlay einschalte oder XBMC auf dem Laptop starte, hätte es vorher eine Verzögerung von 5-10 Minuten gegeben, bevor der Raspberry Pi in der Liste der Geräte auftauchte. In den letzten Wochen erscheint das Pi jedoch nur, wenn ich es neu starte, während die anderen Dienste (XBMC oder UPnPlay) ausgeführt werden. Ich kann ssh und sftp zum Pi, und kann auf RaspBMC Web-Schnittstelle von beiden Geräten ohne Probleme zugreifen.
Ist es möglich, dass UPnP-Netzwerk-Erkennungs- / Ankündigungsnachrichten verloren gehen oder irgendwie blockiert werden? Wie würde ich das untersuchen? Mein Wissen über Netzwerke beschränkt sich auf Portweiterleitung.
Ich bin offen für Vorschläge von alternativen Protokollen zu UPnP - es ist einfach die erste, die ich angetroffen habe, und es funktionierte gut auf meinem vorherigen Setup (XBMC auf dem Desktop Senden von Medien zu einem Apple TV).
BEARBEITEN:
Einige Analysen mit Wireshark auf dem Laptop zeigen, dass sich der Laptop wie erwartet verhält - Senden von M-SEARCH und NOTIFY-Paketen in regelmäßigen Abständen über SSDP an 239.255.255.250 (was ich für die Multicast-Adresse halte). Allerdings reagiert das RPi nicht nur auf diese Pakete mit Unicast-Paketen (wie es die Wikipedia vorschlägt), es sendet auch keine SSDP-Pakete, außer beim Booten.
Ich bin Wireshark und Netzwerkanalyse im Allgemeinen sehr neu, aber ich würde wirklich jede Anleitung oder Ratschläge, die Sie geben können, schätzen.
Der Wireshark-Filter, den ich verwendet habe, war "(udp.dstport == 1900 oder ip.addr == 192.168.0.18) und! (ip.src == 192.168.0.1)", wobei 192.168.0.18 die Adresse meines RPi ist - Ich glaube, das ist richtig, aber, wie gesagt, ich bin Wireshark sehr neu - bitte korrigiert mich, wenn ich mich geirrt habe! Insbesondere habe ich angenommen, dass die Multicast-Antwort des RPi auf M-SEARCH ip.src = 192.168.0.18 hätte, aber ich bin mir nicht sicher (es könnte denkbar sein, 192.168.0.1 oder 239.255.255.250)
EDIT 2:
Geführt von diesem Post habe ich /sbin/route -n ausgeführt und erhalten die folgende Ausgabe.
Ich kann das nicht interpretieren, aber nach anderen Kommentaren im verknüpften Thread scheint dieser Eintrag für Multicast zu fehlen. Nach diesem Ratschlag des verknüpften Threads habe ich sudo route add -net 239.0.0.0 netmask 255.0.0.0 eth0 ausgeführt,% ce_de% hinzugefügt und das RPi neu gestartet - das Pi erscheint jedoch immer noch nicht in der Liste der Netzwerkgeräte für UPnP-Clients. Ich habe auch versucht, 239.255.255.250 als Multicast-Adresse (siehe Edit 1, oben), die den Fehler /etc/rc.local .
Erneut, geleitet von dem verlinkten Beitrag, habe ich installiertes tshark ausgeführt und route: netmask doesn't match route address ausgeführt (Ich habe sudo tshark -i et0 multicast | grep 192.168.0.18 hinzugefügt, da ich viel Verkehr zwischen anderen Geräten im Netzwerk sah).
Hier ist die Ausgabe.
Das RPi sendet einen Cluster von grep -Paketen, aber sehr selten (dieser Datensatz deckt fast 20 Minuten ab und nur zwei Cluster werden gesendet). Ich glaube die NOTIFY Pakete sind wie beschrieben hier , was bedeutet, dass einigen Geräten MAC-Adressen für andere Geräte im Netzwerk fehlen. Obwohl dies potenziell besorgniserregend ist (bestimmte Geräte fragen mehrmals nach der gleichen Adresse - warum "vergessen" sie das?), Ist es vielleicht besorgniserregender, wie oft diese Pakete gesendet werden, und die Tatsache, dass sie gesendet werden , Clients im Netzwerk holen das RPi immer noch nicht ab.
Also, um zusammenzufassen:
RPi sendet ARP -Pakete, aber sehr selten. Gibt es eine Möglichkeit, dies zu kontrollieren?
Auch wenn das RPi NOTIFY -Pakete sendet (im normalen Ablauf von Ereignissen, nicht beim Booten), nehmen Clients im Netzwerk ihre Existenz nicht wahr.
RPi scheint nicht auf NOTIFY -Pakete zu antworten, die von anderen Geräten gesendet wurden.
Ist es möglich, dass UPnP-Netzwerk-Erkennungs- / Ankündigungsnachrichten verloren gehen oder irgendwie blockiert werden?
Verloren, definitiv nicht. Möglicherweise blockiert, in dem Sinne, dass es überhaupt nicht gesendet wird, weil das gesprochene Multicast-UDP falsch implementiert wurde, entweder in einem UPnP-Knoten. Ich sehe regelmäßig ein ähnliches Verhalten wie RaspBMC in markenzertifizierten Heimunterhaltungsgeräten.
Jeder Knoten, der eine Verbindung zum UPnP-Netzwerk herstellt, muss sich selbst ankündigen : Multicast-Adresse (also Adresse 239.255.255.250) mit HTTP-ähnlichen Inhalten senden, aber die Aktion lautet NOTIFY . Dieser Teil von RaspBMC funktioniert anscheinend gut - darum habe ich nach dem anderen Testszenario gefragt.
Derselbe Knoten kann dann optional das Netzwerk entdecken : erneut Multicast-UDP-Paket mit der Aktion M-SEARCH senden, aber im Gegensatz zu NOTIFY , wartet es tatsächlich auf Unicast-Antworten von anderen UPnP-Knoten. RaspBMC als Medienserver muss dies nicht tun, da er andere Knoten nicht kennen muss. Aber andere Knoten müssen über Server im Netzwerk wissen, und einige Dinge können falsch sein:
Wie würde ich das untersuchen?
Installieren Sie auf Ihrem Windows-Laptop DeviceSpy von Intel UPnP-Entwicklertools . Es wird durchweg als die zuverlässigste Implementierung des UPnP-Kontrollpunkts angesehen. Wenn Ihr RasPi nicht sofort angezeigt wird, ist es ein RaspBMC Problem. Es hat die Unicastantwort überhaupt nicht gesendet oder die Antwort ist falsch.
Wenn dies der Fall ist, führen Sie Device Sniffer aus demselben Toolset aus. Starten Sie entweder XBMC oder UPnPPlay und beobachten Sie den UPnP-Multicast-Datenverkehr. Wenn M-SEARCH von der erwarteten IP-Adresse von Windows oder Android stammt, aber RaspBMC nicht erscheint, dann ist es RaspBMC Problem. Das Tool kann die Unicast-Antwort von RaspBMC (falls vorhanden) leider nicht abfangen
Installieren Sie im schlimmsten Fall Wireshark und filtern Sie die Aufnahme auf die IP-Adresse von RasPi . Es wird Ihnen sagen, ob es die Unicast-Antwort gesendet hat oder nicht, und Sie können den Inhalt sehen.
Sie möchten vielleicht versuchen, dass Ihr Router vom Rest Ihres Netzwerks getrennt ist (d. h. alle anderen Geräte sehen sich gegenseitig, aber nicht über Ihren Router) - einige Router "stören" den UPNP-Verkehr. Dadurch erfahren Sie, ob Ihr Router den UPnP-Datenverkehr löscht oder blockiert. Vor allem BT Homehubs sind schuld.
Tags und Links raspberry-pi upnp xbmc