RE: CHAP with Open-iSCSI
Mike, This explains it. We are using: iscsid: transport class version 2.0-867. iscsid version 2.0-869 I will see how to upgrade it. We have patches for bidirectional and large CBDs. Thx, Arvind. -Original Message- From: open-iscsi@googlegroups.com [mailto:open-is...@googlegroups.com] On Behalf Of Mike Christie Sent: Thursday, January 29, 2009 1:34 PM To: open-iscsi@googlegroups.com Subject: Re: CHAP with Open-iSCSI Arvind Jain wrote: Hi Mike, We are using Open iSCSI initiator with our iSCSI target. I have a question on CHAP. I did some experiment and it appears to me that OneWay-CHAP does not work with open-iscsi, Mutual-CHAP does work fine for me. Have others seen the same behavior? What version are you using? I noticed in git one way chap is broken. 870.1 works though. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups open-iscsi group. To post to this group, send email to open-iscsi@googlegroups.com To unsubscribe from this group, send email to open-iscsi+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/open-iscsi -~--~~~~--~~--~--~---
RE: CHAP with Open-iSCSI
Mike, Thanks for this excellent support. Let me know if I can do anything. I can send you wire shark trace with MS initiator oneway-CHAP if this will help. Thx, Arvind. -Original Message- From: open-iscsi@googlegroups.com [mailto:open-is...@googlegroups.com] On Behalf Of Mike Christie Sent: Thursday, January 29, 2009 3:08 PM To: open-iscsi@googlegroups.com Subject: Re: CHAP with Open-iSCSI Arvind Jain wrote: Mike, I have attached the wire shark trace for OneWay-CHAP and Mutual-CHAP. I am not sure how helpful this is. In case of OneWay-CHAP, Open-iscsi initiator does not continues with the login step and gives and error as follows: Logging in to [iface: default, target: iqn.2008-07.com.wasabi:osd.1, portal: 192.168.0.90,3260] iscsiadm: Could not login to [iface: default, target: iqn.2008-07.com.wasabi:osd.1, portal: 192.168.0.90,3260]: iscsiadm: initiator reported error (5 - encountered iSCSI login failure) Target discovery or login failed It looks a normal old interop bug. It looks like the initiator and target do not agree what stage/phase we should be in. The initiator thinks you guys goof and the target thinks we should be continuing on with chap. I have not touched the login acl code in 6 years, so it will take me a bit to look over it and figure out who is wrong. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups open-iscsi group. To post to this group, send email to open-iscsi@googlegroups.com To unsubscribe from this group, send email to open-iscsi+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/open-iscsi -~--~~~~--~~--~--~---
CHAP with Open-iSCSI
Hi Mike, We are using Open iSCSI initiator with our iSCSI target. I have a question on CHAP. I did some experiment and it appears to me that OneWay-CHAP does not work with open-iscsi, Mutual-CHAP does work fine for me. Have others seen the same behavior? Thx, Arvind. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups open-iscsi group. To post to this group, send email to open-iscsi@googlegroups.com To unsubscribe from this group, send email to open-iscsi+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/open-iscsi -~--~~~~--~~--~--~---
RE: CHAP with Open-iSCSI
Mike, I have attached the wire shark trace for OneWay-CHAP and Mutual-CHAP. I am not sure how helpful this is. In case of OneWay-CHAP, Open-iscsi initiator does not continues with the login step and gives and error as follows: Logging in to [iface: default, target: iqn.2008-07.com.wasabi:osd.1, portal: 192.168.0.90,3260] iscsiadm: Could not login to [iface: default, target: iqn.2008-07.com.wasabi:osd.1, portal: 192.168.0.90,3260]: iscsiadm: initiator reported error (5 - encountered iSCSI login failure) Target discovery or login failed BTW, Microsoft initiator works fine with OneWay-CHAP and Mutual-CHAP with our target. So I think it something subtle. Thx, Arvind. -Original Message- From: open-iscsi@googlegroups.com [mailto:open-is...@googlegroups.com] On Behalf Of Mike Christie Sent: Wednesday, January 28, 2009 1:25 PM To: open-iscsi@googlegroups.com Subject: Re: CHAP with Open-iSCSI Mike Christie wrote: Arvind Jain wrote: Hi Mike, We are using Open iSCSI initiator with our iSCSI target. I have a question on CHAP. I did some experiment and it appears to me that OneWay-CHAP does not work with open-iscsi, Mutual-CHAP does work fine for me. Have others seen the same behavior? Not really. I have the opposite. I have seen a report where Mutual-CHAP does not work, but OneWay-CHAP works fine with LSI targets. Mutual-CHAP or OneWay-CHAP works fine with IET, Netapp and Equallogic Actually not sure about Equallogic. I think we just tested one way. I am not sure if we tested 2 way. and some box you probably never heard of here. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups open-iscsi group. To post to this group, send email to open-iscsi@googlegroups.com To unsubscribe from this group, send email to open-iscsi+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/open-iscsi -~--~~~~--~~--~--~--- open_iscsi_MutualCHAP.pcap Description: Binary data open_iscsi_OnewayCHAP.pcap Description: Binary data
RE: CHAP with Open-iSCSI
Mike, I have the following info as you requested: [r...@localhost ~]# iscsid -d 8 -f iscsid: sysfs_init: sysfs_path='/sys' iscsid: sysfs_attr_get_value: open '/module/scsi_transport_iscsi'/'version' iscsid: sysfs_attr_get_value: new uncached attribute '/sys/module/scsi_transport_iscsi/version' iscsid: sysfs_attr_get_value: add to cache '/sys/module/scsi_transport_iscsi/version' iscsid: sysfs_attr_get_value: cache '/sys/module/scsi_transport_iscsi/version' with attribute value '2.0-867' iscsid: transport class version 2.0-867. iscsid version 2.0-869 iscsid: in ctldev_open iscsid: created NETLINK_ISCSI socket... iscsid: InitiatorName==iqn.2005-03.org.open-iscsi:1bd5bc7d3378 iscsid: InitiatorName=iqn.2005-03.org.open-iscsi:1bd5bc7d3378 iscsid: InitiatorAlias=localhost.localdomain iscsid: in ctldev_close iscsid: Max file limits 1024 1024 iscsid: reaped pid 3625, reap_count now 0 [r...@localhost ~]# iscsiadm -m node -T iqn.2008-07.com.wasabi:osd.1 -p 192.168.0.90,3260 node.name = iqn.2008-07.com.wasabi:osd.1 node.tpgt = -1 node.startup = manual iface.hwaddress = default iface.iscsi_ifacename = default iface.net_ifacename = default iface.transport_name = tcp iface.initiatorname = empty node.discovery_address = 192.168.0.90 node.discovery_port = 3260 node.discovery_type = send_targets node.session.initial_cmdsn = 0 node.session.initial_login_retry_max = 4 node.session.cmds_max = 128 node.session.queue_depth = 32 node.session.auth.authmethod = CHAP node.session.auth.username = user0 node.session.auth.password = node.session.auth.username_in = empty node.session.auth.password_in = empty node.session.timeo.replacement_timeout = 120 node.session.err_timeo.abort_timeout = 15 node.session.err_timeo.lu_reset_timeout = 20 node.session.err_timeo.host_reset_timeout = 60 node.session.iscsi.FastAbort = Yes node.session.iscsi.InitialR2T = No node.session.iscsi.ImmediateData = No node.session.iscsi.FirstBurstLength = 262144 node.session.iscsi.MaxBurstLength = 16776192 node.session.iscsi.DefaultTime2Retain = 0 node.session.iscsi.DefaultTime2Wait = 2 node.session.iscsi.MaxConnections = 1 node.session.iscsi.MaxOutstandingR2T = 1 node.session.iscsi.ERL = 0 node.conn[0].address = 192.168.0.90 node.conn[0].port = 3260 node.conn[0].startup = manual node.conn[0].tcp.window_size = 524288 node.conn[0].tcp.type_of_service = 0 node.conn[0].timeo.logout_timeout = 15 node.conn[0].timeo.login_timeout = 15 node.conn[0].timeo.auth_timeout = 45 node.conn[0].timeo.noop_out_interval = 30 node.conn[0].timeo.noop_out_timeout = 30 node.conn[0].iscsi.MaxRecvDataSegmentLength = 131072 node.conn[0].iscsi.HeaderDigest = None node.conn[0].iscsi.DataDigest = None node.conn[0].iscsi.IFMarker = No node.conn[0].iscsi.OFMarker = No [r...@localhost ~]# The above info is with the Oneway-CHAP. Let me know if you need any other info. Thx, Arvind. -Original Message- From: open-iscsi@googlegroups.com [mailto:open-is...@googlegroups.com] On Behalf Of Mike Christie Sent: Wednesday, January 28, 2009 3:31 PM To: open-iscsi@googlegroups.com Subject: Re: CHAP with Open-iSCSI Arvind Jain wrote: Mike, I have attached the wire shark trace for OneWay-CHAP and Mutual-CHAP. I am not sure how helpful this is. In case of OneWay-CHAP, Open-iscsi initiator does not continues with the login step and gives and error as follows: Logging in to [iface: default, target: iqn.2008-07.com.wasabi:osd.1, portal: 192.168.0.90,3260] iscsiadm: Could not login to [iface: default, target: iqn.2008-07.com.wasabi:osd.1, portal: 192.168.0.90,3260]: iscsiadm: initiator reported error (5 - encountered iSCSI login failure) Target discovery or login failed Could you give me the output of iscsiadm -m node -T iqn.2008-07.com.wasabi:osd.1 -p 192.168.0.90,3260 And could you run iscsid by hand with debugging and give me that output when you try to login # iscsid -d 8 -f will print it out to the console. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups open-iscsi group. To post to this group, send email to open-iscsi@googlegroups.com To unsubscribe from this group, send email to open-iscsi+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/open-iscsi -~--~~~~--~~--~--~---
RE: CHAP with Open-iSCSI
Oops, forgot to attach the login debug info using iscsid -d 8 -f last time. Debug output attached for oneway-CHAP and Mutual-CHAP. Mutual-CHAP works fine with our target. Thx, Arvind. -Original Message- From: open-iscsi@googlegroups.com [mailto:open-is...@googlegroups.com] On Behalf Of Arvind Jain Sent: Wednesday, January 28, 2009 8:43 PM To: open-iscsi@googlegroups.com Subject: RE: CHAP with Open-iSCSI Mike, I have the following info as you requested: [r...@localhost ~]# iscsid -d 8 -f iscsid: sysfs_init: sysfs_path='/sys' iscsid: sysfs_attr_get_value: open '/module/scsi_transport_iscsi'/'version' iscsid: sysfs_attr_get_value: new uncached attribute '/sys/module/scsi_transport_iscsi/version' iscsid: sysfs_attr_get_value: add to cache '/sys/module/scsi_transport_iscsi/version' iscsid: sysfs_attr_get_value: cache '/sys/module/scsi_transport_iscsi/version' with attribute value '2.0-867' iscsid: transport class version 2.0-867. iscsid version 2.0-869 iscsid: in ctldev_open iscsid: created NETLINK_ISCSI socket... iscsid: InitiatorName==iqn.2005-03.org.open-iscsi:1bd5bc7d3378 iscsid: InitiatorName=iqn.2005-03.org.open-iscsi:1bd5bc7d3378 iscsid: InitiatorAlias=localhost.localdomain iscsid: in ctldev_close iscsid: Max file limits 1024 1024 iscsid: reaped pid 3625, reap_count now 0 [r...@localhost ~]# iscsiadm -m node -T iqn.2008-07.com.wasabi:osd.1 -p 192.168.0.90,3260 node.name = iqn.2008-07.com.wasabi:osd.1 node.tpgt = -1 node.startup = manual iface.hwaddress = default iface.iscsi_ifacename = default iface.net_ifacename = default iface.transport_name = tcp iface.initiatorname = empty node.discovery_address = 192.168.0.90 node.discovery_port = 3260 node.discovery_type = send_targets node.session.initial_cmdsn = 0 node.session.initial_login_retry_max = 4 node.session.cmds_max = 128 node.session.queue_depth = 32 node.session.auth.authmethod = CHAP node.session.auth.username = user0 node.session.auth.password = node.session.auth.username_in = empty node.session.auth.password_in = empty node.session.timeo.replacement_timeout = 120 node.session.err_timeo.abort_timeout = 15 node.session.err_timeo.lu_reset_timeout = 20 node.session.err_timeo.host_reset_timeout = 60 node.session.iscsi.FastAbort = Yes node.session.iscsi.InitialR2T = No node.session.iscsi.ImmediateData = No node.session.iscsi.FirstBurstLength = 262144 node.session.iscsi.MaxBurstLength = 16776192 node.session.iscsi.DefaultTime2Retain = 0 node.session.iscsi.DefaultTime2Wait = 2 node.session.iscsi.MaxConnections = 1 node.session.iscsi.MaxOutstandingR2T = 1 node.session.iscsi.ERL = 0 node.conn[0].address = 192.168.0.90 node.conn[0].port = 3260 node.conn[0].startup = manual node.conn[0].tcp.window_size = 524288 node.conn[0].tcp.type_of_service = 0 node.conn[0].timeo.logout_timeout = 15 node.conn[0].timeo.login_timeout = 15 node.conn[0].timeo.auth_timeout = 45 node.conn[0].timeo.noop_out_interval = 30 node.conn[0].timeo.noop_out_timeout = 30 node.conn[0].iscsi.MaxRecvDataSegmentLength = 131072 node.conn[0].iscsi.HeaderDigest = None node.conn[0].iscsi.DataDigest = None node.conn[0].iscsi.IFMarker = No node.conn[0].iscsi.OFMarker = No [r...@localhost ~]# The above info is with the Oneway-CHAP. Let me know if you need any other info. Thx, Arvind. -Original Message- From: open-iscsi@googlegroups.com [mailto:open-is...@googlegroups.com] On Behalf Of Mike Christie Sent: Wednesday, January 28, 2009 3:31 PM To: open-iscsi@googlegroups.com Subject: Re: CHAP with Open-iSCSI Arvind Jain wrote: Mike, I have attached the wire shark trace for OneWay-CHAP and Mutual-CHAP. I am not sure how helpful this is. In case of OneWay-CHAP, Open-iscsi initiator does not continues with the login step and gives and error as follows: Logging in to [iface: default, target: iqn.2008-07.com.wasabi:osd.1, portal: 192.168.0.90,3260] iscsiadm: Could not login to [iface: default, target: iqn.2008-07.com.wasabi:osd.1, portal: 192.168.0.90,3260]: iscsiadm: initiator reported error (5 - encountered iSCSI login failure) Target discovery or login failed Could you give me the output of iscsiadm -m node -T iqn.2008-07.com.wasabi:osd.1 -p 192.168.0.90,3260 And could you run iscsid by hand with debugging and give me that output when you try to login # iscsid -d 8 -f will print it out to the console. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups open-iscsi group. To post to this group, send email to open-iscsi@googlegroups.com To unsubscribe from this group, send email to open-iscsi+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/open-iscsi -~--~~~~--~~--~--~--- [r...@localhost ~]# iscsid -d 8 -f iscsid: sysfs_init: sysfs_path='/sys' iscsid: sysfs_attr_get_value: open '/module/scsi_transport_iscsi'/'version' iscsid: sysfs_attr_get_value: new uncached
RE: MaxCmdSN not set after auto login
Mike. Thanks for quick response. Following are the answer to your questions: Q. When the initiator logs back in, is the target sending a MaxCmdSN and ExpCmdSn that indicates the window is smaller? A. Yes Q. Are you digging in the code by any chance? A. I did a bit. Need to look more. Q. Did you see if libiscsi.c:iscsi_update_cmdsn() is updateing the values correctly? A. Not yet. Will look deeper. Q. Could you send a ethereal/wrireshark trace? A. Yes. I will send it today. Thx, Arvind. -Original Message- From: open-iscsi@googlegroups.com [mailto:[EMAIL PROTECTED] On Behalf Of Mike Christie Sent: Friday, June 27, 2008 11:24 AM To: open-iscsi@googlegroups.com Subject: Re: MaxCmdSN not set after auto login Arvind wrote: During our testing with open-iscsi initiator, we discovered a minor issue related to MaxCmdSN. The MaxCmdSN is not re-populated after an automatic login occurs. This can make the initiators send more commands to the target exceeding the MaxCmdSN sent by the target in the Login Response. To reproduce the issue, do the following: 1.Start a Target with MaxCmdSN = ExpCmdSn + 15. 2.Start the open-iscsi initiator, login and run an application that sends at least 16 commands at time. 3.Stop the application. 4.Stop the target. 5.Recompile the target with MaxCmdSN = ExpCmdSn + 3 6.Start the target. 7.Initiator will automatically login to the target. When the initiator logs back in, is the target sending a MaxCmdSN and ExpCmdSn that indicates the window is smaller? Are you digging in the code by any chance? Did you see if libiscsi.c:iscsi_update_cmdsn() is updateing the values correctly? Could you send a ethereal/wrireshark trace? --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups open-iscsi group. To post to this group, send email to open-iscsi@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/open-iscsi -~--~~~~--~~--~--~---
RE: MaxCmdSN not set after auto login
Mike, After looking into the iSCSI spec again, I realized that target can't reduce the MaxCmdSN after the login has occurred. The iscsi_update_cmdsn() is fine. It is doing exactly what it is suppose to do. I guess, if the target does have to reduce the windows size, it can send an asynchronous logout and give a reduced window size when the initiator log back in. This will work fine with the patch that you provided. Thx, Arvind. -Original Message- From: open-iscsi@googlegroups.com [mailto:[EMAIL PROTECTED] On Behalf Of Mike Christie Sent: Friday, June 27, 2008 4:32 PM To: open-iscsi@googlegroups.com Subject: Re: MaxCmdSN not set after auto login Arvind Jain wrote: Mike, Thanks for the patch. I came to the same conclusion after looking into the function iscsi_update_cmdsn(). Perhaps, you could do the same thing for hdr-opcode == ISCSI_OP_NOOP_IN. This will allow the target to dynamically adjust the window size in case of a resource constraint when running multi-initiators. Thx, Arvind. So what are you guys actually sending in this case? The cmdsn definitions in 3.2.2.1 define what targets can do and how are supposed to process the values, but I am not sure what you guys are sending and how to then handle it wrt to the spec. Is iscsi_update_cmdsn busted or are you sending something weird? --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups open-iscsi group. To post to this group, send email to open-iscsi@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/open-iscsi -~--~~~~--~~--~--~---
