VonDoczuDoc.de

Hallo in die Runde,

wir haben hier einen Kocobox die seit dem Umzug in die neuen Praxisräume es JEDE Woche nicht schafft, sich die CRL automatisch zu laden.
Netzwerkkomponenten, Firewall, Box und Internetprovider sind die selben. Manueller Download der CRL ist immer problemlos möglich.
Der Support meint nur "es liegt an der Firwall". Dass an der nichts geändert wurde und die CRL ja über unverschlüsseltes HTTP gelanden wird, ist dabei irrelevant.

Hat das noch jemand und ggf einen Lösungsvorschlag?
Wir habe folgendes getestet:
- Diverse DNS Server
- MTU Sizes
- Firewalll auf "Durchzug" nach Extern für die Box (also keinerlei Filter)

Nichts davon hat Abhilfe gebracht. Der Rest funktioniert, es ist nur diese vermaledeite Liste die nicht geladen werden kann...

Danke und Gruss
Frank

Hallo,

was zeigt die KoCoBox auf dem Display als Fehlermeldung an? Vielleicht hilft das ja und dann im AdminHandbuch nachschauen ...

MfG

- Umzug: Internetanbieter gewechselt, z.B. zu Kabel? Da könnte IPv6 reingrätschen.
- Uhrzeit in der Box korrekt?
- Protokollspeicher bereinigt, SYSLOG auf "Fehler" statt "INFO" und Speicherdauer herabgesetzt?

Danke für das Feedback

Im Display nichts relevantes was sich auch nur annähernd als Hinweis nutzen lässt.
Zeit stimmt und auch der Anschluss läuft auf nativ IP V4 (Telekom).

Seltsamerweise lässt sich die CRl jedes mal Problemlos manuell laden und einspielen. Der Hersteller meinte, "es liegt an der Firewall"... schön, aber die hat sich nicht geändert von der alten zur neuen Praxis, auch nicht der Provider. Und wenn es an der FW liegt, woran genau? Solange dieses Problem nicht gelöst ist, steht die Box in der FW auf Durchzug, da kann also keine Regel im Weg sein.

Protokollspeicher steht auch auf INFO, ja. Zeit passt auch

Hatte das Problem in einer Praxis auch.

Die KocoBox sollte ERST "offline" genommen werden (unter Verwaltung "Leistungsumfang ONLINE:" auf "nicht aktiviert" , dann die CRL & TLS Listen manuell importieren, Leistungsumfang ONLINE:" auf "aktiviert" und dann Neustarten, gfs. gleich "EC_OTHER_ERROR_STATE zurücksetzen"

unsere hatte es diese woche auch erstmalig nicht gemacht, mit manuellem Einspielen gings dann. komisch... natürlich Montag morgends...

zila hat geschrieben: ↑Dienstag 23. Januar 2024, 16:24 Hatte das Problem in einer Praxis auch.

Die KocoBox sollte ERST "offline" genommen werden (unter Verwaltung "Leistungsumfang ONLINE:" auf "nicht aktiviert" , dann die CRL & TLS Listen manuell importieren, Leistungsumfang ONLINE:" auf "aktiviert" und dann Neustarten, gfs. gleich "EC_OTHER_ERROR_STATE zurücksetzen"

Danke, das ist ja mal ein sehr konkreter Tip ! Werde ich umgehend angehen...sobald die Box wieder ein Login zulässt

Seit dem heutigen Passwortwechsel per Copy & Paste war nur EIN Login möglich, seitdem kommt man nicht mehr rein und die Karten werden nicht mehr aktiviert. Warum muss man so viel Lebenszeit mit so einem halbgaren Zeug verschwenden...

Ich richte für den Fall immer einen "Backup Root-User" an...

Alternativ kann man es über das KoCoBox Service-Tool versuchen.
Da gibt es unter Wartung eine Option "Zertifikatslisten aktualisieren"
Bei mir ist es damals aber nicht durchgelaufen

zila hat geschrieben: ↑Dienstag 23. Januar 2024, 16:24 gfs. gleich "EC_OTHER_ERROR_STATE zurücksetzen"

Da tut sich bei uns absolut NICHTS mehr. Der lässt sich partout nicht mehr zurücksetzen. Auch nicht nach Neustart.

scottsdalegirl hat geschrieben: ↑Mittwoch 24. Januar 2024, 15:30

zila hat geschrieben: ↑Dienstag 23. Januar 2024, 16:24 gfs. gleich "EC_OTHER_ERROR_STATE zurücksetzen"

Da tut sich bei uns absolut NICHTS mehr. Der lässt sich partout nicht mehr zurücksetzen. Auch nicht nach Neustart.

Hängt auch davon ab, in welchen Fehlerzustand sich die KocoBox befindet. State 1 oder State 2
Siehe Administratorhandbuch der KoCoBox MED, Kapitel ab 7.5

Grml, die 80% plus und Zustand (1) erreiche ich nach Stunden auf manchen Kocoboxen sogar (auch G3), wenn alle Protokolle im Rahmen der Möglichkeiten zurückgeschraubt sind auf 10 Tage + FATAL, kein Performancelogging läuft und die Box nach Fehlerlöschung neugestartet wurde.
Das ist nämlich so eine Sache, wenn man abends remote die Updates macht und niemand in der Praxis nach Neustart die SMC-B-PIN eingeben kann.

Warum passiert das beim Secunet nicht? Da gibt es zwar auch mal bei halbvollem Protokollspeicher den "Spaß", dass er geleert werden muss (20 Sekunden, kein Neustart), heruntergeladene Updates manuell zu löschen sind und neu heruntergeladen werden müssen, aber man erreicht zumindest noch das Ziel und kann dann neustarten bzw. den automatischen Neustart als Abschluss sehen.

Techniker war heute da und hat die Box 3x Werksresettet, nix geht. Nach seiner Aussage ist ein Zertifikat abgelaufen, woraufhin bei der Generation der Box (aus 2021) alle möglichen seltsamen Fehler auftreten, bis sie schliesslich gar nicht mehr geht. Resultat: Box als Defekt deklariert und ne neue bestellt. Frage offen, ob das nun ein Gewährleistungsfall ist...

Mei, ein Stück Hardware das durch ein abgelaufenes Zertifikat zum Ziegelstein wird... eine verdammt ausgereifte Technik.

zila hat geschrieben: ↑Mittwoch 24. Januar 2024, 09:41 Ich richte für den Fall immer einen "Backup Root-User" an...

Alternativ kann man es über das KoCoBox Service-Tool versuchen.
Da gibt es unter Wartung eine Option "Zertifikatslisten aktualisieren"
Bei mir ist es damals aber nicht durchgelaufen

Danke, das ist aber bei uns ebenfalls gescheitert. Der komplette Anmeldedienst scheint sich verabschiedet zu haben...

Ou man. Wenn ich das so lese, bin ich geneigt auf Secunet umsteigen, wenn der nächste erzwungene Hardwaretausch der KocoBox ansteht...

Also unserer hatte heute auch das Zertifikat wieder nicht geholt. Ist von 2022. Davor hatte es jetzt fast 2 Jahre ohne Probleme funktioniert... Ärgerlich da immer Montag morgen. Hat sich da vielleicht auf der Gegenseite was geändert?

Folgende Fehlermeldungen zeigt die Weboberfläche der Kocobox an:

29.01.2024 07:57:47

OPERATIONAL_STATE/EC_OTHER_ERROR_STATE(2)

OPERATION

WARNING

Bedeutung = Protokollspeicher zu mehr als 80% gefüllt. Protokoll = system:SEC, system:PERF


-------------------------------------------------------------------------------------------------------------
29.01.2024 07:57:51

OPERATIONAL_STATE/EC_LOG_OVERFLOW

OPERATION

WARNING

Bedeutung = Wenn im Rahmen der Regeln für die rollierende Speicherung von Logging-Einträgen Einträge gelöscht werden, die nicht älter als LOG_DAYS bzw. FM_<fmName>_LOG_DAYS sind, tritt der Fehlerzustand ein. Protokoll = system:SEC
_____________________________________________________________________________


29.01.2024 07:58:08

OPERATIONAL_STATE/EC_OTHER_ERROR_STATE(1)

SECURITY

FATAL

Bedeutung = In der Klasse [IOUtils], Zeile [1] der [BasisKonnektor-VM] war vor dem Reboot am [2024-01-16T00:55:00.581+01:00[CET]] ein OOME des Heap-Space aufgetreten, der einen Reboot auslöste.

___________________________________________________________________________________
29.01.2024 07:58:34

OPERATIONAL_STATE/EC_TSL_Out_Of_Date_Within_Grace_Period

SECURITY

WARNING

Bedeutung = Systemzeit t mit t > NextUpdate-Element der TSL und t <= NextUpdate-Element der TSL + CERT_TSL_DEFAULT_GRACE_PERIOD_DAYS und eine neue TSL ist nicht verfügbar NextUpdateTSL = 2024-01-27T00:00:05.000Z GracePeriodTSL = 30
____________________________________________________________________________________


bringt einen das irgendwie weiter? wie verhindere dass ich nächsten Montag das Zertifikat wieder von Hand einspielen muss?

Wir haben hier das gleiche Problem. Wenn die Kocobox diese Liste nicht regelmäßig erneuert, wird die Praxis vom TI-Netz abgekoppelt und baut die VPN-Verbindung zur TI nicht mehr auf. Stand heute ist die einzige Lösung: jeden Sonntag Abend die Liste manuell holen und importieren. Die Firewall hab ich schon mehrfach geprüft und der manuelle Download klappt ja auch. Der Aktualisierungs-Job in der Kocobox scheint einfach nicht zu laufen und unser Support ist ratlos.

*GELÖST*
Nach Freischaltung des Downloadservers per FQDN, Domänenname und IP-Adresse in der Firewall funktionierte der Download noch immer nicht und schlug reproduzierbar jede Woche fehl. Nach intensiver Suche in den Logfiles stellte sich heraus, dass das Intrusion Detection System der Firewall den Downloadversuch der CRL-Liste seitens der Kocobox geblockt hat. Grund ist, dass dieser mittels einer veralteten Java-Version erfolgt, die als unsicher eingestuft wird. Wer also eine moderne Firewall nutzt, die auch den Inhalt des Datenverkehrs analysiert, der sollte hier nach der Ursache fehlgeschlagener Downloads suchen. Gestern war also vorerst der letzte Sonntag mit manuellen CRL-Downloads und Aktualisierung der Kocobox!

Auch die Deaktivierung von PFblockerNG (der auch vorher schon aktiv war) hat sich hier leider auch nichts geändert. Bis zum heutigen Tag bin ich nicht dahinter gekommen, was das Problem ist.