WLAN langsam

[Rüdiger Kupper]

Zugang über WLAN (Mobiledevices, Gastnetzwerk) funktioniert, aber mit sehr langen Ladezeiten. Das WLAN Kepler-Gymnasium scheint(?) flüssig zu funktionieren.

Stationäre Rechner funktionieren wie gewohnt.

[Stephan Richter]

Das Problem war, zumindest bei mir, nach dem Wechsel auf den AP in der Physik in der 5. Stunde dann weg. (Zufall, oder liegt es am AP?).

Heute Nachmittag dann wollten sich die Tablets in den Koffern im U3 kein OS Update ziehen. Auch hier war das MobileDevices WLAN auf Modemgeschwindigkeit.
2 Minuten später hatte der Herr Venter im Lehrerzimmer aber performantes Netz.

[bau]

Das ist mal wieder so ein unglaublich schwer zu untersuchendes Problem.
Hat jemand eine Idee, wie man das Monitoren könnte?

[Stephan Richter]

Ja, in der Tat.

Man bräuchte möglichst viele Infos im check_mk, am besten von allen APs und möglichst vielen Rechnern im Netz, die regelmäßig ihre Bandbreite oder zumindest den Ping reporten.

Kann es evtl.einfach der DNS sein, der manchmal sehr lange braucht? Da hätte ich aber auch keine gut Idee für eine Metrik.

[bau]

Ich habe checkMK noch umgestellt auf SNMP v2.
Der grast jetzt alles Mögliche von den APs ab.

[Stephan Richter]

Gerade ebne (ca. 11:20 Uhr 28.10.2021) war im LZ Minutenlang kein bzw. extrem langsamer WLAN-Empfang.

Ich habe versucht parallel auf den Unifi-Controller zu schauen, aber auch der Zugriff darauf war sehr langsam. Diese "WLAN-Experience" war auf 89% - vergleichsweise niedrig, aber immer noch sehr euphemistisch. Ansonsten sah das ganze normal aus.

Das check_mk Display bei Rüdigers Platz zeigt nur einen "General Error". Hängt der PC dort auch im WLAN? In jedem Fall scheint auch der kein Netz zu haben.

[bau]

Zugriff im Raum 1.09 dauerhaft mit zwei iPads vollkommen unproblematisch über MobileDevices in einer Videokonferenz.

[bau]

der Check-MK-Server hat leider seine Platte vollgemüllt und hängt.

[bau]

Check-MK Rott-Platte auf 20G vergrößert (Ich liebe ProxMox / LXC) :-)

[vent]

Gestern auch zur 5. und 6. Stunde in 5.31 (gab es vorher noch nie) ein sehr schlechte Performance gehabt im Wlan-Netz. Das Laden von WebUntis hat sehr lange gedauert, ebenso wie jeder weitere Schritt.

[shul]

Auch am Fretiag (29.10.21) in der 1.-2. Stunde U1 Raum 5.06 (mit 15 iPads) war das Wlan super schwach. Die iPad hatten fast über die gesamte Doppelstunde nur super langsames Internet, sodass teilweise nicht mal Sogo oder ähnliches geladen wurde.

[bau]

Ich werde jetzt mal die Supervisor-Engine von ciscoHeizung ersetzen und dabei gleich die beiden 10GE-TX-SFP+-Module auswechseln und gleich noch eine redundante 10GE-Leitung zur Heizung einrichten.

Der ProxMoxLS hat auch noch den 8GE-Trunk, den ersetze ich auch noch durch eine 10GE-FX-Karte zum ciscoServerraum.
Auch der ProxMoxPaedml hat das gleiche Setting.

Umzug der beiden nun unnötigen cisco0027 und ciscoKHWRS auf den ciscoServerraum steht auch noch aus.
Mal sehen, ob die Verringerung der Switchebenen was bringt.

[Rüdiger Kupper]

Sehr gut!
Switche reduzieren ist sicher immer eine gute Idee.

[bau]

cisco0027 ist nun nur noch mit 6x GBic zur Verbindung zur TGS eingesetzt, das muss ich als nächstes auf eine 1x 10GE umstellen - dazu ist ein anderer Switch im TGS-Heizungskeller nötig.

[bau]

Grusel: Sowohl auf proxmoxLS als auch auf proxmoxLS2 war ein Tippfehler in der Interfacekonfiguration des VLAN-Trunk-Interfaces: es war eine falsche, zudem unnötige Broadcast-Adresse angegeben.

Habe das behoben - eventuell war das das Unerreichbarkeitsproblem?

[Stephan Richter]

Heute haben sich wieder zahlreiche Kollegen über nicht nutzbares Netz beklagt, insbesondere bei den Koffergeräten.

Ich habe gerade versucht einen der Koffer im U3 auf iPadOS 15.1 zu updaten. (Das ging bisher immer problemlos, sogar remote über JAMF.)

• von den 20 Geräten hatten 16 keine Onlineverbindung, entsprechend schlug die Suche nach Software-Updates fehl (WLAN Verbindung sah normal aus)
• ich konnte die Geräte nicht über JAMF remote Neustarten
• ich habe dann jedes Gerät per Hand neugestartet --> alle hatten anschließend Netz und haben klaglos das Update gestartet

--> Irgendetwas scheint beim Neustart das Problem zu lösen. Ideen:

• ein Problem mit dem DHCP-lease?
• die Gateway hat sich in der Zwischenzeit geändert?
• der AP ignoriert die Geräte aus irgend einem Grund, wenn sie zu lange im Netz hängen?

Meine Vermutung ist, dass es irgendwo ein Routing-Problem gibt, das nach einem Neustart (neuer Lease) verschwindet (für wie lange?).

[bau]

• Frage: Machen die iPads auch so was tolles wie: alle Nase lang denke ich mir eine neue MAC aus?
• Bei fixer MAC könnten wir den iPads fixe IP geben und deren lease-Dauer auf maximal stellen

[Stephan Richter]

Nein, die "private MAC-Adresse" ist im WLAN-Profil der iPADs deaktiviert.

Ich denke aber nicht, dass hier das Grundproblem liegt. Bis vor 3 Wochen hat das ganze ja über Monate hinweg problemlos funktioniert. (und das Betraf jetzt Geräte, die noch auf einer alten ipadOS Version liefen - es war ja der Grund, warum sie sich nicht aktualisieren konnten.)

[Stephan Richter]

Nachdem wir jetzt fast alle Tablets manuell geupdatet haben, ergibt sich folgendes Muster:

• nach einem Update+Neustart haben die Geräte zwar WLAN-Verbindung, aber kein Netz (das kann natürlich auch an den Geräten liegen...unklar)
• Das lässt sich beheben durch EINE der folgenden Schritte
  • erneuter Neustart
  • Aus- und Anschalten des WLANs
  • Wechsel des Geräts zu einem anderen AP

Ich werde noch testen, ob das gleiche auch nach Ablauf des Lease (12h ?) passiert, ohne OS-Update.

[Stephan Richter]

Nach Tests gestern und in der Mathe-Nacht:

• ein Testgerät (ipadOS 15.1) hatte am Donnerstag im U3-Stützpunkt problemlos Netz. Freitag Mittag nicht mehr.
• Neustart der WLAN-Verbindung hat kurzzeitig Besserung gebracht, aber dann ist plötzlich die gesamte WLAN-Verbindung abgebrochen, nicht nur die Route ins Internet.
• Daraufhin habe ich den AP in U3 ausgeschaltet --> Das Gerät hatte instantan WLAN und sehr performantes Netz. (mit 2 von 3 WLAN-Balken)
• Den AP wieder angeschaltet --> 3 von 3 WLAN Balken und weiterhin sehr schneller Seitenaufbau.
• Heute morgen (also nach ca. 16 Stunden hatte das Gerät weiterhin eine sehr gute Verbindung

Auch wenn in den Releasenotes von ipadOS 15.1 etwas von Behebung von WLAN-Verbindungsproblemen steht, gehe ich eigentlich davon aus, dass das ein Unifi-Problem ist:

• zwei APs treten sich gegenseitig auf die Füße?
• der AP ignoriert Pakete von manchen Geräten nach einer gewissen Zeit, die Geräte sind aber weiterhin sauber mit dem WLAN verbunden?

@bau: Sobald du den Tablets feste IPs gegeben hast, kannst du mir bitte die zugehörige Liste schicken!? Dann würde ich mal auf paedml eine Screen-Session aufsetzen, die regelmäßig alle Tablets anpingt.

Ansonsten habe ich noch folgendes gefunden, was ich bei Gelegenheit ausprobieren würde:
​https://www.reddit.com/r/Ubiquiti/comments/qeoeox/frequent_disconnects_from_apple_devices/
​https://blog.grimreapers.de/index.php/2018/07/10/probleme-mit-ubiquiti-unifi-und-apple-ios-geraeten/

[bau]

OK - DANKE für das ausführliche Testen!
Wir hatten ja schonmal angedacht, alle AP zyklisch neu zu starten. Das könnte ja in der Nacht passieren.
Da gibt es auch eine Bericht:
​https://community.ui.com/questions/Scripting-a-reboot/d8725536-1e93-4bde-b847-c87dc4b89dce
der Ähnliches berichtet. Und die Lösung mit der API gleich noch dazu.

[bau]

OK - Script auf unifi.kg-fds.de erstellt und in die crontab eingetragen: Jeden Sonntag um 0:00 Uhr werden alle AP einmal neu gebootet.

Script ist grade durchgelaufen - ich sehe in der Weboberfläche alle AP nacheinander rot und wieder grün werden.

Mal sehen, wie sich das auf die Clients auswirkt.

[Stephan Richter]

Das gleiche Problem bestand bei mir heute in der 2. Pause und nach der 6. Stunde. Nach einem Neustart des AP_LZ war es wieder behoben.
(Im U1 war in 5./6. wohl auch kein Arbeiten mit dem WLAN möglich - siehe Lehrer-Channel).

Ruben hat in den letzten Tagen ähnliches beobachtet beim Versuch seinen Unterricht zu streamen. Die Verbindung ist wohl immer wieder ausgefallen.

a) Wir sollten doch mal schauen, ob wir das Grundproblem finden.
b) Einmal pro Woche neustarten reicht anscheinend nicht.

[bau]

Habe den reboot nun auf täglich 00:00 Uhr gesetzt

[lehm]

Workaround scheint zu funkionieren.