Subject: [Ips] Micorsoft ISNS server : Source attribute

From: Ravi Wijayaratne <[email-masked]>
Date: Thu, 29 Apr 2004 16:08:41 -0700 (PDT)

Hi Joe,

I was testing the Micorsoft ISNS Server and am puzzled by the following 
behaviors I observe. This behavior is relavant to mitzels postings in

https://www1.ietf.org/mail-archive/working-groups/ips/current/msg00425.html

>From Joes statement in that email I gether that the Sourc attribute must be
any storage node already registered under the entity.

1. so initially I have 2 ISCSI disks iqn.hstname1.disk0 and iqn.hstname.dsk1.
I register the entity and the nodes as follows
Source attr: iqn.hstname1.disk0 
op attrs:
<and other things >
iqn.hstname1.disk0 and iqn.hstname.disk1

The registration with the micorsoft ISNS server succeeds

2. Now I delete the disk0 and the deregister PDU looks the following
Source attr: iqn.hstname1.disk0
op attrs:
iqn.hstname1.disk0

The deregistration succeeds

3. Now I recreate iqn.hstname1.dsk0 and re register the disk 

source attr:iqn.hstname1.disk0
op attrs:
iqn.hstname1.disk0

The registration succeeds.

But when I try to login to iqn.hstname1.disk0 from the microsoft initiator the 
the login fails with the message 

"Invalid access to memory location" at the W2k box. I am pretty sure it is internal

I am guessing that we are corrupting the ISNS server database keys 
by doing the above operation. As long as we dont delete the target which
has the name which we chose for the source attributes we are fine. But the moment
we try to deregister that specific target out ISNS data base mappings get messed
up.

Are there any guide lines besides the standard (I am looking at draft-ietf-ips-isns-22.txt)
that gives us some guidelines about the contents of the source attribute field in the
ISNS PDU ? Is it right to say that microsoft has deviated from the standard by requiring 
the source attribute to be a registered or registering storage node of the network entity ?
I dont see such restrictions in the standard, I interpret it to be any string as long as it
uniquely identifies a network entity.

Some insight will be very useful. If you wish I will be happy to provide the ethereal traces

Thanks 
Ravi

=====
------------------------------
Ravi Wijayaratne

		
__________________________________
Do you Yahoo!?
Win a $20,000 Career Makeover at Yahoo! HotJobs  
http://hotjobs.sweepstakes.yahoo.com/careermakeover 

_______________________________________________
Ips mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ips

---

From: Joe Souza <[email-masked]>
Date: Fri, 30 Apr 2004 19:00:35 -0700 (PDT)

Hi Ravi,
 
I am no longer employed at Microsoft so I will not be able to help with the invalid memory access problem, but I can comment on the use of the Source Attribute and how the Microsoft iSNS server enforces this.  One question I have about this, though.  You state that this memory access error occurs on the "W2k box".  Is this machine running the iSCSI initiator or the iSNS server?  It is unclear in the email below.
 
Please read section 5.6.1 "Source Attribute" of the iSNS spec, especially the third paragraph.  This states that the Source Attribute identifies a Storage Node (not an Entity).  Also, the third paragraph defines the reason for the Microsoft iSNS server's enforcing of the Source Attribute.  It basically says that if a request is going to change the contents of the iSNS database, then this request must originate from a Node that belongs to the Entity that is being affected by the request.  Please let me know if this is not clear.
 
Thanks,
-Joe

Ravi Wijayaratne <[email-masked]> wrote:
Hi Joe,

Thanks 
Ravi

=====