unable to specify digest/type

[disruptek]

I've used the globalSAN product for years against a Synology 4XX-series SAN. I've used Windows clients against the same SAN with success. I just built a hackintosh running OS X 10.13.1 and I'm attempting to run iSCSIInitiator -- the binary 1.0.0-beta6 release -- against the same SAN target.

After issuing a login, I received the cryptic iscsictl: An initiator error has occurred. Using Wireshark, I was able to see that the second login stage was submitting a request for a digest-free session against the Synology target, which is configured with header digest. That request is apparently rejected by the server, and turning off header digest subsequently allowed me to mount the SAN targets.

I see how to go about specifying the header digest on the client, but all my attempts yield the error 'iscsictl: The specified digest type is invalid'; I've tried values of crc, crc32, crc32c. I've tried a few capitalization permutations and I even added some escaped string quotes as well.
I've even tried modifying the preferences plist manually to specify "crc32c" as the digest method.

$ iscsictl modify target-config iqn.2000-01.com.synology:BadnAss.Olive -HeaderDigest crc32c
iscsictl: The specified digest type is invalid
$

Thanks in advance for any clues as to what I'm missing!

[disruptek]

For those following behind me... Despite fixing the specification bug, I still cannot setup sessions with header or data digest CRC. The following output is from the Synology's log:

[260431.854027] iSCSI:iscsi_target.c:4223:iscsit_get_rx_pdu HeaderDigest CRC32C failed, received 0x00000000, computed 0x6a51e3c9
[260431.865393] iSCSI:iscsi_target.c:4144:iscsi_target_rx_opcode Got unknown iSCSI OpCode: 0xff
[260431.873864] iSCSI:iscsi_target.c:4147:iscsi_target_rx_opcode Cannot recover from unknown opcode while ERL=0, closing iSCSI connection.

[nsinenian]

I believe the "specification bug" was more about posting an incorrect error message -- it still registered digests. Regardless, that has been addressed. I am unable to reproduce the problem using FreeBSD targets with header / data digests (I verified on the latest debug build that they were being transmitted/processed using WireShark. Can you capture some WireShark output with header digests enabled during the connection process and post here?

[mrdc]

@disruptek
Was you able to fix it?

[disruptek]

Nope, switched to Linux.