Neue Version der Firmware für SHC V2 - 1.2.44.498

  • Ach ist ja blöd… Ja, NTP… Heißt dann aber, dass der Weg von Manuel schon rein logisch der nachvollziehbarere Weg ist, da ja offensichtlich die Zentrale bei einem NTP-Error einfach im Loop hängen bleibt. So klingt es zumindest, wenn ich deine Worte so lese. Fazit: Zentrale braucht zwingend Inet zum NTP-Server-Abgleich. Also doch das Blacklisting…. Wenn NTP in der Tat das Problem war, dann sollte das Experiment mit Blacklisting ergebnisreicher ausfallen.


    Auf jeden Fall möchte ich ein dickes Danke sagen für die ganzen Bemühungen hier. Tolle wäre es auch im Sinne vieler User, wenn zu dieser Problematik LIVISI ein paar Statements hinterlassen könnte - Danke im Voraus an den Support :thumbup:

  • Ist das dann jetzt die letzte finale Version Software, bevor die letzten Livisi-Mitarbeiter Türen zu sperren und die Lichter ausschalten?

    Oder wird am 29.02. nochmal was ausgerollt?


    Solong

    B

    Naja, am 29.2. werden wohl nur noch die Container aus den Büros gerollt… lasst uns froh und dankbar sein für das ganze Projekt LSH, die hätten ja auch alles einfach einstampfen können…

  • Ist das dann jetzt die letzte finale Version Software, bevor die letzten Livisi-Mitarbeiter Türen zu sperren und die Lichter ausschalten?

    Oder wird am 29.02. nochmal was ausgerollt?


    Solong

    B

    Nun, es kann ja nicht die finale Version der Firmware sein, wenn die Zentrale aktuell noch nicht im lokalen Modus alleine funktioniert, ohne dass sie mit dem Web verbunden ist

  • Nun, es kann ja nicht die finale Version der Firmware sein, wenn die Zentrale aktuell noch nicht im lokalen Modus alleine funktioniert, ohne dass sie mit dem Web verbunden ist

    Die Zentrale wird nie komplett ohne Internet funktionieren das hat Livisi aber von Anfang an gesagt... Weshalb es ja auch immer fummelig war die konkrete Abschaltung zu probieren (erst im Beta und später/jetzt hier)...


    🤷🏼‍♀️

  • Nun, es kann ja nicht die finale Version der Firmware sein, wenn die Zentrale aktuell noch nicht im lokalen Modus alleine funktioniert, ohne dass sie mit dem Web verbunden ist

    Naja, wie Manuel schon sagte, ohne Inet wirds wohl nie gehen - allein schon der NTP-Problematik geschuldet (wie ja gestern erst hier eruiert wurde), denn eine eigene RTC hat ja die Zentrale nicht. Das, was sie bis evtl. noch von den Livisi-Servern bezieht, muss sie halt künftig über irgendeinen NTP-Server beziehen. Ist ja auch soweit okay und damit kann ich zu 100000% leben, wenn der ganze andere Kram wie angedacht funzt. Cool wäre natürlich noch, wenn man in der Zentrale den NTP-Server selbst definieren und ihn somit auch ins eigene Netz legen könnte. Aber selbst spätestens dann hängt die Zentrale im normalen Heimnetz ja auch nur am Inet, insofern ists ja schon beinahe wieder Wurscht, woher die Zentrale den aktuellen Zeit-Datensatz herbekommt. Für die Frage "Können Zentralen denn nun wie erhofft einfach geclont werden?" ist diese Erkenntnis auch keine Lösung, hier kommt dann wohl doch das Blacklisting als Spielwiese Nr.1 in Frage.


    Es bleibt spannend und auch dezent aufreibend hier und da ;)

  • Cool wäre natürlich noch, wenn man in der Zentrale den NTP-Server selbst definieren und ihn somit auch ins eigene Netz legen könnte.

    das kannst du über Umwege wohl tun, wenn du im eigenen Netz dem NTP einen der Namen gibst:


    Falls die Zentrale keinen Internetzugang haben sollte, sucht die Zentrale im lokalen Netzwerk nach NTP Servern. Hierfür werden die gängigen IP-Adressen von verbreiteten Routern verwendet.



  • Danke!

    Ich habe die Settings genauso nun zum x-ten Mal reingesemmelt - nun gehts *confused*

    kann ja nur Zahlendreher PW o.ä. gewesen sein, die Basis hat sich ja nicht verändert...

    Danke nochmals :) :thumbup:

  • ... so mit Port 587 (STARTTLS) klappt es auch mit dem t-online Zugang. Leider ist diese Art der Verschlüsselung (Verbindunssicherheit) ja schon lange als potentiell unsicher klassifiziert und sollte wenn möglich nicht mehr benutzt werden. SSL/TLS (Port 465) scheint dann ja aber hier nicht zu funktionieren.

  • ... so mit Port 587 (STARTTLS) klappt es auch mit dem t-online Zugang. Leider ist diese Art der Verschlüsselung (Verbindunssicherheit) ja schon lange als potentiell unsicher klassifiziert und sollte wenn möglich nicht mehr benutzt werden. SSL/TLS (Port 465) scheint dann ja aber hier nicht zu funktionieren.

    Kann es sein, dass Du da einen Dreher hast in deiner Denke? Ist nach beigefügtem Artikel genau anders herum. 587 ist der sichere SMTP Port. siehe hierzu

    https://www.cloudflare.com/de-de/learning/email-security/smtp-port-25-587/

  • ... SSL/TLS (Standardport 465) ist die wirklich sichere Variante. Siehe auch hier.

    Der in dem Beitrag verglichene Port 25 ist ja ganz ohne Verschlüsselung.

    Ich spreche nicht über Port 25 sondern 587. In dem von Dir gesendetem Link spricht man ebenfalls von "Aufrüstung" zu Starttls Port 587.

    "…..an. Heute verwenden die meisten Nutzer implizites SSL/TLS mit Port 465 und rüsten ihre Verbindung mit STARTTLS über Port 587 auf.…."


    Oder bin ich jetzt so daneben?

  • Habe jetzt auch bei mir versucht Email einzurichten via Strato (smtp.strato,de) User & PW, port 587. Bekomme aber beim Testen immer die Fehlermeldung Error: Error in message body (kommt auch bei Port 25) - Port 465 kommt „Timeout“…. Konnte nirgends etwas zu dieser spezifischen Fehlermeldung finden. Habe mal PW falsch eingetragen und dann kommt eine entsprechende Meldung (Bad login or password)… hat irgendjemand eine hilfreichen Lösungsvorschlag oder zumindestens gleiches Problem ?

    Vielen Dank im voraus

Jetzt mitmachen!

Du hast noch kein Benutzerkonto auf unserer Seite? Registriere dich kostenlos und nimm an unserer Community teil!