- Mitglied seit
- 10 Mai 2006
- Beiträge
- 15,275
- Punkte für Reaktionen
- 1,751
- Punkte
- 113
Es hängt halt von der Größe der "Eingabedatei" beim (AVM-)Signieren ab. Ich habe in meinem "sign_image" die passenden Maßnahmen zur Umgehung eingebaut:
Damit sind - nach allem, was ich getestet habe - sowohl die Probleme beim Signieren behoben, als auch das "short read", was bei AVM ab und an mal auftritt. Ich habe jedenfalls danach keine "Klagen" mehr gehört, daß sich durch die Signatur irgendwelche Probleme ergeben hätten oder daß die AVM-Komponenten eine solche Signatur nicht verifizieren konnten.
Die 0,05 ergibt sich daraus, daß bei einer Anzahl von zu signierenden Blöcken, die bei der Division durch 20 einen Rest von 18 ergibt (wo also die zwei Blöcke mit dem Header und dem Inhalt für die Signatur den letzten 10 KByte-Block der Ausgabedatei komplett ausfüllen, weil die ja mit lauter Nullen in die Signatur eingehen müssen), der Platz für die zwei "end of archive"-Blöcke auch noch hinzugefügt werden muß. Weder bei 17 noch bei 19 Blöcken "am Ende" der Daten tritt dieses Problem auf - daher eben nur "in einem von 20 Fällen". Wenn jetzt 3 von 12 Dateien exakt diese Größe aufweisen, ist das eben eine Häufung dieser Fälle, aber deren Wahrscheinlichkeit wird damit nicht größer.
Ich kopiere in diesen Fällen einfach noch einmal den allerersten Block der Image-Datei (das sollte ein Header für das Verzeichnis "./var" sein (das wird zuvor überprüft) und dessen mehrmaliges Auftreten in der Datei ist schon deshalb harmlos, weil das Verzeichnis nicht mehrfach angelegt werden kann und es trotzdem keinen Fehler hervorruft, wenn so ein Header erneut auftritt) in die Ausgabe - damit ergibt sich wieder eine Größe der zu signierenden Daten, bei der die Berechnungen (zur Kontrolle) durch die AVM-Komponenten so funktionieren, wie ich das im zugehörigen IPPF-Thread beschrieben habe.
YourFritz/signimage/sign_image at ed5d2ab931da0ac33e46432eb19ce051ed3e54b6 · PeterPawn/YourFritz
dynamic package management for AVM routers. Contribute to PeterPawn/YourFritz development by creating an account on GitHub.
github.com
Damit sind - nach allem, was ich getestet habe - sowohl die Probleme beim Signieren behoben, als auch das "short read", was bei AVM ab und an mal auftritt. Ich habe jedenfalls danach keine "Klagen" mehr gehört, daß sich durch die Signatur irgendwelche Probleme ergeben hätten oder daß die AVM-Komponenten eine solche Signatur nicht verifizieren konnten.
Die 0,05 ergibt sich daraus, daß bei einer Anzahl von zu signierenden Blöcken, die bei der Division durch 20 einen Rest von 18 ergibt (wo also die zwei Blöcke mit dem Header und dem Inhalt für die Signatur den letzten 10 KByte-Block der Ausgabedatei komplett ausfüllen, weil die ja mit lauter Nullen in die Signatur eingehen müssen), der Platz für die zwei "end of archive"-Blöcke auch noch hinzugefügt werden muß. Weder bei 17 noch bei 19 Blöcken "am Ende" der Daten tritt dieses Problem auf - daher eben nur "in einem von 20 Fällen". Wenn jetzt 3 von 12 Dateien exakt diese Größe aufweisen, ist das eben eine Häufung dieser Fälle, aber deren Wahrscheinlichkeit wird damit nicht größer.
Ich kopiere in diesen Fällen einfach noch einmal den allerersten Block der Image-Datei (das sollte ein Header für das Verzeichnis "./var" sein (das wird zuvor überprüft) und dessen mehrmaliges Auftreten in der Datei ist schon deshalb harmlos, weil das Verzeichnis nicht mehrfach angelegt werden kann und es trotzdem keinen Fehler hervorruft, wenn so ein Header erneut auftritt) in die Ausgabe - damit ergibt sich wieder eine Größe der zu signierenden Daten, bei der die Berechnungen (zur Kontrolle) durch die AVM-Komponenten so funktionieren, wie ich das im zugehörigen IPPF-Thread beschrieben habe.