Hi. I stumbled upon exactly the same issue. It's a bug in srp_daemon, and not in your
understanding of how things should be configured.
--- a/srp_daemon.c 2015-02-11 06:41:49.000000000 -0500
+++ b/srp_daemon.c 2017-02-23 07:10:56.509572959 -0500
@@ -541,7 +541,7 @@
len += snprintf(target_config_str+len,
MAX_TARGET_CONFIG_STR_STRING - len,
",initiator_ext=%016llx",
- (unsigned long long) ntohll(target->h_guid));
+ (unsigned long long) target->h_guid);
if (len >= MAX_TARGET_CONFIG_STR_STRING) {
pr_err("Target config string is too long, ignoring target\n");
It's indeed an "-n" option that causes havoc. In EL7 distro,
/usr/sbin/srp_daemon.sh should be edited to remove it, if you don't like it.
The right command to get the params the will be passed to ib_srp is: "srp_daemon -n
-o -c". It will give you an idea what actually is going to be created.
On a side note, it would be totally wonderful to have a user-friendly explanation from
DEVs of all these i_port_id, t_port_id, guid, LIDs, port GIDs, port GUIDs, UUIDs and all
other shmooids that often pop up in my dmesg output, along with explanation on how they
are crafted.
Thanks.
> 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.