[PATCH 5/9] nvme/040: create an authenticated nvmeof-tcp connection

[Hannes Reinecke]

On 11/22/21 9:57 AM, Sagi Grimberg wrote:
> 
> 
> On 11/22/21 9:55 AM, Hannes Reinecke wrote:
>> Signed-off-by: Hannes Reinecke <hare at suse.de>
>> ---
>>   tests/nvme/040     | 64 ++++++++++++++++++++++++++++++++++++++++++++++
>>   tests/nvme/040.out |  6 +++++
>>   2 files changed, 70 insertions(+)
>>   create mode 100644 tests/nvme/040
>>   create mode 100644 tests/nvme/040.out
>>
>> diff --git a/tests/nvme/040 b/tests/nvme/040
>> new file mode 100644
>> index 0000000..9c2eb07
>> --- /dev/null
>> +++ b/tests/nvme/040
>> @@ -0,0 +1,64 @@
>> +#!/bin/bash
>> +# SPDX-License-Identifier: GPL-3.0+
>> +# Copyright (C) 2021 Hannes Reinecke, SUSE Labs
>> +#
>> +# Test nvme over tcp authentication
>> +
>> +. tests/nvme/rc
>> +
>> +DESCRIPTION="Create authenticated TCP connection via localhost"
>> +QUICK=1
>> +
>> +requires() {
>> +    _nvme_requires
>> +    _have_modules loop
>> +    _require_nvme_trtype_is_fabrics
>> +}
>> +
>> +
>> +test() {
>> +    local port
>> +    local genctr
>> +    local subsys="blktests-subsystem-"
>> +    local hostid="$(uuidgen)"
>> +    local hostnqn="nqn.2014-08.org.nvmexpress:uuid:${hostid}"
>> +    local scratch="/tmp/blktest-ns1.img"
>> +    local nvme_trtype="tcp"
> 
> Why is this tcp specific? what prevents this from passing with
> loop/rdma?
> 

Nothing in principle.

> AFAICT the rest of the tests are not tcp specific either, nor
> is inband auth in general...
> 
> I think we should have the tests run with a user-defind nvme_trtype.
> 

If you can tell me how to do that I'll happily make the change.

>> +    local hostkey
>> +
>> +    echo "Running ${TEST_NAME}"
>> +
>> +    hostkey="$(nvme gen-dhchap-key -n ${subsys}1 2> /dev/null)"
>> +    if [ $? -ne 0 ] ; then
>> +        echo "nvme gen-dhchap-key command missing"
>> +        return 1
>> +    fi
> 
> I think that this belongs in nvme/rc
> 
>> +
>> +    _setup_nvmet
>> +
>> +    truncate -s 512M "${scratch}"
>> +
>> +    port="$(_create_nvmet_port "${nvme_trtype}")"
>> +
>> +    _create_nvmet_subsystem "${subsys}1" "${scratch}"
>> +    _add_nvmet_subsys_to_port "${port}" "${subsys}1"
>> +    _create_nvmet_host "${subsys}1" "${hostnqn}"
>> +    _set_nvmet_hostkey "${hostnqn}" "${hostkey}"
> 
> Can you comment that hash/dhgrp are used with their default values.
> 
Sure.

>> +
>> +    nvme connect -t "${nvme_trtype}" -n "${subsys}1" \
>> +         -a "${def_traddr}" -s "${def_trsvcid}" -S "${hostkey}" \
>> +         --hostnqn="${hostnqn}" --hostid="${hostid}"
>> +
>> +    nvme list-subsys
> 
> Why not just look in the connect retcode? why do you need the
> list-subsys output?
> 
Hmm. Possibly I could; just found it more obvious the check if the
namespace shows up in the system as expected.
Reasoning being that it doesn't help if nvme returns no error, but
the namespace doesn't show up.
But I'm open to suggestions.

Cheers,

Hannes
-- 
Dr. Hannes Reinecke		        Kernel Storage Architect
hare at suse.de			               +49 911 74053 688
SUSE Software Solutions Germany GmbH, 90409 Nürnberg
GF: F. Imendörffer, HRB 36809 (AG Nürnberg)