Stellen wir uns mal ala Feuerzangenbowle ganz dumm:
Da ist ein Entwickler und der verdrahtet die 254 im letzten Oktett fest in seiner App. Schwupps: Problem!
Es ist nunmal Menschenwerk und da …
Hi Michael,
klingt komisch, da es ja nur einige wenige Geräte betroffen haben müsste, nämlich genau die, die eine x.0 oder y.255 bekommen haben. Bei uns waren das gefühlt deutlich mehr.
was genau habt Ihr gemacht/geändert?
Danke und viele Grüße,
Jochen
Hi Jochen – ja, klingt auch komisch und wie gesagt: ob das überhaupt „physikalisch“ möglich ist, müssen andere beurteilen.
Ich habe mir das in etwa so zusammengereimt: Ein Gerät erhält eine .255 am Ende und feuert auf seiner Adresse … für die anderen sieht das (fälschlich) wie ein Broadcast aus und sie reagieren ständig darauf?!? Dadurch wird das gesamte Netzwerk sehr langsam?!? Ist sowas denkbar?
Was wir geändert haben ist relativ einfach: In der OPNSense kann man im Bereich für den DHCP-Dienst verschiedene „zusätzliche Pools“ angeben. Wir haben also mehrere Ranges definiert und sie immer nur von .1 bis .254 laufen lassen. So werden also die Adressen mit der .0 und .255 gar nicht mehr vergeben.
Viele Grüße,
Michael
Hallo Michael,
danke Dir, I’ll try.
Viele Grüße,
Jochen
Ja, erzähl mal, ob es danach auch bei Euch besser wird.
(Vielleicht sollte ich noch dazu sagen, dass bei uns der Unifi-Controller das WLAN nur als „VLAN only“ kennt. )
Michael:
Wie habt ihr denn eure DHCP-Ranges bzw. euer per dhcp zu vergebener IP-Bereich definiert, von 0 bis 255 oder von 1 bis 249?
Wenn von 0 bis 255 wäre aus meiner Sicht das der Fehler.
VG Andreas
Nein, wir hatten ursprünglich (wie schon oben geschrieben) den Bereich von 172.16.1.1 bis 172.16.10.254, damit wir viel mehr als 254 Adressen zur Verfügung haben, wenn eigene Geräte mitgebracht werden usw usw.
Daher ja auch eine /16er Netzmaske.
Bei dieser Vorgehensweise hat man aber trotzdem die IP-Adressen
172.16.1.255
172.16.2.255
172.16.3.255
usw bis hin zu
172.16.9.255, die vom OPNSense-DHCPd an die Geräte verteilt werden.
Also unter’m Strich sind das 9 Geräte mit einer IP-Adresse, die in einem /24er Netz Stress machen würden!
Nein eher nicht. Wenn die Betriebssystem-Programmierer nicht geschlafen haben, dann haben sie die Standards (RFC) ordentlich implementiert und das Gerät verwendet IPs und Netzmasken wie im Standard vorgesehen, d.h. .0 und .255 sind nur in einem /24 für Netzadresse und Broadcast reserviert und für alle anderen Netzmasken ist es nur die erste .0-Adresse und die letzte .255-Adresse oder korrespondierende IP größer 0/kleiner 255.
Hi. Das Schüler-WLAN läuft jetzt viel stabiler und schneller als zuvor … aber:
Wo wir hier schon den Blick in die Glaskugel werfen … der Controller meldet für unterschiedliche APs weiterhin öfter mal, dies:
Sucht man danach im UniFi-Forum, wird man fast erschlagen von gleichen Anfragen – es scheint ja ein gängiges Problem zu sein!?
Ich habe mich daraufhin nochmal auf einem solchen AP per ssh angemeldet und mit tail -f /var/log/messages beobachtet, was da los ist.
Eine der Meldungen lautet:
user.err libubnt[3481]: mcad[3481]: ace_reporter_trsp_curl.check_multi_info(): inform failed with curl code 52
– und zwar genau zu dem Zeitpunkt, wenn der Accesspoint als „Disconnected“ gemeldet wird. Tipp man allerdings info in der Konsole ein, steht dort bei uns immer :
Status: Connected
Es kann also durchaus ein Fehlalarm sein?!
Ist das bei Dir auch so, @jochen ?
Viele Grüße,
Michael
Hallo Michael,
ich denke ja, da gefühlt auch alles funktioniert hat, obwohl APs in den Notifications des Controllers als offline gemeldet wurden, es gab aber keine Beschwerden. Genau kann ich es jedoch nicht sagen, da ich mich nie zeitgleich auf einen der angeblich betroffenen APs verbunden habe. Werde ich versuchen, wenn es wieder dazu kommt.
Spannend: wir haben ja noch 1 Woche Ferien und dadurch keine Anmeldungen von Geräten oder Traffic. In den Controller-Logs tauchen aktuell auch keinerlei Meldungen von angeblichen offline APs auf! Bin mal gespannt, ob sich das wieder ändert, wenn die Schule wieder losgeht und werde berichten.
Viele Grüße,
Jochen
Hallo zusammen,
ich habe den Controller mittlerweile auf 7.2.92 und die APs auf 6.2.35 upgedatet. Keine Fehlermeldungen wg. offline APs ABER: das iPad-Problem besteht nach wie vor.
Bei uns macht übrigens nicht die OPNsense, sondern der LMN-Server DHCP für das betroffene WLAN.
Irgendeine Erkenntnis auf Eurer Seite?
Danke und Gruß,
Jochen
Hi Jochen,
wenn du das „Legacy-Interface“ am Controller aktivierst (also die „alte“ Ansicht) und dort bei den Einstellungen zu „Drahtlos-Netzwerke“ gehst ist da bei deinem betroffenen W-Lan „Sperrung von LAN zu WLAN Multicast- und Broadcastverkehr“ aktiviert oder nicht? Ich hatte vergleichbare Probleme wie du und ich meine das deaktivieren dieser Option hat Besserung gebracht.
Liebe Grüße Frank
Hi Frank,
war aktiviert und habe ich deaktiviert. Aber nach wie vor die gleichen Probleme…
Viele Grüße,
Jochen
Hi.
Obwohl unsere APs weiterhin regelmäßig „getrennt“ anzeigen und kurze Zeit später wieder da sind, glaube ich nicht, dass sie dann wirklich physikalisch vom Netz getrennt wurden, denn wenn ich per ssh auf einem AP mit uptime nachsehe, stehen dort viele hundert Tage uptime.
Ich hätte aber trotzdem gerne eine Möglichkeit, wie man eine Dauer-Online-Verbindung prüfen kann. Ein einfaches ping kann ich zwar 24/7 laufen lassen aber das zeigt mir ja nicht, ob und wann die Verbindung ggf weg war. Daher suche ich ein anderes Tool, mit dem man das über einen Tag überwachen kann. Dann weiß man zumindest, ob die Accesspoints die ganze Zeit ihren Dienst tun und müsste vermutlich im Management-VLAN oder auf dem Controller den Fehler weitersuchen.
Es gibt auf den APs unter /usr/bin ein paar mitgelieferte Standardtools … aber etwas passendes für diesen Fall habe ich noch nicht gefunden.
Viele Grüße,
Michael
Hier kommt ein weiteres kleines Puzzelstück … die Accesspoints sind NICHT offline, auch wenn der Controller zwischendurch den Eindruck hat, dass sie es sind 
Ich habe seit gestern einen der Accesspoints, die häufiger als „getrennt“ gemeldet wurden mit SmokePing beobachten lassen. Hier das Ergebnis:
Der AP war durchgängig erreichbar…
wir hatten bei neuen aps unfi6pro POE-probleme mit nem 24er relativ neuen aruba switch, und das bei nur 4 angeschlossenen Aps.
kann man auch mal probieren ob es hilft, die mal anders mit strom zu versorgen.
„Michael Hagedorn via linuxmuster.net“ noreply@linuxmuster.net 16.09.22 8.30 Uhr >>>
| Michael
16. September |
- | - |
Hier kommt ein weiteres kleines Puzzelstück … die Accesspoints sind NICHT offline, auch wenn der Controller zwischendurch den Eindruck hat, dass sie es sind
Ich habe seit gestern einen der Accesspoints, die häufiger als „getrennt“ gemeldet wurden mit SmokePing beobachten lassen. Hier das Ergebnis:
Der AP war durchgängig erreichbar…
Hallo zusammen,
wir haben unser iPad-Problem gelöst! 
War bei uns kein iPad- oder Unifi-, sondern ein Proxy-Problem: einigen iPads wurde ein anderer IP-Range zugewiesen, um sie von den restlichen Geräten trennen und unterscheiden zu können (wg. Druckberechtigungen etc). Das wurde jedoch nicht in den noProxy-Gruppen auf der Firewall nachgezogen…
Wie so oft also Layer8…
Vielen Dank fürs Mithirnen und viel Erfolg weiterhin bei der Lösung der anderen, hier beschriebenen Probleme!
Viele Grüße,
Jochen
Hi.
Wir haben auch eins der Probleme gelöst: Ein AP wurde ja dauernd als „getrennt“ und nur mit 100MBit angezeigt. Er wurde dann mehrfach über einen Tag verteilt wieder eingebunden – inkl. Error-Log. Der Tipp mit der Spannungsversorgung war offenbar goldrichtig. Wir haben diesen AP vom PoE-Switch zurück auf einen „richtigen“ Injektor gesteckt und seitdem ist dieses Problem behoben!
Seitdem ich alle anderen Accesspoints in die „Überwachung“ von SmokePing aufgenommen habe, wird auch bei diesen APs das nervige „getrennt“ nicht mehr gezeigt. Es kann also durchaus sein, dass das ein ganz simples „zu wenig Spannung vom Cisco-Switch“-Problem war!??
Viele Grüße,
Michael
Hi Ihr,
ich habe heute mal die iPads wieder alle durchgesehen, ob jedes noch i.O. ist. Dabei ist mir aufgefallen, dass alle Pads neuerdings behaupten, das WLAN sei „verborgen“ obwohl dem nicht so ist. Habt ihr das auch? Funktionieren tut noch alles…
LG
Max
Hallo zusammen,
es gibt es FW-Update für die Unifi-APs: Release Notes
Vor allem dies hier könnte u.U. eines der hier von @Michael beschriebenen Probleme lösen:
[UAP] Fix devices occasionally going offline in the Network Application.
Viele Grüße,
Jochen