iscsi-target: ST response on IN6ADDR_ANY socket
authorChris Leech <cleech@redhat.com>
Mon, 12 Aug 2013 18:26:28 +0000 (11:26 -0700)
committerNicholas Bellinger <nab@linux-iscsi.org>
Tue, 13 Aug 2013 03:31:53 +0000 (20:31 -0700)
commitdfecf611a1bb46dfe19fc5329a23ef12c1f0591d
treecbde70d4bbba8b1f259e9e5643d9c312440b65d0
parentde04a8aa6b292b9c7e559794cb50e4296b193002
iscsi-target: ST response on IN6ADDR_ANY socket

Odd little issue, found that if you create an IPv6 portal bound to the
IN6ADDR_ANY wildcard address it will accept IPv4 connections (as long as
bindv6only isn't set globally) but respond to SendTargets requests with
an IPv4-mapped IPv6 address.

Example over loopback:

 In targetcli create a wildcard IPv6 portal
   /iscsi/iqn.../portals/> create ::
 Which should create a portal [::]:3260

 Initiate SendTargets discovery to the portal using an IPv4 address
   # iscsiadm -m discovery -t st -p 127.0.0.1
 The response formats TargetAddress as [::ffff:127.0.0.1]:3260,1

This still works and uses v4 on the network between two v6 sockets, but
only if the initiator supports IPv6 with v4-mapped addresses.

This change detects v4-mapped address on v6 sockets for the wildcard
case, and instead formats the TargetAddress response as an IPv4 address.

In order to not further complicate iscsit_build_sendtargets_response,
I've actually simplified it by moving the bracket wrapping of IPv6
address into iscsit_accept_np where local_ip and login_ip strings are
set.  That also simplifies iscsi_stat_tgt_attr_show_attr_fail_intr_addr.

Side effect of the string format change is that
lio_target_nacl_show_info will now print login_ip bracket wrapped for
IPv6 connections, as will a few debug prints.

Signed-off-by: Chris Leech <cleech@redhat.com>
Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org>
drivers/target/iscsi/iscsi_target.c
drivers/target/iscsi/iscsi_target_login.c
drivers/target/iscsi/iscsi_target_stat.c