What could cause a 'sense error' when setting LTO encryption?

Solution 1:

As usual, hours of troubleshooting mean nothing, but posting a question on a public forum immediately reveals the problem.

There's a bug in stenc 1.0.7 which causes a crash if you use --detail on a blank tape. I have tried to contact the author with a fix but can't get hold of him.

It seems that this crash leaves the drive in an inconsistent state, where it refuses to accept further keys. Fixing the bug and then running stenc --detail with no crash seems to have fixed the problem. I can now set any keys any number of times and there have been no further issues.

If anyone else is having the same problem, in stenc-1.0.7/sec/scsiencrypt.cpp at line 176 it says delete status;. You need to add a new line directly below this that reads status=NULL;. This fixes a double-free error causing the 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);

Solution 2:

Starting with CentOS 7.3 or 7.4 (7.2 works) I encountered another Illegal Request Error that appears randomly when trying to enable encryption.

I figured out that some reserve bits in the SCSI command are not properly initialized. When setting #define DEBUGSCSI one can see that these bits vary on each call.

Add the following memset() in scsiencrypt.cpp to fix it:

SCSIWriteEncryptOptions():

...

  SSP_KAD kad;

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

  kad.type=0x00;

Solution 3:

I spent a day debugging why our Quantum LTO7 HH drive kept giving a Sense error when we were configuring encryption on it using a fully patched stenc 1.0.7, regardless of the options used when uploading it.

Finally, we figured out that in our case, it's because we set a Key Descriptor when generating the key – generating a key using stenc -g 256 -k test.key -kd TESTKEY and then uploading it using stenc -f /dev/nst0 -e on -k test.key -a 1 would fail, while stenc -g 256 -k test.key then uploading using the same command would succeed. Hope this helps somebody!

Solution 4:

I solved a slightly different stenc error on an IBM SCSI LTO-4 drive by updating the firmware. It seems that the factory firmware did not support encryption at all.

My error was:

Status for /dev/nst0
--------------------------------------------------
Device Mfg:              IBM     
Product ID:              ULTRIUM-TD4     
Product Revision:        74H6
Sense Code:              Illegal Request (0x05)
 ASC:                    0x24
 ASCQ:                   0x00

The firmwares are behind a paywall on the IBM site, but you can find them on the IBM FTP server with a bit of digging (they are not public enough for me to feel I can link directly), or on the Lenovo site here: https://datacentersupport.lenovo.com/gb/en/products/storage/tape-and-backup/ts3200/6173/downloads/driver-list/component?name=Software%20and%20Utilities