[stgt] Strange sendtargets behaviour

[Chris Webb]

FUJITA Tomonori <fujita.tomonori at lab.ntt.co.jp> writes:

> Ok, I hacked up a patch to support multiple PDUs in SendTarget
> session. Can you try this with the default
> discovery.sendtargets.iscsi.MaxRecvDataSegmentLength?

Hi. Many thanks for this. I'll deploy it to a test VM and try it now.

> BTW, if getnameinfo or getsockname fails, you still see a corrupted
> response. Better to handle those errors but if getnameinfo or
> getsockname fails, there is something wrong with your environment,
> isn't it?

Ah, no, what was going on here is that iscsiadm was trying to look up a
random string which it parsed as a port number in the sendtargets data (and
which should have been but wasn't an integer) in /etc/services. Later the
data being returned became so corrupt that iscsiadm couldn't parse it all
and just ignored most of the lines. Multiple initiators saw the same random
data, and the problem went away on restarting tgtd, so I'm reasonably
confident the problem lay somewhere in the target.

Unfortunately, I couldn't get more debugging info from open-iscsi about what
it was actually seeing at the time, but if I see the behaviour again, I'll
try to get a detailed dump of the sendtargets data it sees over the wire.

Best wishes,

Chris.
--
To unsubscribe from this list: send the line "unsubscribe stgt" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html