Frank, > Looking at the core file's stack trace using mdb I see the following: > > u...@server:~$ pfexec mdb frankgrimes97_core.iscsitgt > Loading modules: [ libumem.so.1 libc.so.1 libuutil.so.1 libavl.so.1 > libnvpair.so.1 ld.so.1 ] >> $c > libc.so.1`strcmp+0x90() > > I've also uploaded the core file to "/cores/ > frankgrimes97_core.iscsitgt" so that you can take a closer look.
Thank you for passing along the core file, as it resulting in catching a NULL pointer dereference in the CHAP authentication code. A review of the in-core data verifies that the iSCSI Initiator is OSX GlobalSAN (iqn.2005-03.com.sns: .... ), and that the code paths indicate that CHAP authentication is in progress. Where there is an issue, is the iSCSI login data has the iSCSI Initiator's name is set to NULL. RFC-3720 clearly states that the value 12.5 -- InitiatorName must be set for CHAP Authentication. Of course the code should check for this, regardless of that the RFC states. In due time a CR for this defect will be visible here: http://bugs.opensolaris.org/view_bug.do?bug_id=6800065 A follow up question is what version of OSX GlobalSAN are you using, as I tried this same test with version 3.3.0.43 of GlobalSAN, and found no issues when configuring CHAP Authentication, plus verified that one can not set the iSCSI Initiator's name to a NULL entry. The iSCSI Target is also configured for iSNS discovery, whose iSNS server are you using, and what version is it? Regards, Jim Dunham > > > Thanks, > > Frank > -- > This message posted from opensolaris.org > _______________________________________________ > storage-discuss mailing list > [email protected] > http://mail.opensolaris.org/mailman/listinfo/storage-discuss _______________________________________________ storage-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/storage-discuss
