我在 iSCSI 发现方面遇到了问题。先介绍一下背景，我使用的是 Openstack Cinder，Cinder 的一部分要求使用 iSCSI 连接网络驱动器。由于某种原因，Cinder 无法再获取节点列表，经过跟踪，这似乎是由于我的 Openstack 控制器无法通过 iscsiadm 获取节点列表。
我指的命令是
iscsiadm --mode discovery --op update --type sendtargets --portal <target_address>:3260
我会收到以下错误消息
iscsiadm: connecting to <target_address>:3260
iscsiadm: connected local port 58654 to <target_address>:3260
iscsiadm: connected to discovery address <target_address>
iscsiadm: discovery session to <target_address>:3260 starting iSCSI login
iscsiadm: sending login PDU with current stage 1, next stage 3, transit 0x80, isid 0x00023d000000 exp_statsn 0
iscsiadm: Connection to Discovery Address <target_address> failed
iscsiadm: Login I/O error, failed to receive a PDU
有趣的是，这个命令在主机上直接运行时运行良好。它无法从任何其他联网服务器（无论是 Linux 还是 Windows）运行。
现在，如果我通过以下命令创建一个新的门户
tgtadm --lld iscsi --op new --mode portal --param portal=0.0.0.0:1234
我可以通过命令获取节点列表
iscsiadm --mode discovery --op update --type sendtargets --portal <target_address>:1234
因此至少可以排除网络问题。
需要说明的是，除了 iscsid 和 tgtd（两者都与 iSCSI 相关）之外，端口 3260 上没有其他程序在运行。当我在端口 1234 上创建门户时，我得到了类似的输出，当我netstat -nltp | grep <port_number>
我正在运行 Ubuntu 20.04 LTS 服务器版。防火墙已禁用，除了允许端口 3260 传入数据包的规则外，iptables 为空，SELinux 也已禁用。
答案1
我遇到的问题是由于内核更新破坏了较低级别的某些内容。
通过 1234 和 3260 进行的工作连接的 Wireshark 转储表明，此处提到的三次 TCP 握手https://elatov.github.io/2012/06/iscsi-login-packet-capture/通过 3260 进行通信时未建立。
将 Linux 内核从 5.15.0-46-generic 降级到 5.15.0-41-generic 可解决该问题。
作为参考，我使用的是 SuperMicro 文件服务器型号 SSG-6049P-E1CR24H