On 01/07/2016 09:50 PM, james harvey wrote:
If I run "ibsrpdm -c" it shows:
a
id_ext=0002c90300001678,ioc_guid=0002c90300001678,dgid=fe800000000000000002c90300001679,pkey=ffff,service_id=0002c90300001678
But, srp_daemon with "-n" sends i_port_id 0x7916000003c90200:0x2c90300001e79
The 0x7916000003c90200 part is what I couldn't figure out how to see,
before a failed connection attempt. It's not in the ibsrpdm output.
Well, not exactly. Looked through the code, and I see now this
"mysterious" number is the target's port GUID, scrambled a bit. It's
made by reversing the target's port GUID (the last hafl of dgid), in
byte-sized chunks. You'll see the dgid ends in 1679, and the number I
was calling "out of no where" as the initiator_ext value starts with
7916. That's 1679 in reverse, in byte-sized ("16" and "79")
chunks.
Can't remember the function srp_daemon used to do this, but it's
something related to different platform byte ordering.
I don't see in any documentation anywhere for SRP or targetcli
anything about how to set up targetcli without having a rejected
connection attempt. Turns out you can just do the re-ordering of the
last half of the target port GUID to figure out what targetcli needs
for a successful attempt.
If you have a successful procedure for getting SRP target working, it'd
be great for us to add it to the targetcli man page. I've been trying to
follow along and am just confused. It seems crazy that anything would
require rearranging parts of long hex values to work!
-- Andy