Jump to content
SNS Users' Forums
  • Announcements

    • Eric Newbauer

      Follow SNS on Twitter!

      Get notifications via Twitter! Looking for instant updates? We're now also announcing new versions and beta programs via Twitter. Follow Studio Network Solutions on Twitter. Thanks!

Recommended Posts

Attempting to attach to the iscsi target in a netapp.

I see the following errors:

2007-03-13 13:46:56.094 globalSAN iSCSI[414] iSCSI connection to target "iqn.1992-08.com.netapp:sn.84210206" failed with error code 120C: invalid stage transision in login response

Mar 13 13:46:56 tonnage kernel[0]: IOCommandGate::disable() called when not gated

Mar 13 13:46:56 tonnage kernel[0]: Backtrace 0x43c7ee96 0x3bc2b6 0x3bc385 0x43c7c675 0x3b0844 0x18a187 0x12b4da

Mar 13 13:46:56 tonnage kernel[0]: Kernel loadable modules in backtrace (with dependencies):

Mar 13 13:46:56 tonnage kernel[0]: com.StudioNetworkSolutions.driver.globalSAN(1150)@0x43c77000

Mar 13 13:46:56 tonnage kernel[0]: dependency: com.apple.iokit.IOSCSIParallelFamily(1.4.3)@0x43c70000

Mar 13 13:46:56 tonnage kernel[0]: dependency: com.apple.iokit.IOStorageFamily(1.5.1)@0x3baba000

I could easily provide a pktt trace if anyone was interested.

Share this post


Link to post
Share on other sites
Attempting to attach to the iscsi target in a netapp.

I see the following errors:

2007-03-13 13:46:56.094 globalSAN iSCSI[414] iSCSI connection to target "iqn.1992-08.com.netapp:sn.84210206" failed with error code 120C: invalid stage transision in login response

Mar 13 13:46:56 tonnage kernel[0]: IOCommandGate::disable() called when not gated

Mar 13 13:46:56 tonnage kernel[0]: Backtrace 0x43c7ee96 0x3bc2b6 0x3bc385 0x43c7c675 0x3b0844 0x18a187 0x12b4da

Mar 13 13:46:56 tonnage kernel[0]: Kernel loadable modules in backtrace (with dependencies):

Mar 13 13:46:56 tonnage kernel[0]: com.StudioNetworkSolutions.driver.globalSAN(1150)@0x43c77000

Mar 13 13:46:56 tonnage kernel[0]: dependency: com.apple.iokit.IOSCSIParallelFamily(1.4.3)@0x43c70000

Mar 13 13:46:56 tonnage kernel[0]: dependency: com.apple.iokit.IOStorageFamily(1.5.1)@0x3baba000

I could easily provide a pktt trace if anyone was interested.

Hi JohnnyV,

We'd be happy to take a look if you post a trace.

You might also double-check the CHAP settings, but it's unlikely that that's the cause of this problem...

regards,

Ryan

Share this post


Link to post
Share on other sites
Hi JohnnyV,

We'd be happy to take a look if you post a trace.

You might also double-check the CHAP settings, but it's unlikely that that's the cause of this problem...

regards,

Ryan

Johnny,

Better yet, please email your trace logs to iscsi@studionetworksolutions.com and we'll see what we can do.

thanks again,

Ryan

Share this post


Link to post
Share on other sites
Johnny,

Better yet, please email your trace logs to iscsi@studionetworksolutions.com and we'll see what we can do.

thanks again,

Ryan

working on it :) day job is getting in the way ;)

Share this post


Link to post
Share on other sites
working on it :) day job is getting in the way ;)

ok.... sent the iscsi part of the trace. Let me know id you want any other info.

Share this post


Link to post
Share on other sites
ok.... sent the iscsi part of the trace. Let me know id you want any other info.

Got the logs, thanks! We'll have a look and let you know something soon....

-ryan

Share this post


Link to post
Share on other sites
Guest Ted Richardson

JohnnyV:

I took a look at the packet print-out that you sent over and I'm afraid that I'm going to need a bit more information. As far as I can tell, the iSCSI login command coming from the initiator seems well-formed but the response from the target isn't flagged to continue to the next stage.

There's a chance that the target itself has some type of security to prevent "unauthorized" initiators from logging in. I'm aware of other systems that require the user to register the iqn (found under preferences) or the IP address of our initiator somewhere within the target's management system.

If you wouldn't mind, would you please send over a couple more capture files? Instead of dumping the packets to text, though, simply make a raw capture file like documented in Forum topic 117.

In addition to the instructions there, please start the capture with the portal list empty. Once your portal is entered, keep the capture running until after the "gear" stops turning and after you attempt to connect to a target (if the target list is building properly).

Also, it'd be a big help to capture the same basic steps from a machine that can successfully connect to your target for comparison.

Thanks for your help,

Ted

Share this post


Link to post
Share on other sites
JohnnyV:

I took a look at the packet print-out that you sent over and I'm afraid that I'm going to need a bit more information. As far as I can tell, the iSCSI login command coming from the initiator seems well-formed but the response from the target isn't flagged to continue to the next stage.

There's a chance that the target itself has some type of security to prevent "unauthorized" initiators from logging in. I'm aware of other systems that require the user to register the iqn (found under preferences) or the IP address of our initiator somewhere within the target's management system.

If you wouldn't mind, would you please send over a couple more capture files? Instead of dumping the packets to text, though, simply make a raw capture file like documented in Forum topic 117.

In addition to the instructions there, please start the capture with the portal list empty. Once your portal is entered, keep the capture running until after the "gear" stops turning and after you attempt to connect to a target (if the target list is building properly).

Also, it'd be a big help to capture the same basic steps from a machine that can successfully connect to your target for comparison.

Thanks for your help,

Ted

Hello. I am having the same problem as JohnnyV, and thought instead of starting a new thread, I might as well use this one. I have made a packet capture as requested. Where should I send it?

Share this post


Link to post
Share on other sites
Hello. I am having the same problem as JohnnyV, and thought instead of starting a new thread, I might as well use this one. I have made a packet capture as requested. Where should I send it?

Please send your packet capture to iscsi@studionetworksolutions.com

Thanks!

Share this post


Link to post
Share on other sites
JohnnyV:

There's a chance that the target itself has some type of security to prevent "unauthorized" initiators from logging in. I'm aware of other systems that require the user to register the iqn (found under preferences) or the IP address of our initiator somewhere within the target's management system.

Security on the NetApp's is pretty straight forward. You need to create the LUN, then create an iGroup (LUN Masking based on Initiator IQN) then map the two together.

Here's a complete example for anyone playing with a NetApp but new to iSCSI (this example is for Solaris):

netapp01> lun create -s 500g -t solaris /vol/smaccel/bridget0 
lun create: created a LUN of size:  500.1g (536952700928) 
netapp01> 
netapp01> igroup create -i -t solaris bridget 
netapp01> igroup add bridget iqn.1986-03.com.sun:01:e00000000000.4616cd07
netapp01> 
netapp01> lun map /vol/smaccel/bridget0 bridget
lun map: auto-assigned bridget=0
netapp01> 
netapp01> igroup show
bridget (iSCSI) (ostype: solaris):
	iqn.1986-03.com.sun:01:e00000000000.4616cd07 (not logged in)
netapp01> 
netapp01> lun show -v
	/vol/smaccel/bridget0	 500.1g (536952700928)  (r/w, online, mapped)
			Serial#: hpi3k4AQDl-f
			Share: none
			Space Reservation: enabled
			Multiprotocol Type: solaris
			Maps: bridget=0

The above creates a 500GB LUN on the "smaccel" FlexVol. The only thing that would change for Mac would be the OS Type (-t) which you should set to "default" (or just omit the flag entirely).

benr.

Share this post


Link to post
Share on other sites

I was able to get it to work with my Netapp (FAS880) running DOT 7.1.2.1 by setting up chap authentication on both ends.

I was seeing the same error 120c prior to setting up chap.

Share this post


Link to post
Share on other sites
I was able to get it to work with my Netapp (FAS880) running DOT 7.1.2.1 by setting up chap authentication on both ends.

I was seeing the same error 120c prior to setting up chap.

Hi brauhaus. After I setup the chap, the Mac OS can log in the Target (Netapp). However, the disk utility of Mac cannot recognize the iSCSI disk. Is there any addiition configuration required? Thanks.

Share this post


Link to post
Share on other sites
Hi brauhaus. After I setup the chap, the Mac OS can log in the Target (Netapp). However, the disk utility of Mac cannot recognize the iSCSI disk. Is there any addiition configuration required? Thanks.

Using the "sessions" tab in the globalsan tool, I used "get info" and saw the lun. If you don't, it seems to show up again after a log out and log back in. Then, use "disk utility" and it showed up there. You can partition or erase then.

Not saying that this is all working smoothly -- I need to play with it a bit more, I think. Had some issues reconnecting after I powered off the mac and powered it back on.

Dan.

Share this post


Link to post
Share on other sites
Using the "sessions" tab in the globalsan tool, I used "get info" and saw the lun. If you don't, it seems to show up again after a log out and log back in. Then, use "disk utility" and it showed up there. You can partition or erase then.

Not saying that this is all working smoothly -- I need to play with it a bit more, I think. Had some issues reconnecting after I powered off the mac and powered it back on.

Another bit of weirdness I'm seeing -- if I have 2x luns, a lun0 at 5g and a lun1 at 15g, both show up with the same name (in this case "NetappLun0") and the same 5g size.

Something here isn't quite right.

Share this post


Link to post
Share on other sites

×