iscsi: TargetAddress in SendTargets when bound to INADDR_ANY

Quoted 10 lines · Andy Grover

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?

Quoted 6 lines

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..?

Quoted 33 lines · Nicholas A. Bellinger

Quoted 10 lines · Andy Grover

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?

Quoted 6 lines

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..

Quoted 1 line

Perhaps DaveM (Cc'ed) has some input here..?

Hi Nick,

[+CC linux-scsi]

I thought about this a little over the weekend and I think the best thing to do might be this:

for portal in tpg.portals
if portal.ip == INADDR_ANY
emit TargetAddress <incoming connection IP & port>
else
emit TargetAddress portal.ip & port

This lets us use INADDR_ANY and not fake it from userland for the non-MC/S case, the common case. MC/S still works, you just can't wildcard your IP, but rather explicitly state IPs, and then they will be returned properly.