By running isnsd in the foreground with all debugging on (isnsd -f -d all)
I can see another difference.
When tgtd is stopped, isnsd logs "connection closed by peer, killing
socket",
switching isns in tgtd off doesn't give this message.
I tried searching through the tgtd isns code, but couldn't find the place
where the socket is actually closed. It looks like it is done implicitly
when tgtd closes.
If this is true I would suggest closing the socket to the isns server at
the end
of the "Off" section.
Albert
On 08/07/2010 09:51 AM, Albert Pauw wrote:
Looking at it using wireshark I noticed the following.
Deregistering by stopping tgtd gives the following handshake sequence:
tgtd -> isnsd: SCNDereg
tgtd -> isnsd: DeregDev
isnsd -> tgtd: SCNDeregRsp
isnsd -> tgtd: DeregDevRsp
Switching isns off in tgtd gives:
tgtd -> isnsd: SCNDereg
tgtd -> isnsd: DeregDev
isnsd -> tgtd: SCNDeregRsp
After which isnsd goes into a spin.
When looking at the DeregDev command send out by tgtd I see that the
start/stop version hands over the following payload:
iSCSI Name
Entity Identifier (aka IP address of target)
However, looking at the manual version (switching it off) I find the
following payload, which seems to choke isnsd:
iSCSI Name
Entity Identifier (aka IP address of target)
Entity Identifier (aka IP address of target)
Entity Protocol (iSCSI)
Portal IP Address (IPv6 format)
Portal Port
SCN Port
iSCSI Name
iSCSI Node Type (target)
From the isns rfc I find for the DeregDev command:
The DeregDev request message payload contains a single source
attribute (IP Address or Port Name) and key attributes (IP Address,
DNS Name& Path, Node Name or Port Name).
Which looks like the first (simpler) request would be the right one.
Of course isnsd shoudn't choke on it, but I think the isns code needs
a bit of a tweak here.
Albert
--
To unsubscribe from this list: send the line "unsubscribe stgt" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
