FUJITA Tomonori <fujita.tomonori@xxxxxxxxxxxxx> 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@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
