根本原因是CHAP认证仅在iSCSI login阶段触发，而discovery走无需认证的SendTargets流程；login超时多因CHAP凭据不匹配、initiatorname未授权或mutual CHAP反向凭证缺失导致target静默丢包。
为什么 discovery 成功但 login 超时
根本原因是 CHAP 认证在 iSCSI login 阶段才触发，而 discovery（即 iscsiadm -m discovery）走的是不带认证的 SendTargets 流程。即使 target 配置了 auth_type = CHAP 或 mutual_chap = Yes，discovery 仍能成功——它只看网络可达性和 target 是否响应 SendTargets 请求，完全绕过用户/密码校验。
login 超时（常见表现为 iscsiadm -m node -l 卡住 60 秒后报 connection timed out 或 session login timeout）往往不是网络问题，而是 CHAP 凭据不匹配、initiator 名称未被 target 显式授权、或 mutual CHAP 的反向凭证缺失导致 target 主动丢弃连接请求。
CHAP 用户名和 initiatorname 必须与 target 端严格一致
target（如 tgt、lio、scst）通常按 initiatorname + username 组合做 ACL 授权。哪怕只差一个空格或大小写，login 就会静默失败并最终超时。
-
/etc/iscsi/initiatorname.iscsi中的InitiatorName值必须和 target 配置里白名单中的 initiator 名完全一致（例如iqn.1993-08.org.debian:01:abcd1234） - CHAP username（
iscsiadm -m node -o update -n node.session.auth.username -v "alice"）必须与 target 端为该 initiator 配置的username字段一模一样 - mutual CHAP 的
username_in（即 target 用来验证 initiator 的用户名）也必须匹配，且 target 必须明确启用mutual_chap并填入对应密码
target 端配置中 auth_type 和 mutual_chap 的开关逻辑
以 Linux 内核 LIO（targetcli）为例：auth_type 控制是否启用单向 CHAP；mutual_chap 是独立开关，仅当设为 Yes 且 auth_type = CHAP 时才启用双向认证。二者不是“或”关系，而是嵌套依赖。
-
auth_type = None：即使设置了 username/password，login 也不会触发 CHAP，但若 target 强制要求认证，login 会被拒绝（非超时） -
auth_type = CHAP+mutual_chap = No：仅 target 验证 initiator，initiator 不验证 target -
auth_type = CHAP+mutual_chap = Yes：双方互相验证，此时 initiator 必须设置node.session.auth.username_in和node.session.auth.password_in，且 target 端需配置userid_in和password_in
错误配置如 mutual_chap = Yes 但 initiator 没配 username_in，会导致 target 等待 initiator 发起 mutual 验证，超时断连。
debug login 过程的三个关键命令
不要只看 iscsiadm -m node -l 的返回码。超时类问题必须抓底层交互：
- 开启 debug 日志：
iscsiadm -m node -T（先缩短超时便于测试）-p --op=update -n node.session.timeo.login_timeout -v 15 - 查看实时日志：
sudo dmesg -w | grep -i "iscsi\|chap"，重点关注chap response mismatch或rejecting login - 抓包确认流程：
sudo tcpdump -i any -s 0 port 3260 -w iscsi-login.pcap，用 Wireshark 打开后过滤iscsi.opcode == 0x03（Login Request），检查其中的Username、Password、AuthMethod字段是否符合预期
CHAP 密码不会明文出现在包里，但 AuthMethod 和 Challenge/Response 的长度、是否含 mutual flag 可直接判断握手阶段卡在哪一步。
