Re: [Iscsitarget-devel] IET - jSCSI Initiator

[Arne R. <arn...@go...>]

2012/6/25 Andreas Rain <and...@un...>:
> So I have used wireshark now. A detailed log follows (it's just a small view
> on 7 packets but still quite big, I hope not too big):

Please send the capture file (raw file, not a text dump) next time instead.

<snip>

> SCSI: SNS Info
>     [LUN: 0x0000]
>     Valid: 1
>     .111 0000 = SNS Error Type: Current Error (0x70)
>     Filemark: 0, EOM: 0, ILI: 0
>     .... 0110 = Sense Key: Unit Attention (0x06)
>     Sense Info: 0x00000000
>     Additional Sense Length: 6
>     Command-Specific Information: 00000000
>     Additional Sense Code+Qualifier: Power On, Reset, Or Bus Device Reset
> Occurred (0x2900)
>     Field Replaceable Unit Code: 0x00
>     0... .... = SKSV: False
>     Sense Key Specific: 000000
>
> But as you said it might be already cleared? What would that mean? That we
> can't ask for capacity information (this way) after the login response has
> come in?

That means that the initiator code needs to be aware of unit attention
conditions and it also needs to be able to handle them. In that
particular case the READ CAPACITY will succeed if the request is
retried (and no error creeps in).
On a related note: initiators typically do a little inspection of the
target they're connected to by using TEST UNIT READY, different
flavours of INQUIRY and REPORT LUNS to figure out some details about
the logical units attached to the target and their health.

I'd recommend looking at wireshark captures of other initiators (MS
iSCSI initiator, open-iscsi).

Cheers,
Arne

>
> Am 25.06.2012 13:17, schrieb Arne Redlich:
>
> 2012/6/25 Andreas Rain <and...@un...>:
>
> Hello Arne,
>
> Thank you for answering so quickly.
>
> I just found out that the IET sends the Response using the Status Code
> CHECK_CONDITION which implies that an error occured.
>
> Not necessarily an error. The unit attention mentioned in my previous
> mail is also reported this way (the details are in the SCSI sense data
> in the SCSI response). Once IET reported the unit attention condition
> it is automatically cleared.
>
> I'm installing wireshark right now and I'm going to send the resulting data
> as soon as it runs.
> What do you mean by "cleared first". Does it mean that there is more to the
> authentification?
>
> No, this has nothing to do with the iSCSI login, it's a SCSI mechanism
> - you can find details about that in the SAM-2 (or higher) SCSI specs.
>
> HTH,
> Arne
>
> I have set no parameters in my configuration to indicate a more complex
> authentification.
>
> Best regards,
> Andreas
>
> Am 25.06.2012 12:55, schrieb Arne Redlich:
>
> Hi Andreas,
>
> 2012/6/25 Andreas Rain <and...@un...>:
>
> Hello Everyone,
>
> I am currently working on the jSCSI - Project (which provides a java
> version of an initiator and a target).
> For some reason the jSCSI Initiator doesn't work with IET on Ubuntu
> anymore since versions over 0.4.x.
>
> So what I found out so far is,
>
> that after the Login Negotiation our Initiator sends SCSICommand to the
> Target which looks likes this:
>
>   ImmediateFlag: false
>   OpCode: 0x1
>   FinalFlag: true
>   TotalAHSLength: 0x0
>   DataSegmentLength: 0x0
>   InitiatorTaskTag: 0x0
>   LUN: 0x0
>   Expected Data Transfer Length: 0x8
>   CommandSequenceNumber: 0x0
>   ExpectedStatusSequenceNumber: 0x0
>   SCSI CDB: java.nio.HeapByteBuffer[pos=0 lim=16 cap=16]
>
> It expects the Target to answer first with a Data-In which describes the
> devices size and block size in the datasegment. After that it expects
> that Target to give a SCSIResponse.
>
> With version 0.4.x our initiator works fine, but now we're getting a
> SCSIResponse directly after sending this command.
> The SCSIResponse looks like this:
>
> Just a wild guess: IET establishes a "power-on reset" unit attention,
> i.e. that one needs to be cleared first (and initiators need to be
> able to cope with that). Can you check the SCSI requests / responses
> with wireshark? Unless that solves the issue, please send a capture of
> the iSCSI traffic.
>
> HTH,
> Arne
>
> ImmediateFlag: false
>   OpCode: 0x21
>   FinalFlag: true
>   TotalAHSLength: 0x0
>   DataSegmentLength: 0x14
>   InitiatorTaskTag: 0x1
>   Response: 0x0
>   SNACK TAG: 0x0
>   StatusSequenceNumber: 0x1
>   ExpectedCommandSequenceNumber: 0x1
>   MaximumCommandSequenceNumber: 0x21
>   ExpDataSN: 0x0
>   Bidirectional Read Residual Count: 0x0
>
>
> As you can see the DataSegmentLength also varies from the (in the
> command set) expected data transfer length. I am fairly new to this
> which is why I don't know on what parameters in form of bytes which
> response is given. I hope this is enough information. I have a bigger
> log which I can supply if you're asking for it.
>
> Best regards,
> Andreas
>
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> Iscsitarget-devel mailing list
> Isc...@li...
> https://lists.sourceforge.net/lists/listinfo/iscsitarget-devel
>
>
>
>