23
Broadcast wird von pfsense oder Switch eliminiert
Hallo zusammen,
nachdem ich jetzt dank Hilfe hier im Forum mein Netzwerk mit V-Lan's vernünftig zum Laufen gebracht habe, stehe ich vor dem nächsten Problem. Hier mal eine etwas überarbeitete Version des Aufbaus meines Netzwerks:
Nun wollte ich mein Audio-Equipment von Teufel wieder an den Start bringen. Insgesamt handelt es sich dabei um zwei W-Lan-Lautsprecher und zwei Raumfeld-Connectoren. Die Lautsprecher bleiben eigentlich via W-Lan, während ich beide Connectoren über Lan anschließen möchte. Zum Einen weil ich einen der beiden Connectoren für das Raumfeld-System als Host verwende und es da bei einer W-Lan-Anbindung regelmäßig Probleme mit dem Aufwachen auf dem StandBy gibt, zum Anderen weil der zweite Connector an seinem Standort keine stabile W-Lan-Verbindung mehr bekommt.
Der Host-Connector ist mit seinem Standort in der Übersicht als "Teufel-Host" bezeichnet, der zweite Connector hängt am GS1200-8HPv2.
Die Einrichtung des Systems erfolgt grds. über App, also von einem Endgerät aus, welches hinter einem der AP's befindet. Das Endgerät befindet sich im richtigen Subnetz, ebenso wie die beiden W-Lan-Lautsprecher, die logischer Weise auch hinter den AP's zu finden sind.
Die beiden Connectoren kann ich auch sofort in's W-Lan einbinden. Möchte ich sie allerdings über das Lan eingebunden haben, scheitert der Versuch und die Geräte werden nicht gefunden. Die Connectoren bekommen über den DHCP eine feste IP zugewiesen. Sobald ich den Connector anstecke taucht er auch im Netzwerk auf (ich finde ihn bei den DHCP-Leases, er steht auf aktiv, ich kann ihn anpingen). Er befindet sich auch im gleichen Subnetz wie das Endgerät über das ich ihn einbinden möchte. Grundsätzlich folgt die Konfiguration der Geräte folgendem Ablauf:
Es gibt in der App auch noch die Möglichkeit, dass die Connectoren ohne das lokale W-Lan gesucht werden. Da lauscht die App sofort nach dem Broadcast. Das klappt aber auch nicht.
Leider ist hier der Support etwas ratlos. Die sind ja auch keine Netzwerkgurus wie ihr, sondern auf ihr System ausgerichtet.
Meine Vermutung ist, dass der gesendete Broadcast nicht über die Switche oder über die pfsense gelangt.
Wenn du Tante Google nach diesem Problem bemühst, dann kommen nur Antworten in der Richtung wie ich es ursprünglich vor hatte: Wie überträgt man einen Broadcast von einem Subnetz in das Andere. Aber davon wurde mir plausibel abgeraten, deshalb habe ich jetzt für das ganze Client- und Mediengedöns ein eigenes Subnetz. Es werden auch alle Geräte um die es bei meinem Problem geht, dem richtigen Subnetz zugeordnet - nur um das nochmal zu erwähnen.
Wo und wie fange ich mit meiner Suche nach der Ursache an?
Vielen Dank
Stefan
nachdem ich jetzt dank Hilfe hier im Forum mein Netzwerk mit V-Lan's vernünftig zum Laufen gebracht habe, stehe ich vor dem nächsten Problem. Hier mal eine etwas überarbeitete Version des Aufbaus meines Netzwerks:
Der Host-Connector ist mit seinem Standort in der Übersicht als "Teufel-Host" bezeichnet, der zweite Connector hängt am GS1200-8HPv2.
Die Einrichtung des Systems erfolgt grds. über App, also von einem Endgerät aus, welches hinter einem der AP's befindet. Das Endgerät befindet sich im richtigen Subnetz, ebenso wie die beiden W-Lan-Lautsprecher, die logischer Weise auch hinter den AP's zu finden sind.
Die beiden Connectoren kann ich auch sofort in's W-Lan einbinden. Möchte ich sie allerdings über das Lan eingebunden haben, scheitert der Versuch und die Geräte werden nicht gefunden. Die Connectoren bekommen über den DHCP eine feste IP zugewiesen. Sobald ich den Connector anstecke taucht er auch im Netzwerk auf (ich finde ihn bei den DHCP-Leases, er steht auf aktiv, ich kann ihn anpingen). Er befindet sich auch im gleichen Subnetz wie das Endgerät über das ich ihn einbinden möchte. Grundsätzlich folgt die Konfiguration der Geräte folgendem Ablauf:
- Connector in den Setup-Modus versetzen; dadurch erzeugt er ein lokales W-Lan
- Mit dem Endgerät in dieses W-Lan eintreten
- Die App findet das Gerät und frägt nach, wo es hin soll (Kabelgebunden oder W-Lan, letzteres natürlich mit Angabe der SSID und des Keys)
- Die App überträgt die Daten an den Connector und dieser schaltet das lokale W-Lan ab. Dafür propagiert er anschließend in dem vorgegebenen Netz einen Broadcast.
- Das Endgerät wechselt wieder zurück in das W-Lan, sucht diesen Broadcast und registriert das Gerät in der App.
Es gibt in der App auch noch die Möglichkeit, dass die Connectoren ohne das lokale W-Lan gesucht werden. Da lauscht die App sofort nach dem Broadcast. Das klappt aber auch nicht.
Leider ist hier der Support etwas ratlos. Die sind ja auch keine Netzwerkgurus wie ihr, sondern auf ihr System ausgerichtet.
Meine Vermutung ist, dass der gesendete Broadcast nicht über die Switche oder über die pfsense gelangt.
Wenn du Tante Google nach diesem Problem bemühst, dann kommen nur Antworten in der Richtung wie ich es ursprünglich vor hatte: Wie überträgt man einen Broadcast von einem Subnetz in das Andere. Aber davon wurde mir plausibel abgeraten, deshalb habe ich jetzt für das ganze Client- und Mediengedöns ein eigenes Subnetz. Es werden auch alle Geräte um die es bei meinem Problem geht, dem richtigen Subnetz zugeordnet - nur um das nochmal zu erwähnen.
Wo und wie fange ich mit meiner Suche nach der Ursache an?
Vielen Dank
Stefan
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 7683797637
Url: https://administrator.de/forum/broadcast-wird-von-pfsense-oder-switch-eliminiert-7683797637.html
Ausgedruckt am: 27.12.2024 um 08:12 Uhr
23 Kommentare
Neuester Kommentar
Grundsätzlich wird Broadcast NICHT geroutet! Wenn also Handy und das andere Gerät sich in unterschiedlichen VLANs Befinden, hat die App auf den Handy ein Problem, wenn das finden mit Broadcast oder ARP funktioniert.
Jürgen
Jürgen
1
Hallo,
soweit mir bekannt, kommunziiert Teufel auch über mDNS. Ähnlich Sonos, Apple Airplay usw.
Intigriere dazu eine mDNS Reflektor in den entsprechenden VLAN. Z.b: mDNS Avahi.
Bei OPNsense gibts dazu ein fertiges Plugin os-mdns-repeater. Bei Pfsense nennt sich das glaub ich direkt "Avahi"
Gruß
soweit mir bekannt, kommunziiert Teufel auch über mDNS. Ähnlich Sonos, Apple Airplay usw.
Intigriere dazu eine mDNS Reflektor in den entsprechenden VLAN. Z.b: mDNS Avahi.
Bei OPNsense gibts dazu ein fertiges Plugin os-mdns-repeater. Bei Pfsense nennt sich das glaub ich direkt "Avahi"
Gruß
Zitat von @chiefteddy:
Grundsätzlich wird Broadcast NICHT geroutet! Wenn also Handy und das andere Gerät sich in unterschiedlichen VLANs Befinden, hat die App auf den Handy ein Problem, wenn das finden mit Broadcast oder ARP funktioniert.
Jürgen
Grundsätzlich wird Broadcast NICHT geroutet! Wenn also Handy und das andere Gerät sich in unterschiedlichen VLANs Befinden, hat die App auf den Handy ein Problem, wenn das finden mit Broadcast oder ARP funktioniert.
Jürgen
Das ist mir bekannt, deshalb befinden sich die Geräte ja alle im gleichen V-Lan (nur die physikalischen Schnittstellen sind unterschiedlich).
Zitat von @tech-flare:
Hallo,
soweit mir bekannt, kommunziiert Teufel auch über mDNS. Ähnlich Sonos, Apple Airplay usw.
Intigriere dazu eine mDNS Reflektor in den entsprechenden VLAN. Z.b: mDNS Avahi.
Bei OPNsense gibts dazu ein fertiges Plugin os-mdns-repeater. Bei Pfsense nennt sich das glaub ich direkt "Avahi"
Gruß
Hallo,
soweit mir bekannt, kommunziiert Teufel auch über mDNS. Ähnlich Sonos, Apple Airplay usw.
Intigriere dazu eine mDNS Reflektor in den entsprechenden VLAN. Z.b: mDNS Avahi.
Bei OPNsense gibts dazu ein fertiges Plugin os-mdns-repeater. Bei Pfsense nennt sich das glaub ich direkt "Avahi"
Gruß
Danke, werde ich dann gleich mal suchen. Brauche ich das auch wenn die Geräte im gleichen Subnetz / V-Lan sind?
Dann schau doch mal mit Wireshark, was die Teile so kommunizieren. (Im Zweifel am Switch einen Spiegel-Port einrichten).
Die Geräte haben alle eine IP aus dem richtigen Subnetz und können angepingt werden?
Jürgen
Die Geräte haben alle eine IP aus dem richtigen Subnetz und können angepingt werden?
Jürgen
Zitat von @chiefteddy:
Dann schau doch mal mit Wireshark, was die Teile so kommunizieren. (Im Zweifel am Switch einen Spiegel-Port einrichten).
Die Geräte haben alle eine IP aus dem richtigen Subnetz und können angepingt werden?
Dann schau doch mal mit Wireshark, was die Teile so kommunizieren. (Im Zweifel am Switch einen Spiegel-Port einrichten).
Die Geräte haben alle eine IP aus dem richtigen Subnetz und können angepingt werden?
Ja, haben sie. Wie setze ich Wireshark auf einen Broadcast an?
Broadcast hat immer die letzte Adresse im Subnetz --> Filter
Aber warum sollen 2 Geräte, die eine IP-Adresse haben, mittels Broadcast -Paketen kommunizieren. Das macht doch keinen Sinn!
Unicast --> 1 Sender, 1 Empfänger
Multicast --> 1 Sender, mehrere Empfänger
Broadcast --> 1 Sender, Empfänger sind alle im Subnetz (Broadcast-Domäne)
Also warum soll jemand etwas an alle senden, wenn er den einen Empfänger kennt? (IP von Sender und Empfänger sind jeweils bekannt)
Jürgen
Aber warum sollen 2 Geräte, die eine IP-Adresse haben, mittels Broadcast -Paketen kommunizieren. Das macht doch keinen Sinn!
Unicast --> 1 Sender, 1 Empfänger
Multicast --> 1 Sender, mehrere Empfänger
Broadcast --> 1 Sender, Empfänger sind alle im Subnetz (Broadcast-Domäne)
Also warum soll jemand etwas an alle senden, wenn er den einen Empfänger kennt? (IP von Sender und Empfänger sind jeweils bekannt)
Jürgen
Brauche ich das auch wenn die Geräte im gleichen Subnetz / V-Lan sind?
Du solltest vorher einmal generell etwas über Broad- und Multicast Forwarding im Layer 2 und Layer 3 lesen und vor allem verstehen. Die Fragestellung lässt da leider ziemliche Wissenslücken erahnen. 
Nur so viel...
- Bei Broadcasts gibt es sog "All net broadcasts" da ist die Destination IP 255.255.255.255 z.B. bei DHCP usw.
- Das andere sind Netzwerk spezifische Broadcasts die die Netzwerk Broadcast Adresse nutzen. Z.B. in einen Netzwerk 10.1.1.0 /24 dann die 10.1.1.255. UPnP usw.
- mDNS nutzt Multicast mit der Destination IP 224.0.0.251 oder IPv6 ff02::fb und dem UDP Port 5363 und der TLD .local. Die mDNS Multicast Adresse ist eine sog. Link Local Multicast Adresse mit einem TTL (Time To Live) von 1, sprich ist also prinzipbedingt nicht routebar. Hier musst du einen mDNS Reflector genutzen auf der pfSense. Siehe dazu auch hier!
Da du ja eher wild rumrätst und nicht wirklich weisst welche Verfahren die Kisten zur Erkennung denn nun wirklich nutzen gibst du in den Wireshark als Filter am besten die Hardware Mac Adresse dieser Geräte in den Wireshark Capture Filter ein um rein nur diesen Traffic zu sehen.
Das geht mit ether host 00:0C:CC:76:4E:07 was du als Filter Kriterium einträgst. Dann wird dir lediglich der Traffic von und zu dieser Mac Adresse angezeigt.
Leider ist hier der Support etwas ratlos.
Muss man sicher nicht weiter kommentieren. Traurig wenn nicht einmal der Hersteller selber seine Produkte kennt. Du bist aber sicher an einen einfachen Level 1 Supporter gelangt der lediglich erklären kann welche Knöpfe man wie drücken muss. Wenn man nach einem Level 2 Supporter fragt bekommt man auch deutlich bessere Antworten.Es wäre recht naiv zu glauben der Entwickler des Herstellers kennt sein Produkt nicht. Er wird logischerweise sehr wohl wissen was er implementiert hat und wie seine Technik in segmentierten IP Netzen funktioniert!!
Zitat von @aqui:
Nur so viel...
Das ist bekannt.Nur so viel...
- Bei Broadcasts gibt es sog "All net broadcasts" da ist die Destination IP 255.255.255.255 z.B. bei DHCP usw.
- Das andere sind Netzwerk spezifische Broadcasts die die Netzwerk Broadcast Adresse nutzen. Z.B. in einen Netzwerk 10.1.1.0 /24 dann die 10.1.1.255. UPnP usw.
- mDNS nutzt Multicast mit der Destination IP 224.0.0.251 oder IPv6 ff02::fb und dem UDP Port 5363 und der TLD .local.
Die mDNS Multicast Adresse ist eine sog. Link Local Multicast Adresse mit einem TTL (Time To Live) von 1, sprich ist also prinzipbedingt nicht routebar. Hier musst du einen mDNS Reflector genutzen auf der pfSense.
Siehe dazu auch hier!Da setzt meine zweite Frage auch an: Brauche ich das auch wenn ich mich im gleichen Subnetz befinde, aber auf zwei unterschiedlichen NICs? Das ist doch eigentlich kein Routing? Dein verlinktes Beispiel zu avahi ist ja von einem Subnetz auf ein Anderes.
Da du ja eher wild rumrätst und nicht wirklich weisst welche Verfahren die Kisten zur Erkennung denn nun wirklich nutzen gibst du in den Wireshark als Filter am besten die Hardware Mac Adresse dieser Geräte in den Wireshark Capture Filter ein um rein nur diesen Traffic zu sehen.
Nein, ich "rate" nicht. Ich setze voraus, dass die Auskunft des Herstellers der Wahrheit entspricht. Tut es das nicht, wird meine Suche zunächst ins Leere laufen und ich werde in der möglichen Alternative weitersuchen (mDNS).Das geht mit ether host 00:0C:CC:76:4E:07 was du als Filter Kriterium einträgst. Dann wird dir lediglich der Traffic von und zu dieser Mac Adresse angezeigt.
Dankeschön! Eine einfache Lösung - wenn man drauf kommt und das Hintergrundwissen mit einbezieht 
Muss man sicher nicht weiter kommentieren. Traurig wenn nicht einmal der Hersteller selber seine Produkte kennt. Du bist aber sicher an einen einfachen Level 1 Supporter gelangt der lediglich erklären kann welche Knöpfe man wie drücken muss. Wenn man nach einem Level 2 Supporter fragt bekommt man auch deutlich bessere
Richtig. Nur dass der LV1-Supporter mich mit meiner Frage an den LV2-Supporter weitergereicht hat. Von ihm kommt die Auskunft "Broadcast". Und, wie du oben schon angemerkt hast, der Broadcast läuft auf x.x.x.255. Nur, wie es so ist, läuft da vieles hin und her.
Du schreibst, dass beide Geräte eine IP aus dem gleichen Subnetz zugewiesen bekommen haben.
Warum soll denn dann die Kommunikation über Broadcast laufen?
Broadcast oder mDNS usw. dient doch eigentlich nur dazu, bevor man die IP kennt, ein Gerät (zur Erstkonfiguration) oder einen Dienst zu finden.
Wenn man dann die IPs kennt, braucht man kein Broadcast mehr.
Jürgen
Warum soll denn dann die Kommunikation über Broadcast laufen?
Broadcast oder mDNS usw. dient doch eigentlich nur dazu, bevor man die IP kennt, ein Gerät (zur Erstkonfiguration) oder einen Dienst zu finden.
Wenn man dann die IPs kennt, braucht man kein Broadcast mehr.
Jürgen
1Zitat von @chiefteddy:
Du schreibst, dass beide Geräte eine IP aus dem gleichen Subnetz zugewiesen bekommen haben.
Warum soll denn dann die Kommunikation über Broadcast laufen?
ICH kenne die IP, weil ich zum DHCP gesagt habe, dass die MAC xy die IP 1234 haben soll. Die App weiß das aber nicht und die App ist auch so, sagen wir mal "einfach" gehalten, dass du keine IPs eingeben kannst. Wenn die App das Gerät gefunden hat, dann zeigt sie dir das Gerät schon mit der IP an, ist diese allerdings nicht fest zugewiesen, dann bedarf es einem der Geräte die Zuweisung als Host, der dann angeblich (lt. LV2-Support) permanent broadcastet wo er ist um die App bei einer geänderten IP wieder "einzufangen". Hat er die App eingefangen, dann broadcastet er nach den anderen Geräten welche IP diese jetzt nun haben. Wie gesagt, so die Aussage des Supports.Du schreibst, dass beide Geräte eine IP aus dem gleichen Subnetz zugewiesen bekommen haben.
Warum soll denn dann die Kommunikation über Broadcast laufen?
Ich kann da selbst noch gar nichts dazu sagen, weil ich eben nicht weiß (nicht gewusst habe) wie ich danach zu suchen habe. Werde mich heut Nachmittag mal mit dem Tipp von aqui auf die Suche machen. Vielleicht weiß ich dann mehr.
Auf meine Frage:
hast du geantwortet:
Also: Haben die Geräte nun die von dir zugewiesenen IPs oder nicht??
Wenn nicht, bist du beim Konfigurations-Modus und dann bei Broadcast. Wann JA kennt die App nach der Konfiguration die IP und macht Unicast.
Das ist ja OK. Aber wenn die Geräte "eingefangen" sind, braucht es kein permanentes Broadcast mehr. Dass in gewissen Zeitabständen nach neuen Geräten gescannt wird, mag ja auch noch angehen.
So lange alle Geräte im selben Subnetz (VLAN) sind, ist das ja auch kein Problem: Alle finden sich.
Wenn sie sich NICHT finden, hast du ein Problem. Dann musst du mit Wireshark schauen, wer was "redet" und wer was "hört". Denn dann scheint jemand nicht richtig zu "hören" oder/und zu "reden".
Wenn dann alles "gut" ist, kommt der 2. Schritt: Geräte nicht im gleichen Subnetz (VLAN). Dann kommen die von @aqui beschriebenen Techniken zum Einsatz.
Jürgen
Die Geräte haben alle eine IP aus dem richtigen Subnetz und können angepingt werden?
hast du geantwortet:
Ja, haben sie.
Also: Haben die Geräte nun die von dir zugewiesenen IPs oder nicht??
Wenn nicht, bist du beim Konfigurations-Modus und dann bei Broadcast. Wann JA kennt die App nach der Konfiguration die IP und macht Unicast.
Wenn die App das Gerät gefunden hat, dann zeigt sie dir das Gerät schon mit der IP an, ist diese allerdings nicht
fest zugewiesen, dann bedarf es einem der Geräte die Zuweisung als Host, der dann angeblich (lt. LV2-Support)
permanent broadcastet wo er ist um die App bei einer geänderten IP wieder "einzufangen". Hat er die App
eingefangen, dann broadcastet er nach den anderen Geräten welche IP diese jetzt nun haben. Wie gesagt, so die
Aussage des Supports.
fest zugewiesen, dann bedarf es einem der Geräte die Zuweisung als Host, der dann angeblich (lt. LV2-Support)
permanent broadcastet wo er ist um die App bei einer geänderten IP wieder "einzufangen". Hat er die App
eingefangen, dann broadcastet er nach den anderen Geräten welche IP diese jetzt nun haben. Wie gesagt, so die
Aussage des Supports.
Das ist ja OK. Aber wenn die Geräte "eingefangen" sind, braucht es kein permanentes Broadcast mehr. Dass in gewissen Zeitabständen nach neuen Geräten gescannt wird, mag ja auch noch angehen.
So lange alle Geräte im selben Subnetz (VLAN) sind, ist das ja auch kein Problem: Alle finden sich.
Wenn sie sich NICHT finden, hast du ein Problem.
Dann musst du mit Wireshark schauen, wer was "redet" und wer was "hört". Denn dann scheint jemand nicht richtig zu "hören" oder/und zu "reden".Wenn dann alles "gut" ist, kommt der 2. Schritt: Geräte nicht im gleichen Subnetz (VLAN). Dann kommen die von @aqui beschriebenen Techniken zum Einsatz.
Jürgen
1
So, etz hab ich mal die Schittstellen nach Vorgabe von aqui "gewiresharked".
Nach dem FactoryReset kommt das an der LAN-Schnittstelle (die fehlenden Zeilen sind identisch mit den Zeilen 21 bis 42 - das wiederholt sich periodisch:
Versuche ich nun die Einrichtung über W-Lan (das funktioniert ja), dann sieht das Ganze so aus:
Versuche ich jetzt im Setup dem Connector zu sagen, dass er die LAN-Schnittstelle nehmen soll, dann schaut das so aus:
Die Gegenstelle, also die App auf dem Handy, reagiert aber nicht darauf. Warte ich nun bis der Connector das Setup verlässt und schaue dann auf die Schnittstelle, dann kommt das:
Aqui sagte, dass der TTL bei mDNS =1 ist. Nochmal die Frage: Stellt der Schritt über einen Switch im V-Lan schon ein Routing dar? Weil, im "alten" Netzwerk, so wie ich es zuvor hatte, waren zwischen Connector und App auch zwei Switche und der AP - nur halt nicht in einem V-Lan.
Und die zweite Frage auch nochmal: AVAHI - ich habe AVAHI schon an anderer Stelle genannt bekommen. Und genau diese Stelle war die, an der aqui schrieb, dass das Mist sei. Man route keinen Broadcast von einem Subnetz in ein Anderes. Mir fehlt hier jedoch das Verständnis, ob es im Zusammenhang mit verschiedenen Schnittstellen (mein Paket kommt in diesem Fall über die igc1.5 zur pfsense und geht über igc 0.5 wieder raus - oder umgekehrt) auch schon ein Routing ist für das ich einen Reflector bräuchte. igc0.5 und igc1.5 sind in der pfsense gebrückt und stellen ein Subnetz dar.
Nach dem FactoryReset kommt das an der LAN-Schnittstelle (die fehlenden Zeilen sind identisch mit den Zeilen 21 bis 42 - das wiederholt sich periodisch:
Aqui sagte, dass der TTL bei mDNS =1 ist. Nochmal die Frage: Stellt der Schritt über einen Switch im V-Lan schon ein Routing dar? Weil, im "alten" Netzwerk, so wie ich es zuvor hatte, waren zwischen Connector und App auch zwei Switche und der AP - nur halt nicht in einem V-Lan.
Und die zweite Frage auch nochmal: AVAHI - ich habe AVAHI schon an anderer Stelle genannt bekommen. Und genau diese Stelle war die, an der aqui schrieb, dass das Mist sei. Man route keinen Broadcast von einem Subnetz in ein Anderes. Mir fehlt hier jedoch das Verständnis, ob es im Zusammenhang mit verschiedenen Schnittstellen (mein Paket kommt in diesem Fall über die igc1.5 zur pfsense und geht über igc 0.5 wieder raus - oder umgekehrt) auch schon ein Routing ist für das ich einen Reflector bräuchte. igc0.5 und igc1.5 sind in der pfsense gebrückt und stellen ein Subnetz dar.
Es ist leider nicht eindeutig zu sehen ob es hier um UDP Broadcasts oder mDNS (AVAHI) oder um SSDP geht, denn der Trace zeigt von allem etwas.
Nach Letzterem zu urteilen geht es vornehmlich um SSDP.
Wenn es also wirklich mDNS ist wäre AVAHI der Schlüssel zum Erfolg. Wenn es SSDP ist nicht, andere Baustelle.
Gretchenfrage hier ist nur ob es wirklich Broadcast oder Multicast ist was verwendet wird? Leider zeigt der Trace ja von jedem etwas an aber das Gros ist nun mal SSDP.
Das kann man letzlich nur an den Mac Adressen der Endgeräte erkennen die wir in dem o.a. Trace ja leider nicht sehen können um in der Lage zu sein das eindeutig zuzuordnen. Ebenso fehlt eine Erklärung welches Gerät zu welcher IP Adresse gehört.
Die 239.255.255.250 aus deinem Trace ist ja keine Broadcast Adresse wie du als guter Netzwerk Admin ja auch selber weisst.
Sie gehört zu SSDP und ist aus dem Block der Administrative Scoped Multicast Adressen die im RFC 2365 definiert sind.
Kapitel 6.1 ordnet dort die SSDP Multicast Adresse dem sog. "Local Scope" zu wo zu befürchten ist das per Design hier die TTL mit 1 festgelegt ist.
Generell sind diese Multicast Adressen aber laut RFC routebar (TTL>1, siehe zur Thematik auch HIER) wie es ja oben für den "Organizational Block" beschrieben ist die per PIM Routing auch über Segmentgrenzen geroutet werden können oder mit dem Multicast Proxy Package Plugin der pfSense in andere Segmente übertragen werden können.
Leider hast du es versäumt eins der SSDP Pakete für diese Multicast Adresse einmal im detailed View des Wireshark aufzuklappen um im UDP Header des SSDP Paketes einmal das TTL Setting zu sehen.
Nach Letzterem zu urteilen geht es vornehmlich um SSDP.
Man route keinen Broadcast von einem Subnetz in ein Anderes
So pauschal wurde das nie gesagt oder du hast das missverstanden. In den meisten segmentierten IP Netzen muss das z.B. zwingend sein mit z.B. DHCP Forwarding wenn sinnvollerweise ein zentraler DHCP Server betrieben wird. Es gibt noch weitere sinnvolle Broadcast Forwarding Gründe wie UDP 9 (WoL) usw...Wenn es also wirklich mDNS ist wäre AVAHI der Schlüssel zum Erfolg. Wenn es SSDP ist nicht, andere Baustelle.
Gretchenfrage hier ist nur ob es wirklich Broadcast oder Multicast ist was verwendet wird? Leider zeigt der Trace ja von jedem etwas an aber das Gros ist nun mal SSDP.
Das kann man letzlich nur an den Mac Adressen der Endgeräte erkennen die wir in dem o.a. Trace ja leider nicht sehen können um in der Lage zu sein das eindeutig zuzuordnen. Ebenso fehlt eine Erklärung welches Gerät zu welcher IP Adresse gehört.
Die 239.255.255.250 aus deinem Trace ist ja keine Broadcast Adresse wie du als guter Netzwerk Admin ja auch selber weisst.
Sie gehört zu SSDP und ist aus dem Block der Administrative Scoped Multicast Adressen die im RFC 2365 definiert sind.
Kapitel 6.1 ordnet dort die SSDP Multicast Adresse dem sog. "Local Scope" zu wo zu befürchten ist das per Design hier die TTL mit 1 festgelegt ist.
Generell sind diese Multicast Adressen aber laut RFC routebar (TTL>1, siehe zur Thematik auch HIER) wie es ja oben für den "Organizational Block" beschrieben ist die per PIM Routing auch über Segmentgrenzen geroutet werden können oder mit dem Multicast Proxy Package Plugin der pfSense in andere Segmente übertragen werden können.
Leider hast du es versäumt eins der SSDP Pakete für diese Multicast Adresse einmal im detailed View des Wireshark aufzuklappen um im UDP Header des SSDP Paketes einmal das TTL Setting zu sehen.
Zitat von @aqui:
Die 239.255.255.250 aus deinem Trace ist ja keine Broadcast Adresse wie du als guter Netzwerk Admin ja auch selber weisst.
Ja, ist bekannt.Die 239.255.255.250 aus deinem Trace ist ja keine Broadcast Adresse wie du als guter Netzwerk Admin ja auch selber weisst.
Sie gehört zu SSDP und ist aus dem Block der Administrative Scoped Multicast Adressen die im RFC 2365 definiert sind.
Kapitel 6.1 ordnet dort die SSDP Multicast Adresse dem sog. "Local Scope" zu wo zu befürchten ist das per Design hier die TTL mit 1 festgelegt ist.
Das geht über meinen Horizont als "Papi-das-Internet-ist-kaputt-Admin" hinaus.Kapitel 6.1 ordnet dort die SSDP Multicast Adresse dem sog. "Local Scope" zu wo zu befürchten ist das per Design hier die TTL mit 1 festgelegt ist.
Deinen Link hatte ich gefunden, als ich die IP-Adresse gegoogelt habe. Also über Umwege, nicht direkt.
Leider hast du es versäumt eins der SSDP Pakete für diese Multicast Adresse einmal im detailed View des Wireshark aufzuklappen um im UDP Header des SSDP Paketes einmal das TTL Setting zu sehen.
Dein Wunsch sei mir Befehl:
Zu den IP-Adressen:
Die 207 ist die IP des Lan-Ports, die 209 die des W-Lan-Adapters. .1 ist bei mir das GW / DNS, .100 das Endgerät auf dem die App läuft und die .10 ist ne Cloud.
Was mich etwas verwundert hat, das aber nur am Rande, ist die Anfrage nach dem FactoryReset in der Zeile 6. Er frägt hier nach der IP .20. Die IP ist eigentlich die für den zentralen Raumfeld Connector reservierte IP, also über die MAC fest zugewiesene IP. Die kann das Gerät nach dem Reset gar nicht kennen. Und von der App hat sie die Adresse auch nicht gesagt bekommen, weil die App diese auch nicht kennt, bzw. zu dem Zeitpunkt als das Log entstanden ist, der Connector noch gar nichts von der App erfahren hat können.
Sieht gut aus! Time to Live = 4 und damit routebar! 👍 😉
Wenn du die Zeile 6 im ersten Screenshot meinst ist das ein ganz stinknormales ARP Paket weil der Adapter die Mac Adresse seines Gegenüber zur IP Adresse herausbekommen muss um überhaupt mit ihm kommunizieren zu können. Kommunikation von Endgeräten im L2 Ethernet basiert bekanntlich nur auf Mac Adressen.
https://de.wikipedia.org/wiki/Address_Resolution_Protocol
Wie kommst du jetzt auf ein Factory Reset??
ist die Anfrage nach dem FactoryReset in der Zeile 6.
Du sprichst in Rätseln? 🤔Wenn du die Zeile 6 im ersten Screenshot meinst ist das ein ganz stinknormales ARP Paket weil der Adapter die Mac Adresse seines Gegenüber zur IP Adresse herausbekommen muss um überhaupt mit ihm kommunizieren zu können. Kommunikation von Endgeräten im L2 Ethernet basiert bekanntlich nur auf Mac Adressen.
https://de.wikipedia.org/wiki/Address_Resolution_Protocol
Wie kommst du jetzt auf ein Factory Reset??
Die kann das Gerät nach dem Reset gar nicht kennen.
Muss sie aber irgendwie. Denn wie sollte sie sonst ein ARP für diese IP losschicken können?!
Hallo @aqui,
meinst du mit
Dann wird DHCP-Broadcast aber nicht geroutet sondern als Unicast an den DHCP-Server weitergeleitet.
Jürgen
meinst du mit
DHCP Forwarding
ein DHCP-Relay im Router bzw. L3-Switch?Dann wird DHCP-Broadcast aber nicht geroutet sondern als Unicast an den DHCP-Server weitergeleitet.
Jürgen
Zitat von @aqui:
Sieht gut aus! Time to Live = 4 und damit routebar! 👍 😉
Wenn du die Zeile 6 im ersten Screenshot meinst ist das ein ganz stinknormales ARP Paket weil der Adapter die Mac Adresse seines Gegenüber zur IP Adresse herausbekommen muss um überhaupt mit ihm kommunizieren zu können. Kommunikation von Endgeräten im L2 Ethernet basiert bekanntlich nur auf Mac Adressen.
Äh, für mich war das mit dem FactoryReset selbstverständlich...Sieht gut aus! Time to Live = 4 und damit routebar! 👍 😉
ist die Anfrage nach dem FactoryReset in der Zeile 6.
Du sprichst in Rätseln? 🤔Wenn du die Zeile 6 im ersten Screenshot meinst ist das ein ganz stinknormales ARP Paket weil der Adapter die Mac Adresse seines Gegenüber zur IP Adresse herausbekommen muss um überhaupt mit ihm kommunizieren zu können. Kommunikation von Endgeräten im L2 Ethernet basiert bekanntlich nur auf Mac Adressen.
Ich habe mit den Logs versucht darzustellen, was der Connector von sich gibt vom ersten Kontakt im Netzwerk bis zur fehlgeschlagenen Konfiguration. Also ein FactoryReset des Connectors. Hierbei sollten ja sämtliche Daten gelöscht und der Connector jungfräulich sein. Wenn du ihn dann ins Netz bringst, dann kennt er weder seine Umgebung, noch die App. Die App lernt er erst im Zuge der Konfiguration über das Insel-Wlan kennen, welches er beim Setup zur Verfügung stellt. Die IP 10.10.50.20 ist die IP, die der Host im Netz bekommen soll. Also ein anderes Gerät zu dem der Connector jetzt noch gar keinen Kontakt haben kann / sollte, weil er von dem Host nichts weiß.
Muss sie aber irgendwie. Denn wie sollte sie sonst ein ARP für diese IP losschicken können?!
Das frage ich mich in diesem Zusammenhang auch. Wenn dieses Gerät beim ersten Kontakt mit dem Netzwerk von dieser IP erfährt, dann muss ja der Host irgendwo seine Identität im Netz verteilen?Aber gut, wie komme ich jetzt drauf wo's klemmt?
Nochmal meine Fragen zum Routing: Zählt beim V-Lan der Schritt über einen Switch als Routing im Sinne vom TTL und braucht man das mDNS-Relay bereits bei zwei verschiedenen Schnittstellen die gebrückt sind und sich dadurch im gleichen Subnetz befinden?
Weiterhin bin ich auf diese Aussage von Zyxel gekommen. Ist das für mich relevant? Wäre es dann nicht im "alten Netz" auch nicht gegangen?
meinst du mit DHCP Forwarding ein DHCP-Relay im Router bzw. L3-Switch?
Du hast natürlich Recht. Der Vergleich hinkt technisch etwas aber letztlich bringt er diesen relevanten Traffic so in andere IP Segmente.Also ein anderes Gerät zu dem der Connector jetzt noch gar keinen Kontakt haben kann
Das mag sein aber wenn der Connector oder auch die Geräte mDNS oder SSDP Multicasts versenden (im gleichen Segment) dann machen sie sich ja IPtechnisch automatisch bekannt.Das wird dann nur unterbunden wenn man sie segmentiert und die Multicasts dann nicht greifen.
Zählt beim V-Lan der Schritt über einen Switch als Routing im Sinne vom TTL
Oha, die Frage zeugt eher von gravierenden Wissenlücken im Layer 2 und Layer 3.VLAN ist immer ausschliesslich Layer 2, weiss also nichts von IP Adressen, TCP/UDP und TTL usw. WO hast du den TTL Counter im Wireshark oben gefunden?? Richtig im UDP Header! Und...UDP ist welcher Layer?
Du kannst deine Frage nun ganz sicher selber beantworten, oder?! 😉
Naja, sagen wir mal ich habe schon davon gehört Nein, im Ernst, ich weiß was das OSI-Modell darstellt und was der Sinn dahinter ist. Und du hast Recht, da mein Wissen von Tante Google kommt, habe ich da meine Lücken.
Was ich aber bei deinen Ausführungen immer wieder zurate ziehe, ist der Wiki-Artikel über das OSI-Modell. Und genau da verwirrst du mich jetzt etwas mit der Aussage
Nein, im Ernst, ich weiß was das OSI-Modell darstellt und was der Sinn dahinter ist. Und du hast Recht, da mein Wissen von Tante Google kommt, habe ich da meine Lücken.Was ich aber bei deinen Ausführungen immer wieder zurate ziehe, ist der Wiki-Artikel über das OSI-Modell. Und genau da verwirrst du mich jetzt etwas mit der Aussage
VLAN ist immer ausschliesslich Layer 2, weiss also nichts von IP Adressen, TCP/UDP und TTL usw.
Und genau da hast du mich jetzt erwischt: Hier steht das anders und hier auch. Ebenso habe ich bei meinen Suchen nach Infos über das V-Lan diesen Artikel gefunden. Der sagt wiederum aus, dass Layer 2 bis zu 1024, Layer 3 bis zu 4096 V-Lans unterstützen. Da die Zyxel 4096 können und die vorstehend genannten Artikel von Layer 3 sprechen, war ich mir sicher, dass das V-Lan sich hier im Layer 3 bewegt und nicht im Layer 2.WO hast du den TTL Counter im Wireshark oben gefunden?? Richtig im UDP Header! Und...UDP ist welcher Layer?
Du kannst deine Frage nun ganz sicher selber beantworten, oder?! 😉
Äh, ja, laut OSI im Layer 4, also vermutlich fernab der Funktionalität der Schnittstellen in meinem V-Lan.Du kannst deine Frage nun ganz sicher selber beantworten, oder?! 😉
Der sagt wiederum aus, dass Layer 2 bis zu 1024
Was für ein Blödsinn doch so im Internet steht wenn der Tag lang ist...Sieht dir besser mal die offizielle 802.1q Spezifikation an:
https://de.wikipedia.org/wiki/IEEE_802.1Q
Man achte auch darauf in welchem Header das .1q Feld steht! 😉
Die VLAN ID im .1q Header hat qua definitionem 12 Bit = 2 hoch 12 = 4096 mögliche VLANs.
L3 VLANs sind immer ein Subset in einem L2 VLAN.
Fazit:
Halte dich an die offizellen RFC's und nicht den Unsinn von Computer Blöd oder Woche.
weiß was das OSI-Modell darstellt
Ist nur leider so, dass der TCP/IP-Protokollstack nicht nach OSI strukturiert ist.
Lies das mal:
https://de.wikipedia.org/wiki/Datenframe
Besonders IEEE802.1Q-Tag
Jürgen
1
So, nach einem ausgiebigen Selbststudium, was mich zwar mit etwas Backround versorgt hat, bin ich jetzt fast genauso weit wie vorher.
Nachdem ich jetzt so ziemlich am Ende bin mit meinem Latein, habe ich einfach mal ein bisschen rumexperimentiert. Beim Ausprobieren bin ich dann darauf gekommen, dass das System nur nicht funktioniert, wenn die pfsense dazwischen ist. Wenn du dir den Aufbau ansiehst, so wie ich ihn eingangs dargestellt habe, dann muss die Kommunikation zwischen mobilen Endgerät und den via LAN angeschlossenen Teufelkomponenten immer über die pfsense stattfinden. Jetzt habe ich einfach mal das gemacht (rote Verbindung in der Übersicht):
Und zack, hat sofort funktioniert.
Jetzt bin ich bei dem Punkt wo ich mich frage, warum muss ich irgendetwas in der pfsense konfigurieren, wenn ich doch die beiden Schnittstellen (in der Übersicht als igc0.5 und igc1.5 dargestellt) als "Bridge CLIENT" zusammengefasst habe und sie im selben Subnetz liegen? Der in der pfsense vorhandene IGMP-Proxy ist wohl für etwas anderes zuständig und Avahi ist dafür, laut Manual, nicht zu gebrauchen, weil es hierbei darum geht die Pakete von einem Subnetz in ein Anderes zu bringen.
Eine grundsätzliche Frage noch: Müssen die Switche in irgendeiner Art und Weise miteinander kommunizieren können?
Nachdem ich jetzt so ziemlich am Ende bin mit meinem Latein, habe ich einfach mal ein bisschen rumexperimentiert. Beim Ausprobieren bin ich dann darauf gekommen, dass das System nur nicht funktioniert, wenn die pfsense dazwischen ist. Wenn du dir den Aufbau ansiehst, so wie ich ihn eingangs dargestellt habe, dann muss die Kommunikation zwischen mobilen Endgerät und den via LAN angeschlossenen Teufelkomponenten immer über die pfsense stattfinden. Jetzt habe ich einfach mal das gemacht (rote Verbindung in der Übersicht):
Jetzt bin ich bei dem Punkt wo ich mich frage, warum muss ich irgendetwas in der pfsense konfigurieren, wenn ich doch die beiden Schnittstellen (in der Übersicht als igc0.5 und igc1.5 dargestellt) als "Bridge CLIENT" zusammengefasst habe und sie im selben Subnetz liegen? Der in der pfsense vorhandene IGMP-Proxy ist wohl für etwas anderes zuständig und Avahi ist dafür, laut Manual, nicht zu gebrauchen, weil es hierbei darum geht die Pakete von einem Subnetz in ein Anderes zu bringen.
Eine grundsätzliche Frage noch: Müssen die Switche in irgendeiner Art und Weise miteinander kommunizieren können?
So, was soll ich sagen...
Nachdem ich jetzt auch einen wirklich super Support seitens Zyxel bekommen und aqui's zahlreiche Hinweise aufgearbeitet habe war mir klar, dass mein Problem irgendwie homemade ist.
"Links" und "rechts" von der pfsense geht's, ist die pfsense dazwischen, dann geht's ned.
Die Switche waren auch richtig konfiguriert, aquis Grundstudium habe ich auch angewendet (hier an dieser Stelle übrigens ein ganz dickes DANKE AN AQUI für die ausführlichen Manuals hier auf der Plattform!!!), also muss es wohl an der pfsense liegen.
Hätt ich wohl mal richtig gelesen was man mir auf meine erste Frage zur pfsense geantwortet hat: Durch das bilden einer Bridge werden halt nun mal nicht die Firewallregeln der Schnittstelle umgangen oder aufgehoben...
Es war einzig und allein ein "pebkac-Problem" - wie es so nett genannt wird. Man ey, nicht nur dass ich eure Zeit in Anspruch genommen habe, sondern auch dass ich müssiger Weise zwei Wochen im Keller vor dem PC rumgegammelt bin.
Was soll ich dazu sagen: Vielen Dank für eure Hilfe und die zahlreichen Winks mit dem Zaunpfahl!
Nachdem ich jetzt auch einen wirklich super Support seitens Zyxel bekommen und aqui's zahlreiche Hinweise aufgearbeitet habe war mir klar, dass mein Problem irgendwie homemade ist.
"Links" und "rechts" von der pfsense geht's, ist die pfsense dazwischen, dann geht's ned.
Die Switche waren auch richtig konfiguriert, aquis Grundstudium habe ich auch angewendet (hier an dieser Stelle übrigens ein ganz dickes DANKE AN AQUI für die ausführlichen Manuals hier auf der Plattform!!!), also muss es wohl an der pfsense liegen.
Hätt ich wohl mal richtig gelesen was man mir auf meine erste Frage zur pfsense geantwortet hat: Durch das bilden einer Bridge werden halt nun mal nicht die Firewallregeln der Schnittstelle umgangen oder aufgehoben...
Es war einzig und allein ein "pebkac-Problem" - wie es so nett genannt wird. Man ey, nicht nur dass ich eure Zeit in Anspruch genommen habe, sondern auch dass ich müssiger Weise zwei Wochen im Keller vor dem PC rumgegammelt bin.
Was soll ich dazu sagen: Vielen Dank für eure Hilfe und die zahlreichen Winks mit dem Zaunpfahl!
