20
Clients gehen fest im WLAN-Netzwerk mit Unifi-APs
Hallo Community,
ich habe mein WLAN-Netz mit Unifi-APs gebaut und war recht überzeugt, dass das eine gute Idee ist.
Leider hab ich aber seit längerem ein massives Problem:
Die Clients (meist Handys) sind mit dem WLAN verbunden, alles funktioniert, wie es soll.
Nach einer Weile, Die Clients sind immer noch verbunden, geht schlicht nix mehr.
Einmal WLAN aus und wieder an, alles wieder gut (für eine Weile).
Das ist natürlich sehr unschön und nervt die User.
Ich habe schon so einige Anregungen aus dem Netz probiert, wie z.B. die manuelle Anpassung der Kanäle mit einem Abstand von möglichst 4.
Seitdem unser big Boss die Tage einem Kunden eine App auf seinem Handy vorführen wollte, was aus besagtem Grund schief ging, hat sich der Druck, eine Lösung zu finden, nur unwesentlich erhöht
Es handelt sich hierbei um ein WLAN, welches als VLAN konfiguriert ist und über die Firewall direkt ins Internet darf. Es gibt keine Restriktionen in diesem VLAN, da die Handys alles mögliche an Ports wollen (deshalb ein eigenes Netz). Allerdings können diese Clients nicht ins interne LAN (auch nicht nötig).
Verbaut habe ich am Hauptstandort, wo ich diese Probleme habe 9 AP-AC-pro, 1 AP-nanoHD, 1 UBB Bridge.
Der Controller läuft auf einem dedizierten Windows-Server in der aktuellsten Version, die APS sind auch auf aktuellsem Stand.
Die Bridge und dem Nano sind später dazu gekommen, allerdings bestand das Problem schon vor der Erweiterung.
Zusätzlich gibt es 4 weitere vernetzte Standorte mit je 2-3 APs, die auch über den Controller in der Zentrale verwaltet werden.
Ich würde mich über Tips und Hilfe sehr freuen!
ich habe mein WLAN-Netz mit Unifi-APs gebaut und war recht überzeugt, dass das eine gute Idee ist.
Leider hab ich aber seit längerem ein massives Problem:
Die Clients (meist Handys) sind mit dem WLAN verbunden, alles funktioniert, wie es soll.
Nach einer Weile, Die Clients sind immer noch verbunden, geht schlicht nix mehr.
Einmal WLAN aus und wieder an, alles wieder gut (für eine Weile).
Das ist natürlich sehr unschön und nervt die User.
Ich habe schon so einige Anregungen aus dem Netz probiert, wie z.B. die manuelle Anpassung der Kanäle mit einem Abstand von möglichst 4.
Seitdem unser big Boss die Tage einem Kunden eine App auf seinem Handy vorführen wollte, was aus besagtem Grund schief ging, hat sich der Druck, eine Lösung zu finden, nur unwesentlich erhöht
Es handelt sich hierbei um ein WLAN, welches als VLAN konfiguriert ist und über die Firewall direkt ins Internet darf. Es gibt keine Restriktionen in diesem VLAN, da die Handys alles mögliche an Ports wollen (deshalb ein eigenes Netz). Allerdings können diese Clients nicht ins interne LAN (auch nicht nötig).
Verbaut habe ich am Hauptstandort, wo ich diese Probleme habe 9 AP-AC-pro, 1 AP-nanoHD, 1 UBB Bridge.
Der Controller läuft auf einem dedizierten Windows-Server in der aktuellsten Version, die APS sind auch auf aktuellsem Stand.
Die Bridge und dem Nano sind später dazu gekommen, allerdings bestand das Problem schon vor der Erweiterung.
Zusätzlich gibt es 4 weitere vernetzte Standorte mit je 2-3 APs, die auch über den Controller in der Zentrale verwaltet werden.
Ich würde mich über Tips und Hilfe sehr freuen!
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: 1486193696
Url: https://administrator.de/forum/clients-gehen-fest-im-wlan-netzwerk-mit-unifi-aps-1486193696.html
Ausgedruckt am: 22.12.2024 um 23:12 Uhr
20 Kommentare
Neuester Kommentar
Moin,
Was meldet dein Controller dann, wenn nix mehr geht?
Geht dann kein Ping mehr (intern, extren)?
Ist das komplette WLAN nicht mehr da oder schaltest du auf dem Client das WLAN aus und wieder an?
Du siehst schon:
Geht nix mehr, ist eher keine qualifizierte Fehlermeldung
Nach einer Weile, Die Clients sind immer noch verbunden, geht schlicht nix mehr.
Was heißt das denn?Was meldet dein Controller dann, wenn nix mehr geht?
Geht dann kein Ping mehr (intern, extren)?
Ist das komplette WLAN nicht mehr da oder schaltest du auf dem Client das WLAN aus und wieder an?
Du siehst schon:
Geht nix mehr, ist eher keine qualifizierte Fehlermeldung
Der Controller läuft auf einem dedizierten Windows-Server in der aktuellsten Version
Tut das wirklich Not?! Das ist doch so nen Java-Gefrickel. Könntest Du nicht einfach mit HyperV nen Linux-Basis hernehmen?! Mich erinnert das ein wenig an eine alte Installation von mir auf dem (alten) Unifi-Controllerstick. Der war so limitiert, dass das System irgendwann einfach ausstieg.
So ungefähr: https://davidshomelab.com/unifi-controller-setup-on-ubuntu-20-04lts/
Viele Grüße
PS: Mal probiert im "gefrorenen" Zustand die clients rauszuwerfen um zu sehen ob sie bei einer Neuverbindung wieder laufen?
PPS: Betrifft das alle Clients gleichzeitig ... oder nur Clients an einem Standort?! Grundsätzlich läuft das Wifi nämlich unabhängig vom Controller. Den kannste prinzipiell auch abschalten.
PPPS: Wie authentifizieren sich die Clients denn?! Wie ist der Netzwerkaufbau?! Was "startest" Du genau neu? Wie groß ist die Anzahl "clients"? usw.
@goscho
da hast du wohl recht, eine qualifizierte Fehlermeldung ist was anderes :D
Ich wollte sagen, der Client (das Handy) ist noch mit dem WLAN verbunden, hat aber keinen Internet-Zugriff mehr. Am Handy WLAN aus und wieder an, alles wieder für eine Weile ok.
@Visucius
Not tut das sicher nicht, ist aber schöner zu handhaben. Ob ich da nun ein Windows oder ein Linux verwende ist wurscht, es bleibt ein dedizierter Server. Wenn es dir um eine verschwendete Lizenz und spärliche Leistung geht, da kann ich dich beruhigen. Ich habe eine Datacenter und einen ausreichend großen ESXi.
da hast du wohl recht, eine qualifizierte Fehlermeldung ist was anderes :D
Ich wollte sagen, der Client (das Handy) ist noch mit dem WLAN verbunden, hat aber keinen Internet-Zugriff mehr. Am Handy WLAN aus und wieder an, alles wieder für eine Weile ok.
@Visucius
Not tut das sicher nicht, ist aber schöner zu handhaben. Ob ich da nun ein Windows oder ein Linux verwende ist wurscht, es bleibt ein dedizierter Server. Wenn es dir um eine verschwendete Lizenz und spärliche Leistung geht, da kann ich dich beruhigen. Ich habe eine Datacenter und einen ausreichend großen ESXi.
Naja, das klingt aber doch eher so, als ob irgendwas "überläuft". DHCP kanns nicht sein oder?
Laufen die Wifi-Clients im eigenen vLAN? Wie viele Clients hängen denn an so nem AP?
Laufen die Wifi-Clients im eigenen vLAN? Wie viele Clients hängen denn an so nem AP?
und einen ausreichend großen ESXi
Sorry, aber unter den Voraussetzungen gehört der Controller separiert in eine Ubuntu-VM.
Wir betreiben ein Unifi-WLAN mit eben Ubuntu-basiertem Controller und haben die Probleme nicht.
Das wäre der erste Schritt....Controller auf anständiges OS
Gruß
Looser
Das wäre der erste Schritt....Controller auf anständiges OS
Meine Worte Ich greife dann schon mal vor:
"An allem ist der vermaledeite "Zwangscontroller" schuld"
"Und überhaupt ... eingekaufter billiger China-Crap"
"Mit 4 x so teurem Ruckus wäre das nicht passiert"
So, jetzt wieder zurück zum Problem
DHCP kanns nicht sein oder?
Die Frage ist hier: Wer macht den DHCP? Gibt es Überschneidungen mit Reservierungen? Was für ein Netz hat das VLAN?
@Looser27
warum soll es eine Rolle spielen, ob der Controller auf Windows oder Linux läuft?
Eigentlich wird der Controller nur für das Einrichten und Aktualisieren der WLAN-APs benötigt, so man kein Gast-WLAN mit Voucher nutzt.
Eventuell sind es irgenwelche Controller-Einstellungen oder zu viele Clients auf einem AP.
@conquestador
passiert das nur auf ios bzw. Androiden oder hast du das Verhalten auf einem Notebook mit Windows auch?
warum soll es eine Rolle spielen, ob der Controller auf Windows oder Linux läuft?
Eigentlich wird der Controller nur für das Einrichten und Aktualisieren der WLAN-APs benötigt, so man kein Gast-WLAN mit Voucher nutzt.
Eventuell sind es irgenwelche Controller-Einstellungen oder zu viele Clients auf einem AP.
@conquestador
passiert das nur auf ios bzw. Androiden oder hast du das Verhalten auf einem Notebook mit Windows auch?
@goscho
Hatte früher nen Windows-Controller....stürzte ständig ab.....dann auf Ubuntu gewechselt. Problem behoben.
Der Controller wird eben nicht nur fürs Einrichten gebraucht. VLAN-Steuerung der APs, CP, etc.
Hatte früher nen Windows-Controller....stürzte ständig ab.....dann auf Ubuntu gewechselt. Problem behoben.
Der Controller wird eben nicht nur fürs Einrichten gebraucht. VLAN-Steuerung der APs, CP, etc.
Hallo,
woran machst du denn fest, dass es an den APs oder dem Kontroller liegt?
Vielleicht liegt es ja an den Handys!?
Grüße Ralf
woran machst du denn fest, dass es an den APs oder dem Kontroller liegt?
Vielleicht liegt es ja an den Handys!?
Grüße Ralf
Ok, dann versuche ich das mal zusammenzufassend zu beantworten und zu kommentieren.
Ich habe insgesamt 4 WLANs, die ausgestrahlt werden.
1. internes LAN (kein VLAN) 16er Netz
2. Gäste-WLAN (VLAN inklusive Voucher) 24er Netz
3. Eingeschränktes WLAN für die Werkstatt (VLAN) 24er Netz
4. uneingeschränktes WLAN für Handys & Co. (VLAN) 24er Netz
DHCP macht intern ein DHCP-Server, Die VLANs macht die Firewall (Sophos, keine Reservierungen, somit keine Überschneidungen)
Am Standort hängen insgesamt aktuell rund 30 Clients im WLAN (verteilt auf die unterschiedlichen Netze)
Pro AP sind das nicht mehr als durchschnittlich 5 aber auch mal bis 10 Clients.
Das Problem habe ich auf Android gleichermassen wie auf iOS. MeinLaptop hängt im Internen Netz (WLAN) da habe ich das noch nicht beobachtet. Es ist aber auch schwierig, das gegenzutesten. Die Netze sind ja nicht grundlos getrennt.
Warum der Controller unbedingt auf Linux laufen soll, erschließt sich mir auch noch nicht, er läuft auf dem Server stabil ohne Abstürze. Das ist aber vielleicht eher ein Nebenkriegsschauplatz.
Ich habe insgesamt 4 WLANs, die ausgestrahlt werden.
1. internes LAN (kein VLAN) 16er Netz
2. Gäste-WLAN (VLAN inklusive Voucher) 24er Netz
3. Eingeschränktes WLAN für die Werkstatt (VLAN) 24er Netz
4. uneingeschränktes WLAN für Handys & Co. (VLAN) 24er Netz
DHCP macht intern ein DHCP-Server, Die VLANs macht die Firewall (Sophos, keine Reservierungen, somit keine Überschneidungen)
Am Standort hängen insgesamt aktuell rund 30 Clients im WLAN (verteilt auf die unterschiedlichen Netze)
Pro AP sind das nicht mehr als durchschnittlich 5 aber auch mal bis 10 Clients.
Das Problem habe ich auf Android gleichermassen wie auf iOS. MeinLaptop hängt im Internen Netz (WLAN) da habe ich das noch nicht beobachtet. Es ist aber auch schwierig, das gegenzutesten. Die Netze sind ja nicht grundlos getrennt.
Warum der Controller unbedingt auf Linux laufen soll, erschließt sich mir auch noch nicht, er läuft auf dem Server stabil ohne Abstürze. Das ist aber vielleicht eher ein Nebenkriegsschauplatz.
Hi,
deaktiviere zum Test mal das 5Ghz Netz und lass es auf 2.4Ghz only laufen.
Grüße
P.S.: Wo der Controller läuft ist völlig egal.
deaktiviere zum Test mal das 5Ghz Netz und lass es auf 2.4Ghz only laufen.
Grüße
P.S.: Wo der Controller läuft ist völlig egal.
deaktiviere zum Test mal das 5Ghz Netz und lass es auf 2.4Ghz only laufen.
Das ist nicht (mehr) so trivial ... das muss über die Gruppen gemacht werden
Ich muss ja etwas schmunzeln wegen des 16er-Netzes und glaube auch eher, dass es sich um ein Netzwerk-Design-Fehler handelt. Mich würde ja mal interessieren ob diese "verlorenen" Clients irgendwas intern pingen können und wenn ja, extern auch, usw.
Also einfach ein wenig mehr als "Clients gehen fest" ... das scheint mir kein feststehender Begriff in der Netzwerk-Welt zu sein
@Visucius
da kann ich dich beruhigen, da kann keiner nach intern pingen. Was ist für dich so ungewöhnlich an einem 16er Netz für intern und kleineren (24er) für die VLANs? Was lässt dich darauf schließen, dass es an der Netzwerk-Konfiguration liegt?
da kann ich dich beruhigen, da kann keiner nach intern pingen. Was ist für dich so ungewöhnlich an einem 16er Netz für intern und kleineren (24er) für die VLANs? Was lässt dich darauf schließen, dass es an der Netzwerk-Konfiguration liegt?
da kann keiner nach intern pingen.
Nicht "nach" intern! Du behauptest, die Clients hängen noch im Wifi. Dann wäre doch interessant, ob sie wenigstens den vLAN-internen DHCP oder das Gateway pingen können?! Ist das nicht der erste logische Schritt, nach "Clients gehen fest"? Du willst ja wissen, "wo es endet"?!Was ist für dich so ungewöhnlich an einem 16er Netz
Entweder Du hast wirklich so viele Clients im Netz, dann dürfte das Broadcasting ein beträchtliches Grundrauschen im Netzwerk produzieren oder Du hast sie nicht, dann ist die 16er Maske (in meinen Augen) etwas lächerlich. Und wenn ich höre: "Werkstatt", die Anzahl der Wifi-Clients usw. dann glaube ich nicht, dass Du 65.000 Hosts erwarten musst?!Aber jeder wie er fluffig ist. Ich "schmunzle" ja auch nur und bin mit Sicherheit
Natürlich hast du Recht, wenn du sagst, das Netz ist größer, als ich brauche. Man könnte auch hergehen und mit Subnet-Masken von 27dreiviertel und ähnlichem arbeiten (ich hoffe, du verstehst den Spaß) um ja keine IP zuviel zu haben. Man kann aber auch ganz entspannt hergehen und in einem 16er Netz verschiedene Bereiche definieren (natürlich nur in der Schreibweise), womit sich dann Clients, Server, Drucker und anderes einfach trennen lässt ohne getrennt zu sein.
Bezüglich des Ping auf das Gateway, bisher konnte ich das nicht prüfen, weil alle immer erst aus/ein schalten und sich dann erst beschweren. Hier geb ich gern zu, da hätte ich vorher schon mal reagieren können. Aber auch dafür ist dieses Forum da, um an das offensichtlichste erinnert zu werden.
Bezüglich des Ping auf das Gateway, bisher konnte ich das nicht prüfen, weil alle immer erst aus/ein schalten und sich dann erst beschweren. Hier geb ich gern zu, da hätte ich vorher schon mal reagieren können. Aber auch dafür ist dieses Forum da, um an das offensichtlichste erinnert zu werden.
Man kann aber auch ganz entspannt hergehen und in einem 16er Netz verschiedene Bereiche definieren (natürlich nur in der Schreibweise), womit sich dann Clients, Server, Drucker und anderes einfach trennen lässt ohne getrennt zu sein.
Ich frage jetzt mal nicht, warum da nicht jeder schon drauf gekommen ist?! Aber ich lerne ja auch immer wieder gerne hinzu! ...
In meinen Augen ist das so nen Ding, wie der Unifi-Controller auf Windows: Kann man bestimmt alles irgendwie machen – is halt nur doof, wenn der Kram dann nicht zuverlässig läuft 😉
(ich hoffe, du verstehst den Spaß)
PS: Spaß beiseite. Haste mal geschaut, wo die Verbindung der Clients "endet"?! Wir wollen ja "konstruktiv" vorankommen und nicht gegenseitig "rumfrotzeln" ...
PPS: Wir könnten natürlich einfach mal @aqui hinzuziehen. Nach einer "Schimpfkanonade" über Unifi legt er erfahrungsgemäß recht zielsicher den Finger in die Wunde 😉
Das ist doch so nen Java-Gefrickel. Könntest Du nicht einfach mit HyperV nen Linux-Basis hernehmen?!
Ach, und was läuft auf dem Linux Server? Ich erinnere mich noch genau, als der Unifi Controller auf Ubuntu nicht mehr funktionieren wollte, als Ubuntu der Meinung war einfach mal so sein Java upzudaten 
Seit dem wird Java vom Update ausgeschlossen.
Und, nein, das ist nicht der Grund für seinen beschriebenen Fehler ;)
Hast du IPv6 im Netz und deine Problem-Clients sind hauptsächlich Smartphones oder Tablets?
Da gibt es ein inhärentes Problem mit IPv6-NDP, was nach einer gewissen Zeit nicht funktioniert, wenn die WLAN-Clients in den Energiesparmodus wechseln - z.B., wenn das Display für 1-2 Minuten ausgeschaltet wird.
Bestimmte Clients (speziell WLAN-Chips von Qualcomm) senden dann bei Broadcast-Traffic gelegentlich spezielle Frames, die durch den AP ins restliche Netzwerk durchschlagen und dort interessante Fehler mit IGMPv3 / MLD verursachen.
Workaround bisher bei mir war:
Da gibt es ein inhärentes Problem mit IPv6-NDP, was nach einer gewissen Zeit nicht funktioniert, wenn die WLAN-Clients in den Energiesparmodus wechseln - z.B., wenn das Display für 1-2 Minuten ausgeschaltet wird.
Bestimmte Clients (speziell WLAN-Chips von Qualcomm) senden dann bei Broadcast-Traffic gelegentlich spezielle Frames, die durch den AP ins restliche Netzwerk durchschlagen und dort interessante Fehler mit IGMPv3 / MLD verursachen.
Workaround bisher bei mir war:
- Bei Ubiquiti einstellen: IGMPv3 ausschalten, GTK-Rekeying auf einen Wert zwischen 480 und 599 Sekunden konfigurieren (letzteres sorgt dafür, dass die Qualcomm-Chips weiterhin ICMPv6 verarbeiten, weil sie nie in den ganz tiefen Tiefschlaf fallen können und dadurch ein Firmware-Bug bei denen umgangen wird)
- Bei den Switches einstellen: IGMPv3 ausschalten, Flow-Control deaktivieren. Das sorgt dafür, dass die Switches nicht mehr auf PAUSE-Frames reagieren, die von manchen Intel-Chips im Tiefschlaf-Modus versendet werden und interessante Multicast-Probleme auf manchen Switches verursachen.
@ Visucius
Hab jemanden gewinnen können, der mit seinem Handy pingt, wenn nix mehr geht, Ergebnis: Standardgateway pingt nicht.
Weitere Tests sind in Arbeit, ist aber immer schwierig, Ihr kennt das ja, Fehlermeldungen werden weggeklickt und dann erst der Support angerufen...
Das 5G hab ich jetzt auch erst mal testweise deaktiviert.
@ LordGurke
GTK steht ja per Stardard auf 3600, hab das auf deine Empfehlung mal auf 500 gesetzt. IGMPv3 ist per Standart nicht angehakt, somit auch bei mir nicht aktiv.
Aber ja, wie schon oben gesagt, sind es bisher nur Äpfel und Androiden, die sich beschweren.
Mir ist da gerade noch was aufgefallen:
Auf dem Dashboard bekomme ich als unregelmässigkeiten folgende Fehler angezeigt:
DHCP und DNS macht die Sophos
Hab jemanden gewinnen können, der mit seinem Handy pingt, wenn nix mehr geht, Ergebnis: Standardgateway pingt nicht.
Weitere Tests sind in Arbeit, ist aber immer schwierig, Ihr kennt das ja, Fehlermeldungen werden weggeklickt und dann erst der Support angerufen...
Das 5G hab ich jetzt auch erst mal testweise deaktiviert.
@ LordGurke
GTK steht ja per Stardard auf 3600, hab das auf deine Empfehlung mal auf 500 gesetzt. IGMPv3 ist per Standart nicht angehakt, somit auch bei mir nicht aktiv.
Aber ja, wie schon oben gesagt, sind es bisher nur Äpfel und Androiden, die sich beschweren.
Mir ist da gerade noch was aufgefallen:
Auf dem Dashboard bekomme ich als unregelmässigkeiten folgende Fehler angezeigt:
- Endgerät xx:xx:xx:xx:xx:xx hat Probleme, einen Domainnamen in eine IP-Adresse aufzulösen (DNS Timeout).
- Hohe TCP Latenz bei Endgerät xxx
DHCP und DNS macht die Sophos
