DNLA über Netzwerkgrenzen

00:11:32... hätte mir auch direkt auffallen können :rolleyes:😅 Sieht dann aber ja erstmal so aus, als würde die Syno dann auch nix von den anderen Geräten wissen. Die SSDP-Pakete kommen auch bei der Syno an? Geh mal via SSH auf die Syno, schwing Dich auf zum "root"-User und dann lässte mal jenen hier laufen: tcpdump -i eth0 -nev -s 0 udp port 1900 ... In eine Datei kannst Du das auch schreiben indem Du ein " > /pfad/dateiname.pcap" anhängst, so dass Du das dann wieder via Wireshark betrachten kannst.
 
Mein Fehler - da eine ist eher zum live gucken (-s 0), machste mal tcpdump -i eth0 -nev -s 65535 udp port 1900 -w /pfad/file.pcap
 
Ich bin mir nicht sicher, ob in "modernen" tcpdump's die Umleitung mit ">" ein valides pcap-File erzeugt. Die Umleitung mit ">" leitet nur den Output um. Ein korrektes pcap-File müsste man erhalten mit:
Code:
 tcpdump -i eth0 -nev -w ~/output.pcap udp port 1900

Ich bin mir auch nicht sicher, ob das von @blurrrr funktioniert.
machste mal tcpdump -i eth0 -nev -s 65535 udp port 1900 -w /pfad/file.pcap
Weil der Parameter "-w" nun hinter der "Capture Expression" steht, und ich glaube das alle Parameter/Optionen vor der Capture Expression sein müssten/sollten.
 
Zuletzt bearbeitet:
Ja, "~" zeigt normalerweise auf Dein Home-Verzeichnis (für root = /root/, für Benutzer = /home/<Benutzer/), mach das aber nicht, sondern setz dort den Pfad auf eine Syno-Freigabe (z.B. /volume1/<Freigabename>), denke, so wirst Du das ja das erste mal auch gemacht haben :)
 
Ich hab da mal ne Datei...die spricht nicht zu mir.
Leider kann ich die ja so nicht anhängen. Was wäre daraus genau interessant?
Ich habe mal ein Auszug als txt angehängt.
 

Anhänge

  • output.txt
    738 Bytes · Aufrufe: 3
Ich hab da mal ne Datei...die spricht nicht zu mir.
Bedeutet genau was? 😅

Aber jut, wir haben ja "Möglichkeiten"... ☺️ Also nächster Versuch: Ich denke mal, dass Du Wireshark "ganz normal" installiert hast bzgl. der Installationspfade... Dann: Öffnen wir einmal die Eingabeaufforderung und geben ein: "ssh <nas-admin-user>@<nas-ip>" ein. Da wird vermutlich zunächst erstmal eine Bestätigung eingefordert, welche Du mit "yes" beantwortest. Danach sollte die Passwortabfrage kommen. Ist das alles durch, landest Du - wie bisher gehabt - auf der Shell. Und jetzt wird es leider etwas hässlich, macht aber nix, kann man alles zurückstellen:

1) sudo su -
2) echo "<nas-admin-user> ALL=(ALL) NOPASSWD:ALL" >> /etc/sudoers

Mit letzterem Befehl kann <nas-admin-user> den Befehl "sudo" auch ohne Passwortabfrage eingeben, das ist für den nächsten Schritt leider wichtig, da ansonsten die Verbindung immer abbricht.

Jetzt meldest Du Dich wieder aus der SSH-Session ab und dann folgt das eigentliche Vorhaben - auch wieder in der Windows-Eingabeaufforderung:

3)
Bash:
ssh <nas-admin-user>@<nas-ip> "sudo /usr/sbin/tcpdump -i eth0 -U -w - 'not (host <deine-rechner-ip> and port 22)'" | "C:\Program Files\Wireshark\Wireshark.exe" -i - -k

Kurz zur Erläuterung (sofern überhaupt notwendig)...:
<nas-admin-user> = Dein administrativer Benutzer auf dem NAS (z.B. "fidibus")
<nas-ip> = System wo mitgeschnitten werden soll
<deine-rechner-ip> = IP von dem "Rechner" (Client) von welchem Du grade arbeitest. Somit wird die SSH-Verbindung zwischen Client und NAS nicht mitgeschnitten

Du kannst das jetzt a) laufen lassen und schon während des Mitschnitts in Echtzeit filtern, oder b) erstmal laufen lassen und dann "später" speichern/anschauen (als Datei eben). Was die Filterung angeht (einfach oben in die Filterzeile schreiben), so würde ich folgendes empfehlen:

1) ssdp
2) ip.addr==<ip-tv1> || ip.addr==<ip-tv2>
(alternativ geht auch statt "||" einfach ein "or")

Somit lassen sich die Dinge auch kombinieren, z.B. in Form von

3) ssdp && ip.addr==<ip-tv1>
oder
4) ssdp && (ip.addr==<ip-tv1 || ip.addr==<ip-tv2>)

Ausschliessen kannst Du ebenfalls, z.B. in Form von:
5) ssdp && ip.addr!=<ip-vom-funktionierenden-tv>

So... wenn Du Dich ausgetobt und ordentlich Informationen gesammelt hast, müssen wir noch das rückgängig machen, was wir initial verbrochen haben (die Passwort-lose Rechte-Erhöhung für den administrativen NAS-User).

Zunächst gehen wir wieder via SSH auf die Synology.... Da wir anfangs einfach via ">>" am Ende der betroffenen Datei eine Zeile angehängt haben, können wir es uns einfach machen und einfach wieder die letzte Zeile in dieser Datei löschen:

1) sudo su -
2) Einmal den Inhalt der Datei überprüfen: cat /etc/sudoers (auf die letzte Zeile achten)
3) Letzte Zeile entfernen: sed -i '$d' /etc/sudoers
4) Nochmal kontrollieren: cat /etc/sudoers (die Zeile mit dem Admin-User sollte dann weg sein)
5) "root" mittels "STRG+D" abmelden (wir sind dann wieder der administrative Benutzer)
6) Prüfen, ob wir auch kein Recht mehr haben, sudo ohne Passwortabfrage auszuführen: sudo ls

Wenn Du dann wieder nach einem Passwort gefragt wird, ist das System wieder im Ursprungszustand :)

... so langsam denke ich schon fast, dass das ggf. eine Anleitung für die Hauptseite wert wäre... 😅
 
@blurrrr : Danke für deine ausführliche Anleitung -> das hab ich fast alles erledigt
Der Mittschnitt bringt nur nicht das erhoffte Licht.
Ich kann nun natürlich den funktionierenden Sony noch einmal mitschnüffeln.
2 Dinge sind aktuell problematisch für mich:
1. Nach meiner Einschätzung nach ist auf der FW alles richtig - sonst würde gar nichts gehen
2. Warum erscheinen in der Geräteliste keine weiteren Geräte, vermutlich weil sie über eine Gateway "verschleiert" reinkommen.
Es geht die DNLA Integration von Denon/Heos im Homeassistant, der Denon selbst und der Sony TV.
Ich habe in der FW den Mittschnitt in post #34 mit einer Abweichung - HTTP/1.1 401 Unauthorized bei Samsung im Vergleich zum Rest. Im Synologics-Stream finde ich das nicht.
Daher spricht die Datei nicht zu mir, die ich auf der Syno mitgeschnitten habe.
Sozusagen kein Erkenntnisgewinn für mich - und die Frage, was kann ich davon einstellen, ihr wisst da mehr.
 
Mal blöd gefragt, die Samsung-TVs sind teil der Floating-Rule, oder nicht? Die anderen Geräte ggf.? Kannst halt nochmal hiermit testen (da weiss ich aber auch grade nicht genau), bei der gewünschten Firewall-Regel unter den erweiterten Optionen:

1695380110415.png
(Quelle: https://docs.netgate.com/pfsense/en/latest/troubleshooting/firewall.html#review-rule-parameters)

Das Beispiel was da aufgeführt ist, passt eigentlich nicht so ganz, allerdings ist der Proxy im Spiel und die betroffenen Hosts haben ja eigentlich eine andere MAC, nicht, dass das irgendwo zu Verwirrungen führt. "Eigentlich" dürfte das meiner Meinung nach keine Rolle spielen, da ja durchaus nochmal eine URL in den Paketen angegeben wird, aber wer weiss... ich würde es einfach mal einschalten, mal testen und entweder geht es dann, oder eben nicht, dann kann man die Option ja auch einfach wieder rausnehmen :)
 
Nach ausbleibendem Erfolg habe ich die floating rule wieder entfernt.
Dadurch sind keine Änderungen eingetreten.
Ich habe eine Gruppe aus allen IP's gebaut, die DNLA auf dem NAS erreichen möchten.
Dazu zählen 3x TV (2x Samsung, 1x Sony), Denon und HA.
Die floating rule war ja zum Schluss schon alles any ;).
Da ich nicht genau verstehe, an welcher Kommunikation das anzuhängen wäre, habe ich das komplette Regelwerk für die TV's mal damit ausgestattet.
 
Nach ausbleibendem Erfolg habe ich die floating rule wieder entfernt.
Dadurch sind keine Änderungen eingetreten.
Da ging es auch nur um das Logging der Firewall, so dass "alles" von der Firewall gelogged wird, was angegebene Dinge betrifft (die erlaubten Pakete, die geblockten sieht man ja - bei aktiviertem Logging - auch durch andere Regeln).
 
Zwischendurch die Geräte auch mal wieder neugestartet? 😁

Bin aber wie gesagt auch garnicht so im Thema was das Multimediazeugs angeht... Alternativ könntest Du aber vermutlich auch nochmal das Paket "PIMD" ausprobieren, was wohl bei einigen Personen schon zum Erfolg geführt haben soll. So wie ich das bisher gelesen habe, musst Du nur alle entsprechenden Interfaces - wo "kein" entsprechender Broadcast weitergeleitet werden soll - in der PIMD-Config deaktivieren.
 
Kann ich nicht finden.
Hatte da doch extra die offizielle pfSense-Paketliste verlinkt, da steht das Paket jedenfalls dabei.

FW ist ehr schlecht...Homeoffice.
Das dauert eine Minute oder so (wenn überhaupt)... 🤪 Betroffenen Personen im Haushalt kurz Bescheid geben und ab dafür. Alternativ kannst Du Dich natürlich auch mit einer kurzfristigen Internetstörung seitens des Providers rausreden, um den Hausfrieden zu wahren... 😜😂

Ich bin nun aber auch kurz vor der Aufgabe.
Also ich würde dran bleiben, es kann kein "unlösbares" Problem darstellen und selbst wenn es schlussendlich nicht läuft, wäre es doch trotzdem interessant zu wissen, ob es ggf. auch einfach an den Samsung-TV-Geräten liegt (was ich mir eigentlich nicht vorstellen kann).
 

Zurzeit aktive Besucher

Keine Mitglieder online.

Letzte Anleitungen

Statistik des Forums

Themen
4.590
Beiträge
46.960
Mitglieder
4.234
Neuestes Mitglied
andreassw14
Zurück
Oben