-
Bug
-
Resolution: Unresolved
-
Blocker
-
rhel-10.2
-
None
-
Yes
-
Critical
-
rhel-storage-io-2
-
3
-
False
-
False
-
-
None
-
None
-
None
-
None
-
Unspecified
-
Unspecified
-
Unspecified
-
-
x86_64
-
None
What were you trying to do that didn't work?
When configuring TLS for NVMe-TCP connections, I am no longer able to connect to the namespace:
# subsysnqn=nqn.1992-08.com.netapp:sn.48c34f56b71f11ef8a10d039ea98949f:subsystem.rhel_103_ss_1_tls # keydata=NVMeTLSkey-1:01:ZGWG+gp2Wt22Qnc3Bjw2UwVndVgnwB/yTozbmsf0SBQKexut: # nvme check-tls-key -vv --identity=1 --subsysnqn=$subsysnqn --keydata=$keydata --insert --keyfile /etc/nvme/tls-keys # nvme connect -t tcp --tls -a 172.18.50.171 -n $subsysnqn could not add new controller: failed to write to nvme-fabrics device
The logs report the following at the time of the connection:
Dec 15 17:01:07 rhel-storage-103.fast.eng.rdu2.dc.redhat.com tlshd[220058]: nl_recvmsgs: Operation not permitted Dec 15 17:01:17 rhel-storage-103.fast.eng.rdu2.dc.redhat.com kernel: nvme nvme4: queue 0: TLS handshake failed, error -110
This previously worked with RHEL-10.1 and nvme-cli-2.11-3.el10. It also works with RHEL-9.8 and nvme-cli-2.13-1.el9.
What is the impact of this issue to you?
Automation failures
Please provide the package NVR for which the bug is seen:
kernel-6.12.0-172.el10.x86_64
nvme-cli-2.16-2.el10.x86_64
How reproducible is this bug?: Often
Steps to reproduce
- see above