Patches und VPN

[enertegus]

Hallo,
wie die Umfrage https://knx-user-forum.de/eibpc/10254-iets-und-vpn.html und Anmerkungen unser Kunden aus dem professionellem Umfeld zeigt, ist die VPN Wartung ein wichtiges Feature.

Um VPN freizuschalten, bedarf es eines neues Linux-Kernels (bzw. anders kompiliert) und einer neuen Firmware.

Ab Patch 1.100 kann dies vom Anwender selbst eingespielt werden. Bei den Patches gab es ja einige Verwirrung. Um diese zu vereinfachen, folgende Planung:

Das nächste Patch mit VPN und Kernel wird Patch 2.000 sein.

• Ab sofort sind alle volle 100er Nummern dann immer inkremental, das heisst: Wenn ich 2.300 einspielen will, brauche ich 2.000, 2.100, 2.200
• Patches mit 1000er Nummern sind vollständig. Für Patch 3.000 brauch ich also nicht alle Patches 2.100 ... 2.900
• Patches mit Zwischennummern (2.002, 2.234, 4.459) sind vollständig bis zur nächst kleineren 100er Nummer. Für 2.234 brauch ich dann also: 2.000, 2.100, 2.200 sonst nix.

Im Eibstudio wird eine Überprüfung eingebaut, die das testet und ggf. eine Fehlermeldung einbaut. Man kann dann nix falsch machen bzw. ist sich seiner Sache beim Upgrade sicher.

Um die Sache "glatt" zu ziehen, brauchen wir folgende Ausnahme:
Für Patch 2.000 benötigt man mindestens 1.100, 1.101 und 1.300.

D.h. leider für alle EiBPCs ohne 1.100 Patch, dass man für das Upgrade auf VPN (und ggf. weiteren Upgrades) den EibPC bei Enertex flashen lassen muss - EibPC Patch 1.100 - €9.80 : enertex bayern gmbh, Online-Shop. Das VPN Upgrade an sich wird kostenfreier Bestandteil in der Basis-Version.

[Bodo]

Supi

Wow Bravooo. Gute Idee mit den Patchnummern.
Und dann noch mit Überprügung. Voll cool.

[SnowMaKeR]

WOW.
Bin platt...

[MatthiasS]

Jungs, ich bin stolz auf euch

[MarkusS]

Könnt Ihr die Patches nicht differenziell machen - 2.300 beinhaltet alle Änderungen seit 2.000?

[salixer]

Könnt Ihr die Patches nicht differenziell machen - 2.300 beinhaltet alle Änderungen seit 2.000?

2.300 enthält alle Änderungen seit 2.200. Die einzelnen Patches sollen halt nicht riesig werden. So oft vorkommen wird das aber sicher nicht, nur bei größeren Änderungen.

[enertegus]

Könnt Ihr die Patches nicht differenziell machen - 2.300 beinhaltet alle Änderungen seit 2.000?

naja, wenn wir zum Beispiel in 2.000 nen Kernel ausliefern, dessen Einspielen natürlich kritischer ist (Spannungsunterbrechnung, Kind fliegt über das Stromkabel...) würde es das Risko erhöhen.

[Tessi]

2.300 enthält alle Änderungen seit 2.200. Die einzelnen Patches sollen halt nicht riesig werden. So oft vorkommen wird das aber sicher nicht, nur bei größeren Änderungen.

Wenn aber 3.000 alles seit der Urversion enthält ist das sicher 'riesiger' als wenn 2.900 alles seit 2.000 enthält

naja, wenn wir zum Beispiel in 2.000 nen Kernel ausliefern, dessen Einspielen natürlich kritischer ist (Spannungsunterbrechnung, Kind fliegt über das Stromkabel...) würde es das Risko erhöhen.

Ja und? Egal wie klein die 'Häpchen' sind, wenn im falschen Moment das Kind stolpert ist das entweder ein Problem, oder das System kann damit umgehen. Ich kann nur sagen, im Automobilsektor fällt ein Steuergerät durch, wenn es sich nach einem weshalb auch immer abgebrochenen Updateversuch nicht 'retten' läßt (indem noch einmal geflascht wird). Das wird vom Kunden so verlangt und auch getestet! Ich hätte mir jetzt gewünscht, das der EibPC da genauso robust gewesen wäre...

Zurück zu den Patches:
Warum nicht so:
Um auf 2.345 zu kommen brauch ich: 2.000, 2.300, 2.345 sonst nix.
Oder ganz systematisch:
Um auf 2.345 zu kommen brauch ich: 2.000, 2.300, 2.340 und 2.345.

Also jede 1000er Version umfasst alles seit der Urversion.
Jede 100er Version alles seit der letzten 1000er.
Jede 10er Version alles seit der letzten 100er.
(Und ggf. noch jede 1er Version umfasst alles seit der letzten 10er.)

Ich brauche also maximal 3 (oder 4) Patches um von irgendwo auf den aktuellen Level zu kommen.
OK, mit 1.100 gibt es da einen Sonderfall, aber nur deswegen sollten die 100er nicht anders als die 1000er und 10er inkrementiell sein.
Es muß ja nicht nur an dieser Stelle berücksichtigt werden, das einiges ohne das spezielle Update bei Enertex nicht geht, also fände ich ein homogenes System mit deutlichem Hinweis auf diese eine Ausnahme besser.

Sonst ist es am Ende so:
Um auf 2.999 zu kommen brauch ich: 2.000, 2.100, 2.200, 2.300, 2.400, 2.500, 2.600, 2.700, 2.800, 2.900, 2.999 - für meinen Geschmack zu viel.

Der andere Weg bliebe bei maximal 4 Patches:
Um auf 2.999 zu kommen brauch ich: 2.000, 2.900, 2.990 , 2.999 - mehr nicht.
Wobei das mit den 'Einzelschritten' ja noch entfallen könnte:
Um auf 2.999 zu kommen brauch ich dann: 2.000, 2.900, 2.999.
Nur finde ich es mit 4 Patches halt logischer.

Oder es wird eine richtig intelligente Verwaltung ins EibStudio integriert, die automatisch alle fehlenden Teile von der Homepage holt und in den EibPC läd - so wie man das heute von den Updatefunktionen vieler Programme kennt. Dann ist es dem Anwender ziemlich egal, was und wieviel alles gebraucht wird, es ist ja nur ein Komando und um den Rest muß er sich nicht mehr kümmern.
Aber mir würde schon die einfachere Lösung reichen.

[EIB-TECH]

brav

[enertegus]

Ich kann nur sagen, im Automobilsektor fällt ein Steuergerät durch, wenn es sich nach einem weshalb auch immer abgebrochenen Updateversuch nicht 'retten' läßt (indem noch einmal geflascht wird).

M.E.: Im Automobilsektor gäbe es kein Kernelupdate. Da wärs dann Ende mit der Version 1.300. Kostenlose Featureupgrades - kenn ich nicht.

Wir könnten natürlich das 2.000 Patch über unseren Shop als käufliche Version (wie den 1.100) anbieten, quasi vom Profi geflasht. Ich weiss nicht, ob ich hier eine Umfrage starten sollte ....

Alle FW-Updates und Patches (außer 1.100 und dann die 2.000 Version) sind tatäschlich auch nicht durch eine Stromunterbrechnung gefährdet.

Wenn Du den EibPC in ein Auto einbauen willst, ruf noch mal an. Dann gibts speziellen Support - über das wie unterhalten wir uns dann.

Gruss
Michael

[makki]

Trotzdem: Die Ersparniss von einer handvoll übertragenen MB interessiert im xDSL-Zeitalter wirklich keinen, nichtmal den Provider..

Es muss lüppen, fertig. Egal von welchem Patch/Firmware-Level man kommt.. Vorhandene Systeme wie apt hätten da übrigens ihre Vorteile auszuspielen, nein, das wär jetzt böse
Es sollte einfach und übersichtlich sein, Update xy=Patch/Firmware/Fix-XY. "In einem Rutsch", es interessiert den AW - zurecht - einen feuchten kehrricht, was der Unterschied zwischen Patch, FW usw. ist und ob Patch 17 zu FW 16 passt..
Und ja, das sollte IMHO drastisch vereinfacht werden..

Edit: und wo wir schon im Automobilsektor waren: es interessiert mich ja auch nicht was die Niederlassung in meinen BMW flashed, solange es am Ende des Tages einfach funktioniert und wenigstens einer der vielen Bugs behoben ist

Makki

[no sleep]

M.E.: Im Automobilsektor gäbe es kein Kernelupdate. Da wärs dann Ende mit der Version 1.300.

Sorry, aber dieses Argument ist mit einer Pinzette an den Haaren herbeigezogen.
Auch einen Kernel kann man zu jeder Zeit sicher flashen. Das hängt ausschließlich davon ab, wie man das System designt hat. Ich habe vor einigen Jahren auch mal ein embedded Device entwickelt und da gab es genau 5 Partitionen:
a) Bootloader
b) Gerätespezifische Settings
c) Kernel
d) ro Dateisystem für das BS
e) rw Dateisystem für den User

Vor allem a) sollte man sich beim Systemdesign gut überlegen. Damit kann man die Returnierungsquote zerflashter Geräte schon ganz nah Richtung "0" drücken.
Bei mir gab es auch immer ein "komplettes" Update, das die Partitionen c) und vor allem d) komplett geflasht hat. Dieses Gepatche im Dateisystem führt bei Geräten mit Flash-Speicher früher oder später nach meiner Erfahrung immer zu Problemen.

[Uwe!]

Bevor wieder alles zerredet wird: Ich find's nen sehr großen Schritt in die richtige Richtung!
Auch klar: das Bessere ist der Feind des Guten!
Aber es geht halt auch nciht immer alles auf einmal.

[salixer]

Sorry, aber dieses Argument ist mit einer Pinzette an den Haaren herbeigezogen.

Von kritischen Remote-Updates habe ich im Automobilsektor noch nicht gehört. Dann fährt man eben in die Werkstatt und bezahlt 50 € für ein Update. Das können wir natürlich auch gern so machen

Auch einen Kernel kann man zu jeder Zeit sicher flashen. Das hängt ausschließlich davon ab, wie man das System designt hat. Ich habe vor einigen Jahren auch mal ein embedded Device entwickelt und da gab es genau 5 Partitionen:
a) Bootloader
b) Gerätespezifische Settings
c) Kernel
d) ro Dateisystem für das BS
e) rw Dateisystem für den User

Sicher ist relativ. Den Kernel könnte man theoretisch redundant auslegen und wenn einer zerschossen ist könnte der Bootloader den Fallback-Kernel booten. Ich habe allerdings im Consumer-Bereich noch kein Gerät gesehen, das diesen Aufwand betreibt. Weder beim 50 € Router, noch beim 500 € Smartphone. Da hilft im Falle eines fehlgeschlagenen Updates oft nur noch der Zugriff auf den Bootloader, der für den Anwender aber eigentlich nicht vorgesehen ist.
Dass der Bootloader aktualisiert wird, kommt quasi nie vor. Und wenn der ausfällt hilft eigentlich nur noch der Programmieradapter.
Nicht umsonst steht imemr dabei: Während des Updates nicht die Stromzufuhr unterbrechen

PS: Es ist müsig darüber zu diskutieren, wann und wie oft ein Patch einen anderen, zuvor installiereten Patch benötigen wird. Das wird die Zukunft zeigen. Sicher wollen auch wir das nicht alle 3 Tage haben und neue Geräte werden sowieso mit aktuellen Versionen ausgeliefert.

[Uwe!]

Ich habe allerdings im Consumer-Bereich noch kein Gerät gesehen, das diesen Aufwand betreibt. Weder beim 50 € Router, noch beim 500 € Smartphone.

Ich kenn's vom 500€ Router (Lancom) Da gibt's einen Bootloader und zwei parallele Firmwarebversionen. Wenn nach einem Update die neue nciht hoch kommt, wird automatisch die alte geladen. Wenn die auch nicht mehr geht, kann man mit dem Bootlaoder wieder eine neue aufspielen