HM-Sensorsterben (SC und SCO) nach update auf FW 3.61.5

[Slice]

Ja, ich weiß, aber bekanntlich stirbt die Hoffnung zuletzt.

[blackhole]

... die Entwickler sind dabei die Sache zu analysieren und zu beheben.

Was beheben die Entwickler denn?

Wenn man die Erkenntnisse von jp112sdl zusammenfasst und kombiniert, ist es doch wohl so, dass ein Fehler, der unter anderem in der Geräte-Firmware 1.0 von HM-Sec-SCo schon immer vorhanden war, entweder durch einen Zufall oder einen Workaround in Dual-Copro-Firmware 4.2.14 in der aktuellen Ausprägung bis vor 5 Monaten nie aufgetreten ist.

Bekanntermaßen sind ja erst mit dem Realease von Dual-Copro-Firmware 4.4.12 vor etwa 5 Monaten, als Bestandteil von der CCU3-Firmware 3.61.5, 3.61.6, 3.61.7 und 3.63.8, die hier diskutierten Probleme aufgetreten.

Das wiederum kann ja nur bedeuten, dass der Teil der in Dual-Copro-Firmware 4.2.14, der bis vor etwa 5 Monaten den Fehler der Geräte-Firmware von HM-Sec-SC und HM-Sec-SCo die letzen Jahre erfolgreich kaschiert hat, in Dual-Copro-Firmware 4.4.12 verändert oder entfernt wurde.

Das heißt aber nicht, dass Dual-Copro-Firmware 4.4.12 per se fehlerhaft ist, da andere HM-Geräte eben nicht von dem Fehler betroffen sind. Das bedeute aber schon, dass es für eine Ursachenbehebung nun (seit Jahren, spätestens aber seit 5 Monaten) an der Zeit ist, den Fehler in der Firmware von HM-Sec-SC und HM-Sec-SCo zu beheben.

An dieser Stelle sind wir an dem Punkt, an dem jp112sdl das alte "Forenwissen" bzgl. der OTA-Updatefähigkeit von HM-Sec-SC und HM-Sec-SCo auf den Kopf gestellt hat. Technisch spricht ja anscheinend nichts dagegen, dass der ursächliche Fehler in Form eines Geräte-Firmwareupdates für HM-Sec-SC und HM-Sec-SCo behoben wird. Nach meinem Verständnis wäre damit dann tatsächlich die Ursache des Problems behoben.

Um auf meine Frage zurückzukommen: Was beheben die Entwickler?

[Xel66]

Das heißt aber nicht, dass Dual-Copro-Firmware 4.4.12 per se fehlerhaft ist, da andere HM-Geräte eben nicht von dem Fehler betroffen sind.
...
Um auf meine Frage zurückzukommen: Was beheben die Entwickler?

Was sie versuchten zu beheben, entzieht sich als Anwender natürlich meiner Kenntnis. Aber gemäß meiner Beobachtungen und auch anderer Anwenderberichte stellen auch andere "verschlüsselt" kommunizierende Geräte ihre Tätigkeiten ein, wenn der Fehler initial von den SCo ausgelöst wurde. Nur provozieren sie den Fehler wie die SCo (noch) nicht. Heißt für mich als externen Beobachter, dass das Problem größer ist und die Problemlösung komplexer, als nur das Verhalten der SCo oder der CoPro-Firmware auf den Fehler anzupassen, damit es nicht zu den Auswirkungen kommt. Diesen Fehler kann man auf zwei Arten angehen. Man macht einen Workaround und stellt die vorherige Verhalten (Tolerierung) wieder her, oder man hat die eigentliche Ursache gefunden und möchte sie beseitigen, um nicht zukünftig wieder in das gleiche Problem zu laufen (wenn es z.B. tatsächlich nur ein Timing-Problem ist, was das tolerierte Fehlverhalten vom Problemauslöser unterscheidet).

Es ist davon auszugehen, dass die Funkmodulfirmware den Counter vorher nicht korrekt behandelt bzw. die eigenmächtige Veränderung durch die SCo toleriert hat (kann ja grundsätzlich vorkommen, wenn die CCU mal ein Funkpaket nicht mitbekommen hat). Somit ist es eher ein grundsätzliches Problem. Ich würde die korrekte Behandlung des Packet Counters auch als Sicherheitselement einer signierten Kommunikation im Rahmen des Spoofing- und Replay-Schutzes betrachten. Du erinnerst Dich an die Demo des CCC, die hier irgendwo auch verlinkt ist? Habe ich mit meiner Annahme Recht und stellt nun nur diese vorherige Tolerierung als Workaround wieder her, hat man dann eigentlich sein Sicherheitskonzept untergraben (oder es zumindest geschwächt). Man müsste sich mal die Counter anderer signiert kommunizierender Geräte anschauen. Wenn ich mal Zeit dafür finde... - im Moment eher schlecht.

Gruß Xel66

[stan23]

Ist es nicht so, dass andere Geräte bei wiederholten Sendeversuchen den Counter gleich lassen?

Weil einerseits die Funkmodul-FW im Fehlerfall langsam antwortet, der SCo bei der Wiederholung aber den Counter erhöht, kommt im Extremfall keine gesicherten Kommunikation zu Stande.

Auf Seiten der Funkmodul-FW muss auf jeden Fall diese Verzögerung raus, woher sie auch kommt.

Und davon unabhängig ist im SCo das Erhöhen des Counters und die Sendeschleife (anderer Bug) zu fixen.

[Xel66]

Ist es nicht so, dass andere Geräte bei wiederholten Sendeversuchen den Counter gleich lassen?

Genau das wäre das Verhalten, welches ich erwarten würde. Ich kann es derzeit nicht prüfen, weil ich viel unterwegs bin und keinen Zugriff auf den Analyzer habe. Die SCo machen es aber nachweislich anders.

Und davon unabhängig ist im SCo das Erhöhen des Counters und die Sendeschleife (anderer Bug) zu fixen.

Genau. Es sind meiner Meinung nach mindestens zwei Baustellen (Firmware von SCo und Funkmodul). Zumindest ist auch die signierte Kommunikation mit anderen Geräten in der Folge der Fehlerauslösung durch die SCo betroffen. Inwieweit andere Geräte ein ähnliches Verhalten haben, müsste man noch nachschauen. Ich kann derzeit nicht schauen. Ist aber im Grunde auch egal, denn es ist zu vermuten, dass das Problem gelöst und nicht versteckt werden soll, denn ein Workaround wäre ja schneller veröffentlicht.

Gruß Xel66

[MichaelN]

Man wartet einfach die paar Jahre bis die HM Geräte alle den Betrieb eingestellt haben.

[stan23]

Dann hätten mal lieber die RHS den Bug

[jp112sdl]

Ist es nicht so, dass andere Geräte bei wiederholten Sendeversuchen den Counter gleich lassen?

Weil einerseits die Funkmodul-FW im Fehlerfall langsam antwortet, der SCo bei der Wiederholung aber den Counter erhöht, kommt im Extremfall keine gesicherten Kommunikation zu Stande.

Auf Seiten der Funkmodul-FW muss auf jeden Fall diese Verzögerung raus, woher sie auch kommt.

Und davon unabhängig ist im SCo das Erhöhen des Counters und die Sendeschleife (anderer Bug) zu fixen.

Ja. Genau so.
60 Threadseiten zusammengfasst.
Danke

[jp112sdl]

Dann hätten mal lieber die RHS den Bug

Jup, die kann man wenigstens mit ner AskSin++ Firmware versorgen.

[chka]

musste nur schmunzeln, 5 Grad sind Fenster auf:

Der HM-TC-IT-WM-W-EU bekommt alles mit die ccu hast wieder mal verschluckt