After more digging, I found out this out of no where hex string is
referred to as "initiator_ext", and is being sent since srp_daemon.sh
give srp_daemon the "-n" flag. Since there's no user-set
initiator_ext, srp_daemon grabs it from somewhere.
If I want to continue using the "-n" flag, how can I find out what my
initiator is going to send as initiator_ext, so the target can be set
up to work with it?
Or, can I set my own initiator_ext, it looks by appending it to
/etc/srp_daemon.conf ?
Why doesn't ibsrpdm give the initiator_ext value?
On Wed, Jan 6, 2016 at 3:07 AM, james harvey <jamespharve...@gmail.com> wrote:
> I think:
>
> TL;DR - I can find my initiator's guid, but targetcli doesn't work
> with that in acls. I have to give it the i_port_id to work. How do I
> find the i_port_id, other than having a failed connection attempt and
> looking at dmesg?
>
> On Wed, Jan 6, 2016 at 3:02 AM, james harvey <jamespharve...@gmail.com> wrote:
>> I'm at a loss on how to get the hex address to go underneath acls when
>> setting up srpt. If I use the fe80 prefix I see everywhere including
>> /sys, it gets rejected. If I use the prefix shown in the kernel
>> rejection method, which I can't find anywhere else, it works fine.
>>
>> I am using targetcli, but I don't think this is a targetcli issue,
>> because it's the kernel showing in dmesg the bizzare prefix that I
>> can't figure out where it's coming from.
>>
>> Was linux 4.2.5 (-1 Arch) on both machines. Target upgraded to 4.3.2
>> (-2 Arch) with no change. Been acting like this for months, since I
>> started with InfiniBand.
>>
>> Just upgraded from ConnectX to ConnectX-2 cards, and seeing the same
>> behavior.
>>
>> targetcli configuration:
>>
>> /> ls
>> o- /
>> .........................................................................................................................
>> [...]
>> o- backstores
>> ..............................................................................................................
>> [...]
>> | o- block
>> ..................................................................................................
>> [Storage Objects: 3]
>> | | o- kvm1
>> ....................................................................
>> [/dev/disk1/kvm1 (100.0GiB) write-thru activated]
>> | | o- kvm2
>> ....................................................................
>> [/dev/disk2/kvm2 (100.0GiB) write-thru activated]
>> | | o- kvm3
>> ....................................................................
>> [/dev/disk3/kvm3 (100.0GiB) write-thru activated]
>> | o- fileio
>> .................................................................................................
>> [Storage Objects: 0]
>> | o- pscsi
>> ..................................................................................................
>> [Storage Objects: 0]
>> | o- ramdisk
>> ................................................................................................
>> [Storage Objects: 0]
>> o- iscsi
>> ............................................................................................................
>> [Targets: 0]
>> o- loopback
>> .........................................................................................................
>> [Targets: 0]
>> o- sbp
>> ..............................................................................................................
>> [Targets: 0]
>> o- srpt
>> .............................................................................................................
>> [Targets: 1]
>> | o- ib.fe800000000000000002c90300001679
>> ...........................................................................
>> [no-gen-acls]
>> | o- acls
>> ............................................................................................................
>> [ACLs: 1]
>> | | o- ib.fe800000000000000002c90300001e79
>> ....................................................................
>> [Mapped LUNs: 3]
>> | | o- mapped_lun0
>> ....................................................................................
>> [lun0 block/kvm1 (rw)]
>> | | o- mapped_lun1
>> ....................................................................................
>> [lun1 block/kvm2 (rw)]
>> | | o- mapped_lun2
>> ....................................................................................
>> [lun2 block/kvm3 (rw)]
>> | o- luns
>> ............................................................................................................
>> [LUNs: 3]
>> | o- lun0
>> .....................................................................................
>> [block/kvm1 (/dev/disk1/kvm1)]
>> | o- lun1
>> .....................................................................................
>> [block/kvm2 (/dev/disk2/kvm2)]
>> | o- lun2
>> .....................................................................................
>> [block/kvm3 (/dev/disk3/kvm3)]
>> o- vhost
>> ............................................................................................................
>> [Targets: 0]
>> o- xen_pvscsi
>> .......................................................................................................
>> [Targets: 0]
>>
>> NOTE my InfiniBand cards have similar IDs, and only differ by one
>> character -- compare the end, 1679 vs 1e79.
>>
>> On the target (host):
>> $ cat /sys/class/infiniband/mlx4_0/ports/1/gids/0
>> fe80:0000:0000:0000:0002:c903:0000:1679
>> {It's my understanding this should be used underneath srpt, as the wwn}
>>
>> On the initiator (client):
>> $ cat /sys/class/infiniband/mlx4_0/ports/1/gids/0
>> fe80:0000:0000:0000:0002:c903:0000:1e79
>> {It's my understanding this should be used underneath acls, and mapped
>> with the luns}
>> # ibsrpdm -c
>> id_ext=0002c90300001678,ioc_guid=0002c90300001678,dgid=fe800000000000000002c90300001679,pkey=ffff,service_id=0002c90300001678
>> {so, its /etc/srp_daemon.conf is just comments and the line}
>> a
>> id_ext=0002c90300001678,ioc_guid=0002c90300001678,dgid=fe800000000000000002c90300001679,pkey=ffff,service_id=0002c90300001678
>>
>> But, after starting service target on the target, and service
>> srpdaemon on the initiator, dmesg on target shows:
>> [ 849.710278] ib_srpt Received SRP_LOGIN_REQ with i_port_id
>> 0x7916000003c90200:0x2c90300001e79, t_port_id
>> 0x2c90300001678:0x2c90300001678 and it_iu_len 260 on port 1
>> (guid=0xfe80000000000000:0x2c90300001679)
>> [ 849.714528] ib_srpt Session : kernel thread ib_srpt_compl (PID 24481)
>> started
>> [ 849.714601] ib_srpt Rejected login because no ACL has been
>> configured yet for initiator 0x7916000003c902000002c90300001e79.
>> [ 849.714613] ib_srpt Session 0x7916000003c902000002c90300001e79:
>> kernel thread ib_srpt_compl (PID 24481) stopped
>>
>> And, dmesg on initiator shows:
>> [ 976.616221] scsi host11: ib_srp: REJ received
>> [ 976.616229] scsi host11: ib_srp: SRP LOGIN from
>> fe80:0000:0000:0000:0002:c903:0000:1e79 to
>> fe80:0000:0000:0000:0002:c903:0000:1679 REJECTED, reason 0x00010001
>> [ 976.616269] scsi host11: ib_srp: Connection 0/4 failed
>> [ 976.616276] scsi host11: ib_srp: Sending CM DREQ failed
>>
>> Why is the target machine, in the srp context only, seeing the ports
>> as starting with 0x7916000003c90200 and 0x2c90300001678, and the
>> client machine seeing the ports as starting with fe80:0000:0000:0000?
>> What are these 0x7916... and 0x2c90... prefixes, and how can I find
>> them besides getting a rejection and looking at the kernel logs? I
>> haven't seen these prefixes anywhere else on either system.
>>
>> In targetcli, if I use acls with 0x7916000003c902000002c90300001e79,
>> then everything works great.
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
