Was kann beim Einstellen der LTO-Verschlüsselung zu einem „Erkennungsfehler“ führen?

Lösung 1:

Wie üblich bedeuten stundenlange Fehlerbehebung nichts, aber das Posten einer Frage in einem öffentlichen Forum offenbart das Problem sofort.

Es gibt einen Fehler in Stenc 1.0.7, der einen Absturz verursacht, wenn Sie --detail verwenden auf einem leeren Band. Ich habe versucht, den Autor mit einer Lösung zu kontaktieren, kann ihn aber nicht erreichen.

Es scheint, dass dieser Absturz das Laufwerk in einem inkonsistenten Zustand zurücklässt, in dem es sich weigert, weitere Schlüssel zu akzeptieren. Den Fehler beheben und dann stenc --detail ausführen ohne absturz scheint das problem behoben zu sein. Ich kann jetzt beliebige Tasten beliebig oft setzen und es gab keine weiteren Probleme.

Wenn jemand anderes das gleiche Problem hat, in stenc-1.0.7/sec/scsiencrypt.cpp in Zeile 176 steht dort delete status; . Sie müssen direkt darunter eine neue Zeile hinzufügen, die status=NULL; lautet . Dies behebt einen Double-Free-Fehler, der den Absturz verursacht hat.

--- a/src/scsiencrypt.cpp
+++ b/src/scsiencrypt.cpp
@@ -174,6 +174,7 @@ SSP_NBES* SSPGetNBES(string tapeDevice,bool retry){
            if(status->nbes.encryptionStatus!=0x01)break;
            if(moves>=MAX_TAPE_READ_BLOCKS)break;
            delete status;
+           status=NULL; //double free bug fix
            if(!moveTape(tapeDevice,1,true))break;
            moves++;
            status=SSPGetNBES(tapeDevice,false);

Lösung 2:

Beginnend mit CentOS 7.3 oder 7.4 (7.2 funktioniert) bin ich auf einen weiteren Illegal Request Error gestoßen, der zufällig erscheint, wenn ich versuche, die Verschlüsselung zu aktivieren.

Ich habe herausgefunden, dass einige Reservebits im SCSI-Befehl nicht richtig initialisiert sind. Beim Setzen von #define DEBUGSCSI man sieht, dass diese Bits bei jedem Aufruf variieren.

Fügen Sie den folgenden memset() hinzu in scsiencrypt.cpp um es zu beheben:

SCSIWriteEncryptOptions():

...

  SSP_KAD kad;

=> memset(&kad,0,sizeof(kad));

  kad.type=0x00;

Lösung 3:

Ich verbrachte einen Tag damit, zu debuggen, warum unser Quantum LTO7 HH-Laufwerk immer wieder einen Sense-Fehler ausgab, als wir die Verschlüsselung darauf mit einem vollständig gepatchten stenc konfigurierten 1.0.7, unabhängig von den beim Hochladen verwendeten Optionen.

Schließlich haben wir herausgefunden, dass es in unserem Fall daran liegt, dass wir beim Generieren des Schlüssels einen Schlüsseldeskriptor festlegen – einen Schlüssel mit stenc -g 256 -k test.key -kd TESTKEY generieren und dann mit stenc -f /dev/nst0 -e on -k test.key -a 1 hochladen würde fehlschlagen, während stenc -g 256 -k test.key dann würde das Hochladen mit demselben Befehl erfolgreich sein. Hoffe, das hilft jemandem!