Soluzione 1:
Come al solito, ore di risoluzione dei problemi non significano nulla, ma postare una domanda su un forum pubblico rivela immediatamente il problema.
C'è un bug in stenc 1.0.7 che causa un crash se usi --detail su un nastro vuoto. Ho provato a contattare l'autore con una correzione ma non riesco a contattarlo.
Sembra che questo arresto anomalo lasci l'unità in uno stato incoerente, in cui si rifiuta di accettare ulteriori chiavi. Risolvere il bug e quindi eseguire stenc --detail senza crash sembra aver risolto il problema. Ora posso impostare qualsiasi chiave qualsiasi numero di volte e non ci sono stati ulteriori problemi.
Se qualcun altro ha lo stesso problema, in stenc-1.0.7/sec/scsiencrypt.cpp alla riga 176 dice delete status; . Devi aggiungere una nuova riga direttamente sotto questo che legge status=NULL; . Questo corregge un errore double-free che causa il crash.
--- 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);
Soluzione 2:
A partire da CentOS 7.3 o 7.4 (7.2 funziona) ho riscontrato un altro errore di richiesta illegale che appare in modo casuale durante il tentativo di abilitare la crittografia.
Ho capito che alcuni bit di riserva nel comando SCSI non sono inizializzati correttamente. Quando si imposta #define DEBUGSCSI si può vedere che questi bit variano a ogni chiamata.
Aggiungi il seguente memset() in scsiencrypt.cpp per risolverlo:
SCSIWriteEncryptOptions():
...
SSP_KAD kad;
=> memset(&kad,0,sizeof(kad));
kad.type=0x00;
Soluzione 3:
Ho passato una giornata a cercare il motivo per cui la nostra unità Quantum LTO7 HH continuava a dare un errore Sense quando stavamo configurando la crittografia su di essa utilizzando un stenc completamente patchato 1.0.7, indipendentemente dalle opzioni utilizzate durante il caricamento.
Alla fine, abbiamo capito che nel nostro caso è perché abbiamo impostato un descrittore chiave durante la generazione della chiave, generando una chiave usando stenc -g 256 -k test.key -kd TESTKEY e poi caricandolo usando stenc -f /dev/nst0 -e on -k test.key -a 1 fallirebbe, mentre stenc -g 256 -k test.key quindi il caricamento utilizzando lo stesso comando avrà esito positivo. Spero che questo aiuti qualcuno!