On Wed, 2012-01-11 at 15:12 -0800, Andy Grover wrote: > Hi all, > > Dax discovered an issue with portals bound to 0.0.0.0 (INADDR_ANY), and > we've been working together to address it. > > When a portal is bound to INADDR_ANY, we return 0.0.0.0 for > TargetAddress in the response to iscsi SendTargets cmd. Should we > instead be returning the IP that the request came in on, or perhaps emit > TargetAddress for each active interface? > > Thanks -- Regards -- Andy > > PS I was initially tempted to just not return TargetAddress (it's > optional) since we don't support redir, but it's needed for MC/S as well.. > PPS any tips on how to get the needed info from the struct iscsi_cmd > passed to iscsit_build_sendtargets_response? So the sanitized string output is saved into iscsi_conn->login_ip from initial lookup via ->getname() in __iscsi_target_login_thread().. However, as you mentioned this would still be an issue with MC/S where a client would have to perform explicit discovery to each IP address that could be used in a multiple connection session with in-band discovery. I'm tempted to say that solving this in the kernel is the wrong approach, and that we should depend upon higher level userspace code to explictly create network portals via normal configfs means for us to simulate INADDR_ANY operation based on the configured interfaces.. I'm leaning this way because I'm not aware of an expected method to walk configured IP addresses to achieve what would be required here for a purely kernel-level solution.. Perhaps DaveM (Cc'ed) has some input here..? --nab -- To unsubscribe from this list: send the line "unsubscribe target-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
