Probleme beim Einsatz mehrerer Access Points

Dann solltest du nochmals genau deine Einstellungen durchgehen.

Nach allem, was den Netzwerkverkehr von und zu dem Drucker blockieren könnte.

Na welch ein Glück, dass er sich hier angemeldet hat. Auf die Idee wäre er ohne uns bestimmt nicht gekommen

Spaß beiseite.

Ich habe noch keine Zyxels konfiguriert aber Nebula ist doch der Cloud-Controller?! Kann es sein, dass die dort irgendwie "einzeln", bzw. getrennt konfiguriert sind?!

Die müssen im selben Account liegen, d.h. grundsätzlich die Konfiguration aus den selben Controllereinstellungen erhalten. Du machst dein Einstellungen in Nebula und "deployst" bzw. provisionierst dann die APs damit. Der eine Controller enthält dann also beide APs und betreut z.B. die Übergabe der Clients und Netzwerkverkehr.

Gruselig sowas öffentlich in einer Cloud zu machen ! Will man lieber nicht drüber nachdenken über die Folgen gänzlich Unbekannten Passwörter und Verschlüsselungen zu offenbaren....

Moin,

ich habe jetzt den kompletten Ablauf bzgl. AirPrint/ Multicast und IGMPv3/ IGMP Snooping nicht drauf, schmeisse das aber trotzdem einmal in den Raum.

Grundsätzlich kannst du ja auf die Geräte per direktem IP-Zugriff zugreifen.
Könnte es aber sein, dass du ein Problem mit fehlendem IGMPv3 hast, bzw. das nicht von allen Geräten supportet wird und daher zum erliegen kommt.

Ich würde mal am Laptop ein Wireshark anschmeißen und einen der beiden Ports am Switch mitschneiden, die einen AP angeschlossen haben. Dann mal schauen, welche Pakete mitgeschnitten werden, wenn dein smartphone am selben bzw. am anderen AP angeschlossen sind.

Und auch mal prüfen was in den TechSpecs bzgl. IGMPv3 enthalten ist.

Kann auch sein, dass mein Ansatz völlig daneben ist, weil ich eine Sache übersehen habe/ nicht weiss (siehe dazu mein ersten Satz), aber dümmer wird man dadurch ja nicht


ANsonste habe ich dies gerade noch gefunden:
https://community.bose.com/t5/SoundTouch-Lautsprecher/Soundtouch-10-Verb ...
Schaue mal, ob du die BOSE-Kiste mit einem Update versehen kannst
Das löst dann zwar das Drucker-Problem noch nicht, aber "mühsam nährt sich das Eichhörnchen" oder so ähnlich war das doch

Gruß
em-pie

AirPrint geht über direkten Link Local Multicast (Bonjour) dafür braucht er normal kein IGMP das geht einfach über Layer 2 Bridging. Ist eher zu vermuten wie Kollege @certifiedit.net schon sagt das die AP Teile im Router Mode arbeiten und zwischen WLAN und lokalem LAN routen.
Da der TO aber keinerlei weitere Angaben zur Konfig bzw. Setup der APs macht kann man hier nur wild im freien Fall raten. Fakt ist das Link Local Multicast (mDNS) wegen des fixen TTL von 1 nicht routebar ist und so an Routing Grenzen hängen bleibt ohne Proxy. AirPrint geht also ohne Bonjour Proxy rein nur im Layer 2 Bridging.
Die Symptome des TO sprechen für ein geroutetes Umfeld, im Minimum aber für einen Multicast Filter auf den APs.
Wie gesagt ohne weitere AP Setup Info ist das der Blick in die Kristallkugel...!

Naja, die Kollegen @Visucius spielen eben gerne Kindergartenbetreuung. Da kann das schonmal untergehen, was ich sage. Genau mit @aqui Meinung stimme ich überein. Aber gut, @Visucius, warum hilfst du Ihm dann nicht einfach direkt ;)

a) Firmware einheitlich?

b) Hängt einer der APs an Port 4 der Fritzbox (ggfs. indirekt)?

c) Versuche erst die LAN-Ports der diversen Switche udn prüfe per Kabel ob die Quer-Kommunikation funktioniert. Vielleicht liegts ja gar nicht am Wifi selber.

Viel Erfolg.

PS: Was hats denn mit 5.1 "The Zyxel Device is in standalone mode by default" auf sich?

Ein Fehler, denn damit deaktiviert man das schnelle Roaming zwischen den APs. Sollte besser aktiviert sein !
Ist falsch. Generell gibt es standartisiert nur 20 Mhz Bandbreite im 2,4 Ghz Band. 40 Mhz ist proprietär und man wir dann massiv von umlegenden WLANs gestört bzw. stört selber auch diese.
Siehe dazu auch:
Seit WLAN Umstellung von Cisco WAP 200 auf Zyxel NWA3560-N schlechtere Verbindung
Besser auf ein, denn das vermeidet sonst den weiten Bereich der besseren Outdoor Kanäle und kann zu Störungen mit Nachbar 5Ghz WLANs führen.
Kontraproduktiv. Hier sollte man immer mit einem freinen WLAN Scanner wie https://www.nirsoft.net/utils/wifi_information_view.html messen wie die aktuelle Verteilung ist und dort immer auf einen 4 kanaligen Abstand die APs manuell einstellen. Siehe WLAN Setup Tutorial oben.
Wenn man keine .11g Clients mehr hat besser anschalten um die Effizienz zu erhöhen. Bei Vorhandensein von .11g Clients dann auf nur g/n/a/ax Clients limitieren. keinesfalls das alte .11b Protokoll zulassen !
Das kannst du auf den WLAN Clients auch immer ganz einfach selber checken !!
Führe in der Eingabeaufforderung oder Powershell ein ipconfig aus (Windows)
Wenn du im WLAN die gleiche IP Netzwerk Adresse verwendest wie im kupferbasierten LAN, dann arbeiten deine APs im ganz normalen Layer 2 Bridging Mode !

Wenn dann schon "der" Kollege. In der Mehrzahl spreche ich von mir ausschließlich in dunklen Momenten

Mir liegt es natürlich fern zertifizierte Hilfestellung in Frage zu stellen! Nur wenn sich jemand anmeldet, weil bei seinem Auto ab 50 km/h hinten links was rappelt und die Antwort lautet:

a) musst halt nachschauen, was locker ist oder

b) hol Dir professionelle Hilfe – ich greife mal vor

Dann habe ich eigentlich nur Zeit verplempert.

Und deswegen ist Dein Bezug auf @aqui: leider etwas fehlplatziert. Der hat zwar beizeiten ne rustikale Ader ... aber seine Antworten lassen sich im schlechtesten Fall ergoogeln und bestenfalls hat er eine beeindruckende Trefferquote.

Aber das ist jetzt auch Kindergarten: Es ist Sonntag! In BY und vermutlich auch BW wieder mal wunderschönes Wetter.

In diesem Sinne ... GENUSS steht an!

Das klingt für mich alles zusammen nach einem Problem mit Multicast bzw. IGMP-Snooping - so wie @em-pie auch vermutet hat, aber direkt von aqui weggebügelt wurde.

Warum ich das denke:
Diese Geräteerkennung basiert im wesentlichen auf mDNS, welches mit Multicast betrieben wird.
Wenn entweder die Switches und/oder die Access-Points IGMP-Snooping betreiben, leiten sie nur Multicast-Gruppen weiter, für die sich auch mindestens ein Client registriert hat. Insbesondere bei WLAN-APs hast du dadurch den großen Vorteil, nur wirklich den Multicast-Traffic zu senden, der auch wirklich von mindestens einem Teilnehmer bekommen werden will und sparst Bandbreite.

Gerade in kaskadierten Switch- und Access-Point-Umgebungen funktioniert das öfter mal nicht so sauber, wie man sich das wünscht. Hier sollten die Switchports, an denen APs oder andere Switches hängen ("Uplink-Ports") so konfiguriert werden, dass alle Mutlicast-Gruppen weitergeleitet werden.
Bei ZyXEL gibt es da in der Regel die Möglichkeit, dies pro Switchport festzulegen.

Wenn dann das Problem weiter auftritt, kann man dem Access-Point ebenfalls mal testweise abgewöhnen, IGMP-Snooping zu machen.
Bei jeder Änderung sollten die WLAN-Clients einmal neu verbunden werden (also WLAN aus und wieder an), um das senden von IGMP-Joins zu wiederholen und neue mDNS-Suchen nach den Geräten anzustoßen.

Einige Geräte führen IGMP und IPv6-MLD getrennt zu konfigurieren auf. Da müsstest du dann notflals auch mal gucken, dass MLD-Snooping ebenfalls entsprechend konfiguriert wird.



Doch, du brauchst in halbwegs modernen Netzwerken IGMP resp. MLD, wenn du Multicast empfangen willst. Das ist ja Sinn der Sache: Du registrierst dich für Multicast-Gruppen, die du haben willst. Und wenn du dich augenscheinlich nicht interessierst, weil du dich eben in keiner Gruppe registrierst, dann bekommst du auch keinen Multicast. Sollte eigentlich jeder Netzwerker wissen!


IGMP-Snooping. Du sprichst von IGMP-Snooping


Im Übrigen möchte ich hier an dieser Stelle nochmal auf die "IP-Binsenweisheit" hinweisen:
Wenn der TO, wie er selbst mehrfach erklärt hat, auf den verkabelten Clients wie auch an den WLAN-Clients durchgängig das Subnetz 192.168.178.0/24 verwendet, können wir Routing auf den APs mit 100%iger Sicherheit ausschließen. Denn würden sie routen, kämen die Clients niemals ins Internet, da der AP ja zwingend auf dem WLAN- und dem RJ45-Interface das exakt gleiche Subnetz hätte und damit keine disjunkten Routen gegeben wären.
Die Geräte laufen also mit Sicherheit in AP-/Bridge-Modus und wir können wohl langsam aufhören zu suchen, ob sie nicht vielleicht doch irgendwo Router sind.

Richtig, das fackeln aber ohne diese Intelligenz immer auch die Endgeräte allein ab ! Abgebügelt hatte ich das nicht, das war dann missverständlich. Allerdings ist es nicht zwingend im Layer 2.
Multicast ist ja darauf ausgelegt das es auch in dummen, ungemanagten Netzen mit dummen Switches und APs funktioniert. IGMP Funktionen auf der Infrastruktur selber sind also niemals zwingend für die Funktion sonst könnten alle Nutzer mit solcher Hardware in der Praxis niemals Multicast basierte Funktionen nutzen, was ja nicht der Fall ist.
Dumme Infrastruktur Komponenten fluten dann halt im Layer 2 und Multicast funktioniert so trotzdem.
In intelligenten APs kommt dann noch die Multicast zu Unicast Konvertierung dazu sofern die sowas überhaupt haben. Aber auch das ist eben nicht zwingend aus Layer 2 Sicht. Airprint funktioniert auch mit einem 12 Euro Chinesen Switch und AP.
Auch das weiss man als Netzwerker !

Mahlzeit,
bei Ubiquiti, Meraki, Cisco und Aerohive kann man einstellen, dass Multicast von LAN auf WLAN und umgekehrt geblockt wird (werden kann).

Such mal danach im Controller, gerade wenn Endgerät und Drucker auf unterschiedlichen APs hängen, wird ja zwingend die LAN-Infrastruktur als Transportweg benutzt.

Wenn beide Geräteklassen auf demselben AP hängen, handelt der AP das Multicast direkt. Sieht man ja daran, dass es in der Konstellation funktioniert.

Und Routing fällt bei einem flachen Netz ja eh raus.

Blocking wäre dann aber kontraproduktiv für alle Multicast basierten Anwendungen. Das ist dann sicher auch nicht die Default Einstellung. Besser ist immer eine Multicast - Unicast Konvertierung im WLAN:
https://www.heise.de/ct/ausgabe/2014-14-Probleme-bei-Multicast-im-W-LAN- ...

b) Ist der Port 4 nicht als GästeLan konfigurierbar? Versuche doch mal die Ports 1 - 3 um das auf jeden Fall auszuschließen.

c) Gut, das ist aber auch schon Voraussetzung, damit die Dinger ins Netz kommen. Ich glaube ja immer noch, dass das eigentlich nicht an den APs, sondern an den Switchen liegt. Die beiden APs hängen ja vermutlich nicht am selben Switch?!
Da könntest Du ja den Weg nachvollziehen und den Unterschied suchen zwischen den beiden APs auf dem Weg zum Drucker.

VG

Was soll IMGP denn sein ??
Ein Screenshot dieser Einstellung wäre hilfreich. Das dediziert Ports zuzuweisen ist Quatsch.
Das ist auch richtig so, denn nur DER ist der relevante Port. Der andere wird meist rein nur als PPPoE Port benutzt wenn man die APs direkt ans Internet klemmt, was normal kein Mensch macht. Vergiss das also mit dem 2ten Port.
Ist so oder so das Sinnvollste. Seine AP Daten in eine anonyme Cloud zu senden an Empfänger die man nicht kennt ist eine griselige Vorstellungf. Kein normal denkender Mensch dem seine Datensicherheit etwas wert ist macht sowas. Aber muss auch jeder selber wissen.
Vermutlich das Zielführendste. Da darf man gespannt sein was die dann als vermeintliche Lösung anbieten !! Ist auch gleichzeitig mal ein Lackmus Test für deren Enduser Supportkompetenz.

wusst ichs doch

Das wäre sinnfrei, denn wenn IGMP Snooping auf dem Switch aktiviert ist macht der Switch das immer automatisch. Der tiefere Sinn von IGMP Snooping !
MC Setup Beispiel eines Cisco SG Switches:
Port spezifisch muss da niemals was eingestellt werden !

Du kannst das korrekte Multicast Handling im Heimnetz auch immer ganz einfach selber mal testen:
Fehlersuche im lokalem Netzwerk (RSTP, MRP, Multicast)