issues with Solaris target about iscsiinitiator HOT 8 CLOSED

Looks like a corner case. Based on your input I’m guessing that discovery is being run with no discovery portals defined, is that true? If so it’s a simple null check that was missed.

Even with the daemon crashing, you should be able to list the discovery portals: iscsictl list discovery-config Are any listed?

As for your comment: "Presumably even if this crash didn't happen there would still be something else not working”, I will say that discovery and login does work on at least 3 different types of targets.

On Dec 14, 2015, at 12:47 AM, jeditekunum [email protected] wrote:

Total iscsi noob here. Just started playing with this. iscsid is crashing consistently. On 10.10.5 with latest Xcode.

Exception Type: EXC_BAD_ACCESS (SIGSEGV)
Exception Codes: KERN_INVALID_ADDRESS at 0x0000000000000000

Thread 4 Crashed:
0 com.apple.CoreFoundation 0x00007fff925233e9 CFArrayGetCount + 25
1 iscsid 0x000000010a829f79 iSCSIDiscoveryRunSendTargets + 41 (iSCSIDiscovery.c:127)
2 iscsid 0x000000010a8349a3 iSCSIDRunDiscovery + 19 (iSCSIDaemon.c:817)
3 libsystem_pthread.dylib 0x00007fff89fe505a _pthread_body + 131
4 libsystem_pthread.dylib 0x00007fff89fe4fd7 _pthread_start + 176
5 libsystem_pthread.dylib 0x00007fff89fe23ed thread_start + 13
I see that iSCSIPLCreateArrayOfPortalsForSendTargetsDiscovery can return null. This result is next passed to CFArrayGetCount in iSCSIDiscoveryRunSendTargets.

Things work up to the point of doing login. Server is Solaris 11. Presumably even if this crash didn't happen there would still be something else not working.

With some guidance I can make changes, test, and PR.

—
Reply to this email directly or view it on GitHub #20.

from iscsiinitiator.

I am able to do "add discovery-portal". When I do "modify discovery-config -SendTargets enable" I get "SendTargets discovery has been enabled" and then iscsid crashes as shown above.

After rebooting, I removed the discovery-portal and tried a manual "add target" which worked. Then when it tries to login it crashes the same.

My server shows the target:

TARGET NAME                                                  STATE    SESSIONS 
iqn.1986-03.com.sun:02:a0e142c3-5e3c-e307-dd2e-872c4a6f8141  online   0        
    alias:                  -
    auth:                   none (defaults)
    targetchapuser:         -
    targetchapsecret:       unset
    tpg-tags:               default

from iscsiinitiator.

I added null-checking in several places (commit 8f36135). Basically, your first crash dump tells me that for some reason the daemon thinks no discovery portals have been added. Perhaps they weren't the first time, or they were and there's some other problem. If the second crash was like the first (same backtrace?), then it is likely that it has little to do with login and is really just the first problem again.

Try the new build and tell me if sudo iscsictl add discovery-portal ... and sudo iscsictl modify discovery-config -SendTargets enable works (i.e., causes your target to show up when you list targets). We'll start there. You'll have to give it at least 30 seconds or whatever your discovery interval is set to, after that, the targets should show up. Let's deal with this first and see if the login issue persists.

from iscsiinitiator.

Thanks for the quick update. I have gotten further.

It no longer crashes but instead it hangs. I discovered that Solaris does not enable discovery by default so after enabling SendTargets on Solaris the discovery is working (I can see it in "list targets").

Now I have a iscsid hang when doing login.

    2831 Thread_620   DispatchQueue_1: com.apple.main-thread  (serial)
    + 2831 start  (in iscsid) + 52  [0x107c63384]
    +   2831 main  (in iscsid) + 909  [0x107c6f52d]  iSCSIDaemon.c:1128
    +     2831 CFRunLoopRun  (in CoreFoundation) + 97  [0x7fff8db9b671]
    +       2831 CFRunLoopRunSpecific  (in CoreFoundation) + 296  [0x7fff8dae3bd8]
    +         2831 __CFRunLoopRun  (in CoreFoundation) + 927  [0x7fff8dae41bf]
    +           2831 __CFRunLoopDoSources0  (in CoreFoundation) + 269  [0x7fff8dae4b8d]
    +             2831 __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__  (in CoreFoundation) + 17  [0x7fff8daf2a01]
    +               2831 __CFSocketPerformV0  (in CoreFoundation) + 768  [0x7fff8db32980]
    +                 2831 iSCSIDProcessIncomingRequest  (in iscsid) + 291  [0x107c6f003]  iSCSIDaemon.c:1007
    +                   2831 iSCSIDLogin  (in iscsid) + 282  [0x107c6db6a]  iSCSIDaemon.c:436
    +                     2831 iSCSIDLoginAllPortals  (in iscsid) + 437  [0x107c6d7e5]  iSCSIDaemon.c:325
    +                       2831 iSCSIDLoginCommon  (in iscsid) + 372  [0x107c6d4f4]  iSCSIDaemon.c:252
    +                         2831 iSCSILoginSession  (in iscsid) + 891  [0x107c662bb]  iSCSISession.c:924
    +                           2831 iSCSIKernelActivateConnection  (in iscsid) + 155  [0x107c6b9bb]  iSCSIKernelInterface.c:565
    +                             2831 IOConnectCallScalarMethod  (in IOKit) + 111  [0x7fff8e04ec52]
    +                               2831 io_connect_method  (in IOKit) + 381  [0x7fff8e0ab16c]
    +                                 2831 mach_msg  (in libsystem_kernel.dylib) + 55  [0x7fff8e03a64f]
    +                                   2831 mach_msg_trap  (in libsystem_kernel.dylib) + 10  [0x7fff8e03b4de]

Log:

Dec 14 07:15:04 dagobah sudo[1069]:    steve : TTY=ttys000 ; PWD=/home/steve ; USER=root ; COMMAND=/usr/bin/iscsictl login iqn.1986-03.com.sun:02:a0e142c3-5e3c-e307-dd2e-872c4a6f8141
Dec 14 07:15:04 dagobah kernel[0]: iscsi: Sent PDU type 0x43 (sid: 0, cid: 0)
Dec 14 07:15:04 dagobah kernel[0]: iscsi: Sending data length: b5
Dec 14 07:15:04 dagobah kernel[0]: iscsi: Sent PDU type 0x43 (sid: 0, cid: 0)
Dec 14 07:15:04 dagobah kernel[0]: iscsi: Sending data length: 11b
Dec 14 07:15:04 dagobah kernel[0]: iscsi: Transfer size: 0 (sid: 0, cid: 0)
Dec 14 07:15:04 dagobah kernel[0]: iscsi: Queued task 0 (sid: 0, cid: 0)
Dec 14 07:15:04 dagobah kernel[0]: iscsi: Starting task 0 (sid: 0, cid: 0)
Dec 14 07:15:04 dagobah kernel[0]: iscsi: Sent PDU type 0x1 (sid: 0, cid: 0)
Dec 14 07:16:04 dagobah kernel[0]: iscsi: Task timeout for task 0 (sid: 0, cid: 0)
Dec 14 07:16:04 dagobah kernel[0]: iscsi: Transfer size: 0 (sid: 0, cid: 0)
Dec 14 07:16:04 dagobah kernel[0]: iscsi: Queued task 0 (sid: 0, cid: 0)
Dec 14 07:16:04 dagobah kernel[0]: iscsi: Starting task 0 (sid: 0, cid: 0)
Dec 14 07:16:04 dagobah kernel[0]: iscsi: Sent PDU type 0x1 (sid: 0, cid: 0)
Dec 14 07:17:04 dagobah kernel[0]: iscsi: Task timeout for task 0 (sid: 0, cid: 0)
Dec 14 07:17:04 dagobah kernel[0]: iscsi: Connection timeout (sid: 0, cid: 0)
Dec 14 07:17:04 dagobah kernel[0]: iscsi: Releasing session (sid 0)
Dec 14 07:17:04 dagobah kernel[0]: iscsi: Deactivated connection (sid: 0, cid: 0)
Dec 14 07:17:04 dagobah kernel[0]: iscsi: Removed event sources (sid: 0, cid: 0)
Dec 14 07:17:04 dagobah kernel[0]: iscsi: Released connection (sid: 0, cid: 0)

My Solaris config says:

Target: iqn.1986-03.com.sun:02:a0e142c3-5e3c-e307-dd2e-872c4a6f8141
    Alias: -
    TPGT: 1
    ISID: 4000002a0000
    Connections: 1
        CID: 0
          IP address (Local): 192.168.7.10:43138
          IP address (Peer): 192.168.7.10:3260
          Discovery Method: SendTargets 
          Login Parameters (Negotiated):
            Data Sequence In Order: yes
            Data PDU In Order: yes
            Default Time To Retain: 20
            Default Time To Wait: 2
            Error Recovery Level: 0
            First Burst Length: 65536
            Immediate Data: yes
            Initial Ready To Transfer (R2T): yes
            Max Burst Length: 262144
            Max Outstanding R2T: 1
            Max Receive Data Segment Length: 32768
            Max Connections: 32
            Header Digest: NONE
            Data Digest: NONE

from iscsiinitiator.

Excellent, now we're getting somewhere. I'm not aware of anyone having used this with Solaris, and I have not tested it with Solaris so this is good. Can you please attach a tcpdump of the iSCSI traffic (or Wireshark, whichever you prefer)? If you start capture iSCSI traffic only just before login for about a minute or two that should be enough. I'll take a look at that and see if I can figure out what is happening.

The log you attached shows that the iSCSI kernel extension automatically drops the connection after a task timeout. This means that the initiator sent a request to the target, the target didn't respond and the initiator dropped the session. I've only seen this happen in the past with IET targets on Linux when the SCSI I/O byte count is too high. This is a parameter that is specified in the kernel extension's .plist, and it tells OS X what the maximum I/O request size should be. The values are empirically set based on testing I've done with a few targets. Feel free to reduce those values to see if the connection is no longer dropped. You will basically have to run the uninstall script, change values in the kext folder's Info.plist file, and then run the install script again for it to take effect.

from iscsiinitiator.

iSCSI-Solaris.pcapng.zip

from iscsiinitiator.

I believe the login issue has now been resolved (please try commit 1b206fd). I am able to login and format an iSCSI disk on a Solaris 11 (COMSTAR) target. Please verify and let us know.

from iscsiinitiator.

Fabulous!

It is working for me with Solaris 11.2.

Thank you!

from iscsiinitiator.