2

I have an issue with iSCSI discovery. Just some background, I'm using Openstack Cinder and part of Cinder requires the use of iSCSI for networked drives. Cinder is unable to get the list of nodes anymore for some reason, and after tracing, it seems to be due to the inability of my Openstack controller to get the list of nodes via iscsiadm.

The command I'm referring to is iscsiadm --mode discovery --op update --type sendtargets --portal <target_address>:3260

I'll get the following error message

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

Interestingly enough, this command runs fine when running on the host directly. It cannot run from any other network-ed server, whether Linux or Windows.

Now if I create a new portal via the following command tgtadm --lld iscsi --op new --mode portal --param portal=0.0.0.0:1234

I'm able to get the list of nodes just fine via the command iscsiadm --mode discovery --op update --type sendtargets --portal <target_address>:1234

So it rules out a network issue, at least.

For the record, nothing else is running on port 3260 aside form iscsid and tgtd, both of which are related to iSCSI. When I create a portal on port 1234, I get similar outputs when I netstat -nltp | grep <port_number>

I'm running Ubuntu 20.04 LTS Server Edition. The firewall is disabled, iptables are empty aside from the rule to allow incoming packets at port 3260, SELinux is also disabled.

Elf
  • 41
  • 4
  • i may be blind, but what is acutally the business related question or issue exactly? is the target ip a public ip? If not, why do you hide it? – djdomi Aug 17 '22 at 15:33
  • It's a private IP, but anyway the question is, I am unable to get the list of nodes via iSCSI discovery and am wondering if I'm missing a consideration. For some reason, discovery via port 3260 is not working, whereas discovery via other ports seem to work fine, once I create a new portal – Elf Aug 17 '22 at 15:57
  • tr, a NC ip 3260 on the target not that it's been blocked – djdomi Aug 18 '22 at 16:45
  • @dgdomi NC -L 3260 on the target -> Currently in use (tgtd active); NC -L 3260 on the target when tgtd is disabled-> Seems to be listening, no response; Initiator sends a discovery message, the login message appears; NC -L 1234 on the target when tgtd is diabled -> Same log in message as above appears ; NC -zv 3260 - get message [tcp/iscsi-target] succeeded; – Elf Aug 19 '22 at 03:04
  • @dgdomi Thanks! I've solved my problem by rolling back an automatic kernel update. – Elf Aug 19 '22 at 07:48

1 Answers1

2

The issue that I had was due to a kernel update that broke something at the lower level.

Wireshark dumps of the working connection via 1234, and 3260 showed that the 3-way TCP handshake mentioned here https://elatov.github.io/2012/06/iscsi-login-packet-capture/ was not established when communicating via 3260.

Downgrading the Linux Kernel to 5.15.0-41-generic from 5.15.0-46-generic resulted in the issue being solved.

For reference, I'm using a SuperMicro File Server Model SSG-6049P-E1CR24H

Elf
  • 41
  • 4