unable to add IPv6-only interface address as iscsi portal

[Kevin Otte]

When I attempt to add a ULA address as a portal IP:

/iscsi/iqn.20.../tpg1/portals> pwd
/iscsi/iqn.2000-12.net.nivex:storage.omashu/tpg1/portals
/iscsi/iqn.20.../tpg1/portals> create fd60:e0:a0f4:121::4
Using default IP port 3260
IP address does not exist: fd60:e0:a0f4:121::4

But this succeeds when adding a global IP:

/iscsi/iqn.20.../tpg1/portals> create 2606:a000:a449:5900::4
Using default IP port 3260
Created network portal 2606:a000:a449:5900::4:3260.
Entering new node /iscsi/iqn.2000-12.net.nivex:storage.omashu/tpg1/portals/2606:a000:a449:5900::4:3260

I do not know if this is a filter within the target that it can only add global IPs, or if it is only looking at primary interfaces and not VLANs:

$ ip addr
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    link/ether 00:21:85:10:77:49 brd ff:ff:ff:ff:ff:ff
    inet 172.31.3.4/24 brd 172.31.3.255 scope global eth0
       valid_lft forever preferred_lft forever
    inet6 2606:a000:a449:5900::4/64 scope global
       valid_lft forever preferred_lft forever
    inet6 fe80::221:85ff:fe10:7749/64 scope link
       valid_lft forever preferred_lft forever
3: eth0.121@eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether 00:21:85:10:77:49 brd ff:ff:ff:ff:ff:ff
    inet6 fd60:e0:a0f4:121::4/64 scope global
       valid_lft forever preferred_lft forever
    inet6 fe80::221:85ff:fe10:7749/64 scope link
       valid_lft forever preferred_lft forever

ProblemType: Bug
DistroRelease: Ubuntu 16.04
Package: targetcli 1:3.0~pre4.1~ga55d018-2
ProcVersionSignature: Ubuntu 4.4.0-43.63-generic 4.4.21
Uname: Linux 4.4.0-43-generic x86_64
ApportVersion: 2.20.1-0ubuntu2.1
Architecture: amd64
Date: Sat Nov 12 13:55:57 2016
PackageArchitecture: all
ProcEnviron:
 TERM=xterm
 PATH=(custom, no user)
 XDG_RUNTIME_DIR=<set>
 LANG=en_US.UTF-8
 SHELL=/bin/bash
SourcePackage: targetcli
UpgradeStatus: Upgraded to xenial on 2016-09-05 (68 days ago)

[Kevin Otte (nivex)]

Ah, this appears to be a fault in rtslib not enumerating the VLAN interface:

>>> import rtslib.utils
>>> rtslib.utils.list_eth_names()
['lo', 'eth0']

[Kevin Otte (nivex)]

So it turns out this is a bit of a "perfect storm" involving an IPv6-only interface.
I've filed a bug upstream at: https://github.com/Datera/rtslib/issues/17

[Kevin Otte (nivex)]

There has been no activity on this bug in nearly a year. We're a week away from releasing 17.10, which will put us well on the way to being in the dev cycle for the next LTS. I have grave concerns about a fix making it into the repo in time having witnessed deadlines come and go on previous releases. I really don't want to have to keep local patches around post-upgrade next year.

The upstream bug does have a patch associated with it. Is there anything else I need to do to shepherd this along?

[Kevin Otte (nivex)]

I just tested this with targetcli-fb in 17.10 and it gleefully allowed me to add a portal for an address that isn't even on the system, but I do see it listening in "ss -a -6" output. I guess this at least avoids the problem of upgrading my server from 16.04 -> 18.04 when the time comes. Sadly it looks as though 16.04 will be forever broken.