Skip to content

Conversation

@martin-gpy
Copy link
Contributor

During nvme connect-all, if a discovery log page record reports the sectype as anything other than NVMF_TCP_SECTYPE_NONE in nvmf_connect_disc_entry(), it then assumes that tls should be default set for the same. But this holds true only for configured PSK TLS connections alone and not generated PSK TLS (i.e. secure channel concat) connections since both concat and tls flags are meant to be mutually exclusive. Fix the same.

Fixes: #3034

During nvme connect-all, if a discovery log page record reports
the sectype as anything other than NVMF_TCP_SECTYPE_NONE in
nvmf_connect_disc_entry(), it then assumes that tls should be
default set for the same. But this holds true only for configured
PSK TLS connections alone and not generated PSK TLS (i.e. secure
channel concat) connections since both concat and tls flags are
meant to be mutually exclusive. Fix the same.

Signed-off-by: Martin George <marting@netapp.com>
@igaw
Copy link
Collaborator

igaw commented Jan 5, 2026

I think the nvmf_connect_disc_entry function should not blindly enable tls in this case.

Something like this here:

	if (e->trtype == NVMF_TRTYPE_TCP &&
	    e->tsas.tcp.sectype != NVMF_TCP_SECTYPE_NONE &&
	    !cfg->tls)
		c->cfg.tls = true;

If we check the command line for --concat and --tls and ensure that the user doesn't provide both options, then this here would be a good place to log what is happening. It seems relevant to report to me. What do you think?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

concat connections fail during connect-all

2 participants