Gruß an alle
Ich habe hier einen WLC30 mit 6 AP, die daran angebunden sind. Einer verabschiedete sich von heute auf morgen und will nicht mehr mit dem WLC reden. Im Syslog steht nun DTLS connection failed: Bad certificate, peer (adresse WLC), state ClientRcvCertificate .. Alle andern funktionieren, es ist nur diese eine AP (ein L321AGN mit einer 10.72.0092SU2 Firmware) . Datum/Uhrzeit stimmen und es wurde auch an sich nichts daran geändert. Auf einemal stand er halt bei fehlende AP.
Irgendjemand eine Idee
Seltsamer Fehler Verbindungerbindung AP auf WLC
Moderator: Lancom-Systems Moderatoren
Re: Seltsamer Fehler Verbindungerbindung AP auf WLC
check mal ob Datum und Zeit auf WLC und dem betreffenden AP gleich sind.
Viele Grüße
ts
Viele Grüße
ts
TakeControl: Config Backup für LANCOM Router, WLC, APs, Firewalls und Switche...
https://www.linkedin.com/posts/activity ... 04032-DNQ5
https://www.nmedv.de
https://www.linkedin.com/posts/activity ... 04032-DNQ5
https://www.nmedv.de
Re: Seltsamer Fehler Verbindungerbindung AP auf WLC
Habe ich das passt .. das ist ja so sein Standardfehler ... ich habe jetzt mal mit Setup - Zertifikate - SCEP-Client - Aktualisieren das Zertifikat neu ausstellen lassen .. und schau an es funktioniert wieder .... sollte er das nicht von alleine machen ?
Re: Seltsamer Fehler Verbindungerbindung AP auf WLC
Sollte er das alleine machen-> ja natürlichw.blecker hat geschrieben: 07 Mär 2023, 12:06 Habe ich das passt .. das ist ja so sein Standardfehler ... ich habe jetzt mal mit Setup - Zertifikate - SCEP-Client - Aktualisieren das Zertifikat neu ausstellen lassen .. und schau an es funktioniert wieder .... sollte er das nicht von alleine machen ?
hat Lancom es so implementiert, das dass passiert -> leider nein.
Ein AP, der sich mit dem WLC verbindet, bekommt genau in dem Moment die Zeit syncronisiert, und zwar nur in diesem Moment.
Später passiert das nie wieder. Uns ist das in einem Projekt aufgefallen und Lancom sagte da, das man das bisher nie als Problem gesehen hat,
da die Uhlen inn den APS sehrt stabil sind. Uns war das mit LX APs aufgefallen, die sind wohl da aufgrund der Linux Basis etwas bissiger bei Zeitabweichungen und Zertifikaten.
Workarround 1: WLC per Cron nachts für 5 Minuten disablen, wenn der WLC wieder erreichbar ist, verbinden sich die APS und bekommen die Zeit des WLC gesetzt
Workarround 2 : auf allen Aps per Script deine Zeitserver eintragen, dien die APs erreichenn können.
Es gibt dazu einen Feature Request - > Regelmäßige Zeitsysynronisation der APs vom WLC über capwap (über die Vendor Erweiterung von LANCOM), dazu kenne ich den aktuellen Status nicht.
Viele Grüße
ts
TakeControl: Config Backup für LANCOM Router, WLC, APs, Firewalls und Switche...
https://www.linkedin.com/posts/activity ... 04032-DNQ5
https://www.nmedv.de
https://www.linkedin.com/posts/activity ... 04032-DNQ5
https://www.nmedv.de
Re: Seltsamer Fehler Verbindungerbindung AP auf WLC
Läuft würd ich sagen Die AP synchroneren sich aber alle schon mit unserem NTP Server .. ich muss mal schauen wie oft die das tun .. ah alle 24 h
-
- Beiträge: 1113
- Registriert: 19 Aug 2014, 22:41
Re: Seltsamer Fehler Verbindungerbindung AP auf WLC
Vorgehen, wenn der AP keine Echtzeituhr (RTC) besitzt:
https://de.wikipedia.org/wiki/Echtzeituhr
NTP-Server abschalten, dann im AP die Uhrzeit um mehrere Monate in die Vergangenheit stellen, so dass die Uhrzeit des AP ausserhalb dem Gültigkeitsrahmen des für DTLS verwendeten Maschinenzertifikats liegt. Den AP für mehrere Minuten stromlos schalten und danach starten. Es sollte die bereits bekannte DTLS-Zertifikat-Fehlermeldung wieder erscheinen. Danach den NTP-Server wieder einschalten. Und den AP per Kaltstart neustarten. DTLS-Zertifikat-Fehlermeldung sollte nicht mehr auftauchen, da sich der AP ordnungsgemäss vor dem Aufbau der verschlüsselten Kommunikation (DTLS) die aktuelle Uhrzeit vom NTP-Server holt.
Die Gültigkeitsdauer eines Maschinenzertifikats (X.509-Zertifikat) kann mit OpenSSL:
abgefragt werden.
Linuxrechner (und somit auch AP's LANCOM LX) verwenden in der Regel für den Zeitdienst Chrony.
https://chrony.tuxfamily.org/
Bei fehlender Echtzeituhr (RTC) sollte Chrony mit dem Parameter "-q" beim Rechnerstart gestartet werden, bevor der reguläre Zeitserverdienst (per Systemd) gestartet wird. Mit dem Parameter "-q" versucht Chrony einmalig die Uhrzeit ab einem Zeitserver zu synchronisieren. Zum Beispiel:
/usr/sbin/chronyd -F -1 -t 15 -q 'server 192.168.1.1 iburst'
Hinter der IPv4-Adresse 192.168.1.1 versteckt sich ein LANCOM-Router mit einer batteriegepufferten Echtzeituhr (RTC).
Bei fehlender Echtzeituhr (RTC) sollte Chrony (per Systemd-Dienst) mit dem Parameter "-s" für den regulären Zeitserverdienst gestartet werden, damit Chrony beim Rechnerstart die Uhrzeit des Linuxrechners auf den Zeitstempel der Drift-Datei setzt, falls die vorgängige Zeitsynchronisation mit Parameter "-q" fehlschlug. Mit Parameter "-s" startet Chrony (mindestens) mit der Uhrzeit des letzten Schreibvorgangs auf die Drift-Datei. Danach sollte Chrony versuchen, die Uhrzeit mit einem Zeitserver (hier: NTP-Server) zu synchronisieren.
https://chrony.tuxfamily.org/doc/4.3/chronyd.html
Die von Chrony zu verwendende Drift-Datei wird mit dem Konfigurationsparameter "driftfile" in der Chrony-Konfigurationsdatei chrony.conf konfiguriert.
https://chrony.tuxfamily.org/doc/3.4/chrony.conf.html
https://de.wikipedia.org/wiki/Echtzeituhr
NTP-Server abschalten, dann im AP die Uhrzeit um mehrere Monate in die Vergangenheit stellen, so dass die Uhrzeit des AP ausserhalb dem Gültigkeitsrahmen des für DTLS verwendeten Maschinenzertifikats liegt. Den AP für mehrere Minuten stromlos schalten und danach starten. Es sollte die bereits bekannte DTLS-Zertifikat-Fehlermeldung wieder erscheinen. Danach den NTP-Server wieder einschalten. Und den AP per Kaltstart neustarten. DTLS-Zertifikat-Fehlermeldung sollte nicht mehr auftauchen, da sich der AP ordnungsgemäss vor dem Aufbau der verschlüsselten Kommunikation (DTLS) die aktuelle Uhrzeit vom NTP-Server holt.
Die Gültigkeitsdauer eines Maschinenzertifikats (X.509-Zertifikat) kann mit OpenSSL:
Code: Alles auswählen
# openssl x509 -dates -noout -in <Pfad zum Maschinenzertifikat>
Code: Alles auswählen
notBefore=Dec 30 18:54:30 2019 GMT
notAfter=Jan 21 18:54:30 2030 GMT
https://chrony.tuxfamily.org/
Bei fehlender Echtzeituhr (RTC) sollte Chrony mit dem Parameter "-q" beim Rechnerstart gestartet werden, bevor der reguläre Zeitserverdienst (per Systemd) gestartet wird. Mit dem Parameter "-q" versucht Chrony einmalig die Uhrzeit ab einem Zeitserver zu synchronisieren. Zum Beispiel:
/usr/sbin/chronyd -F -1 -t 15 -q 'server 192.168.1.1 iburst'
Hinter der IPv4-Adresse 192.168.1.1 versteckt sich ein LANCOM-Router mit einer batteriegepufferten Echtzeituhr (RTC).
Bei fehlender Echtzeituhr (RTC) sollte Chrony (per Systemd-Dienst) mit dem Parameter "-s" für den regulären Zeitserverdienst gestartet werden, damit Chrony beim Rechnerstart die Uhrzeit des Linuxrechners auf den Zeitstempel der Drift-Datei setzt, falls die vorgängige Zeitsynchronisation mit Parameter "-q" fehlschlug. Mit Parameter "-s" startet Chrony (mindestens) mit der Uhrzeit des letzten Schreibvorgangs auf die Drift-Datei. Danach sollte Chrony versuchen, die Uhrzeit mit einem Zeitserver (hier: NTP-Server) zu synchronisieren.
https://chrony.tuxfamily.org/doc/4.3/chronyd.html
Die von Chrony zu verwendende Drift-Datei wird mit dem Konfigurationsparameter "driftfile" in der Chrony-Konfigurationsdatei chrony.conf konfiguriert.
https://chrony.tuxfamily.org/doc/3.4/chrony.conf.html