On 12/19/2014 09:32 AM, Tommy Apel wrote:
I can try to pull the 2.x branch and see if it works there just for
the sake of testing
Thanks, it should work.
In any case, I will fix this on 3.x soon.
Nic, seems that our last emails crossed each other, thank for confirming
2.x.
2014-12-19 9:31 GMT+01:00 Nicholas A. Bellinger <nab@xxxxxxxxxxxxxxx>:
On Fri, 2014-12-19 at 08:45 +0100, Tommy Apel wrote:
Hey Nicholas,
I pulled the trunk off https://github.com/Datera/rtslib.git yesterday
to because I wanted to test iSER
Thanks for the version info.
In that case, it might be a regression specific to rtslib v3.0, as my
example below to configure a network portal using an IPv6 private
address was actually using targetcli v2.x code.
Adding CC' for Jerome.
--nab
2014-12-19 8:20 GMT+01:00 Nicholas A. Bellinger <nab@xxxxxxxxxxxxxxx>:
Hi Tommy,
On Thu, 2014-12-18 at 20:50 +0100, Tommy Apel wrote:
Hello All,
how come I cannot use ipv6 adresses such as link-local and private
ipv6 within targetcli ?
/iscsi/iqn.20.../tpg1/portals> create fe80::f652:1403:7f:3041
Using default IP port 3260
IP address does not exist: fe80::f652:1403:7f:3041
/iscsi/iqn.20.../tpg1/portals> create fe00::f652:1403:7f:3041
Using default IP port 3260
IP address does not exist: fe00::f652:1403:7f:3041
4: ib0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 2044 qdisc pfifo_fast
state UP qlen 256
link/infiniband
80:00:00:48:fe:80:00:00:00:00:00:00:f4:52:14:03:00:7f:30:41 brd
00:ff:ff:ff:ff:12:40:1b:ff:ff:00:00:00:00:00:00:ff:ff:ff:ff
inet6 fe00::f652:1403:7f:3041/7 scope global
valid_lft forever preferred_lft forever
inet6 fe80::f652:1403:7f:3041/64 scope link
valid_lft forever preferred_lft forever
So iscsi-target currently doesn't support link-local addresses as
network portals, and rtslib is explicitly filtering them from the list
of available addresses provided in targetcli.
The issue is that link-local addresses need the ethernet interface
explicitly specified in order to successfully kernel_bind() from the
iscsi-target side, and there is currently not a method to relay
this information through configfs ahead of attempting kernel_bind()
during network portal creation.
However, all scope global and private addresses should work, and AFAICT
it looks your fe00::f652:1403:7f:3041 address is being incorrectly
filtered by userspace, and not actually failing during kernel_bind().
Here's how it looks on my end in targetcli using a similar fe00:
prefixed scope global private address following what you have above:
# link-local address is filtered from network portals
/iscsi/iqn.20...tpgt1/portals> create fe80::5054:ff:fe12:3456 3260
IP address does not exist: fe80::5054:ff:fe12:3456
# private address can be used as network portal
/iscsi/iqn.20...tpgt1/portals> create fe00::5054:ff:fe12:3456 3260
Successfully created network portal fe00::5054:ff:fe12:3456:3260.
/iscsi/iqn.20...tpgt1/portals> ls
o- portals .............................................................................. [2 Portals]
o- 10.0.2.15:3260 ............................................................................ [OK]
o- fe00::5054:ff:fe12:3456:3260 .............................................................. [OK]
/iscsi/iqn.20...tpgt1/portals>
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast
state UP qlen 1000
link/ether 52:54:00:12:34:56 brd ff:ff:ff:ff:ff:ff
inet 10.0.2.15/24 brd 10.0.2.255 scope global eth0
valid_lft forever preferred_lft forever
inet6 fe00::5054:ff:fe12:3456/7 scope global
valid_lft forever preferred_lft forever
inet6 fe80::5054:ff:fe12:3456/64 scope link
valid_lft forever preferred_lft forever
Please confirm which version of targetcli + rtslib your using.
Thanks for reporting!
--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
