4

I'm trying to set an encryption key on an LTO-4 drive under Linux. I successfully did this once, power cycled the drive, and now I cannot get the drive to accept the key again.

The command I am using is this:

$ stenc -f /dev/nst0 -a 1 -e on -k test.key
Provided key length is 256 bits.
Key checksum is 7a43.
Turning on encryption on device '/dev/nst0'...
Sense Code:              Illegal Request (0x05)
 ASC:                    0x26
 ASCQ:                   0x00
 Additional data:        0x00000000000000000000000000000000
Error: Turning encryption on for '/dev/nst0' failed!
Usage: stenc --version | -g <length> -k <file> [-kd <description>] | -f <device> [--detail] [-e <on/mixed/rawread/off> [-k <file>] [-kd <description>] [-a <index>] [--protect | --unprotect] [--ckod] ]
Type 'man stenc' for more information.

The drive is HP so I need to use -a 1 however different values don't change the result. Using /dev/sg1 instead has the same issue.

The tape is LTO-4 so encryption is supported:

$ mt-st -f /dev/nst0 status
SCSI 2 tape drive:
File number=0, block number=0, partition=0.
Tape block size 0 bytes. Density code 0x46 (LTO-4).
Soft error count since last status=0
General status bits on (41010000):
 BOT ONLINE IM_REP_EN

I ran the HP Tape & Library Tools and did an encryption test with this same tape and it passed, so the drive seems to be able to have keys set, just not via the stenc program for some reason.

I found a SCSI manual that said ASC 0x26 is "Invalid field in parameter list" which doesn't really explain much.

Has anyone else seen this error before or have any ideas how to get the drive to accept the key?

6

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);
| improve this answer | |
  • I have added on line 176 the status=NULL; but..doesn't work – elbarna Oct 11 '17 at 14:57
  • @elbarna: What do you mean by "doesn't work"? It still crashes, or it doesn't let you set the keys? – Malvineous Oct 12 '17 at 3:18
  • Give me this message stenc -f /dev/nst0 -e on -k /etc/tape.key -a 1 --ckod Provided key length is 256 bits. Key checksum is ffffe7a6. Turning on encryption on device '/dev/nst0'... Sense Code: Illegal Request (0x05) ASC: 0x26 ASCQ: 0x00 Additional data: 0x00000000000000000000000000000000 Error: Turning encryption on for '/dev/nst0' failed! Usage: stenc --version | -g <length> -k <file> [-kd <description>] | -f <device> [--detail] [-e <on/mixed/rawread/off> [-k <file>] [-kd <description>] [-a <index>] [--protect | ... – elbarna Oct 12 '17 at 12:28
  • Have you tried disabling encryption (setting a blank key) first, power cycling the drive, and using different -a values? – Malvineous Oct 13 '17 at 5:59
  • I will try now,first 0 then 1 – elbarna Oct 13 '17 at 16:20
3

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;
| improve this answer | |
  • Welcome to the site. I found your answer to be a bit hard to read with the original formatting, so I have tried to improve it. I think the code snippet could use a bit more work, I'll let you decide about that. It's been 7 years since I developed SCSI code myself, so I can't say whether this answer is correct or not. – kasperd Jan 9 '18 at 22:06
2

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!

| improve this answer | |
  • Did you try again with TESTKEY after getting it to work without a key descriptor? Or with different text instead? – Malvineous Mar 22 '18 at 8:17
  • 1
    After the upload succeeded I did try to generate a new key with a key descriptor, and it failed to upload again. I didn't try different values of the key descriptor, I was already quite happy that it worked without one. – dazjorz Mar 23 '18 at 9:48
1

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

| improve this answer | |
  • 1
    You should grab all the firmware files while you can, HP made theirs secret and now few people have copies of them which is a huge pain for anyone using second-hand drives. – Malvineous Mar 11 at 0:56
  • 1
    Yikes that sucks for the kind of light home use that I'm using LTO for, good thing I've got all the IBM tape firmwares safely backed up (to tape, aptly). Real shame they would lock down the used market for these fantastic devices – Luke F Mar 11 at 10:28

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.