Donald,

                

Mike is talking about this fix from Dell that we submitted
http://groups.google.com/group/open-iscsi/browse_thread/thread/436ff294f
49d06df.

 

Thanks,

Shyam

 

From: open-iscsi@googlegroups.com [mailto:open-is...@googlegroups.com]
On Behalf Of Donald Williams
Sent: Wednesday, July 15, 2009 9:20 AM
To: open-iscsi@googlegroups.com
Subject: Re: iscsiadm -m iface + routing

 

Hi Mike, 

 

 Thanks for helping out.  When you say "Dell" fixed something, did you
mean Dell / Equallogic or another part of Dell?  I'm not aware of
anything Dell/EQL submitted but that doesn't mean anything. ;-) 

 

 What I'm seeing from the array logs are resets coming from the
initiator. 

 

SATA001:MgmtExec:13-Jul-2009
10:01:32.015700:targetAttr.cc:939:INFO:7.2.15:iSCSI session to target
'192.168.0.31:3260,
iqn.2001-05.com.equallogic:0-8a0906-23416c402-0b3000293644a537-test' f

rom initiator '192.168.0.39:50972, iqn.1994-05.com.redhat:561933d78489'
was closed.

        iSCSI initiator connection failure.

        Reset received on the connection.

 

The other message I see are these.   That haven't happened recently so
possibly after upgrading to the new iSCSI code helped a little. 

 

734030:720998:SATA001:MgmtExec:10-Jul-2009
08:07:53.973826:targetAttr.cc:939:INFO:7.2.15:iSCSI session to target
'192.168.0.31:3260,
iqn.2001-05.com.equallogic:0-8a0906-8a416c402-cbf0000b3414a3bc-ovm-1-l

un1' from initiator '192.168.0.154:35475,
iqn.1994-05.com.redhat:9693ecdf6c66' was closed.

        iSCSI initiator connection failure.

        Connection was closed by peer.

 

 So, CHAP is getting involved since connections are dropping then having
to re-login.   Why they are dropping in the first place is a mystery. 

 

  Everything else in the logs looks fine. 

 

On Tue, Jul 14, 2009 at 6:00 PM, Mike Christie <micha...@cs.wisc.edu>
wrote:


On 07/13/2009 09:20 AM, Hoot, Joseph wrote:
> Mike,
>
> Just as an FYI (in case you were most curious about this issue) I've
> narrowed this issue down to something with CHAP.  On my EqualLogic, if
I
> disable CHAP, I can't reproduce this issue.
>
> So I did the following.  I after upgrading to the latest OEL 5.3
release
> of the iscsi-initiator, I could still reproduce the problem.
Therefore,
> I did the following:
>
> 1) Setup another test environment using the same hardware (physical
> different hardware, but all same firmware, models, etc..)
> 2) presented a new test volume from EqualLogic
> 3) ran the ping test (ping -Ieth2 192.168.0.19&  ping -Ieth3
> 192.168.0.19).
> 4) I couldn't reproduce the issue.
> 5) I checked what the difference were-- CHAP the only difference.
> 6) So I turned on CHAP authentication to the volume.
> 7) rm -rf /var/lib/iscsi/nodes/* /var/lib/iscsi/send_targets/*
> 8) rediscovered targets (after modifying /etc/iscsi/iscsid.conf with
> CHAP information)
>
> node.session.auth.authmethod = CHAP
> node.session.auth.username = mychapuserhere
> node.session.auth.password = mypasshere
>
> 9) ran the same ping test and was able to get iscsi sessions to fail
> within 2 minutes.
> 10) I wanted to prove that CHAP was the issue. So I logout out of all
> iscsi sessions.
> 11) I disabled CHAP on the EqualLogic
> 12) rediscovery targets and re-logged in to the sessions (without CHAP
> authentication)
> 13) ran the ping tests and couldn't break it after 30 minutes.
> 14) added CHAP again and was able to break the sessions within 2
> minutes.
>
> So definitely something odd with CHAP (my guess, either in open-iscsi
> code or EqualLogic code).  I've asked Roger Lopez, from Dell, to
attempt
> to reproduce this in his lab.  He has EqualLogic and Oracle VM
Servers.
> Oracle developers that I'm working with don't currently have access to
> an EqualLogic, but they are attempting to reproduce this with their
> iSCSI equipment as well.  I'm going to setup port mirroring on our
> switch and run tcpdumps to see what I can get.
>

This is strange because CHAP does not come into play in the normal IO
path. When we login we will do authentication with CHAP, but after that
succeeds it nevers comes up when doing IO. It would only come up again
when the session/connection is dropped/disconnected and we relogin. For
the relogin we will do the CHAP authentication again.

Maybe some memory error where chap values are overwriting some other
memory.

There was one recent fix by Dell, where when using CHAP they could
segfault iscsid. Here is the updated RPM that I am working on for RHEL
5.4 that has the fix:

http://people.redhat.com/mchristi/iscsi/rhel5.4/iscsi-initiator-utils/

 

 




--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---

Reply via email to