Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 15 Oct 2021 16:04:48 +0000
From:      bugzilla-noreply@freebsd.org
To:        bugs@FreeBSD.org
Subject:   [Bug 259152] [iscsi] ExpDataSN mismatch in SCSI Response (unable to connect or authenticate to OCI oracle iscsi block devices)
Message-ID:  <bug-259152-227-iheXAwtJCY@https.bugs.freebsd.org/bugzilla/>
In-Reply-To: <bug-259152-227@https.bugs.freebsd.org/bugzilla/>
References:  <bug-259152-227@https.bugs.freebsd.org/bugzilla/>

next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D259152

John Baldwin <jhb@FreeBSD.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jhb@FreeBSD.org,
                   |                            |mav@FreeBSD.org,
                   |                            |trasz@FreeBSD.org

--- Comment #5 from John Baldwin <jhb@FreeBSD.org> ---
Please redo the packet capture with '-s 0'.  The SCSI response PDUs are in =
the
same packet as the Data-In but can't be seen in WireShark since the captured
packets are truncated.  Given the small number of packets involved, using '=
-s
0' should be ok without risk of dropping packets.

Note that since there is a Data-In, the ExpDataSN field should be 1 in the =
SCSI
Response.  It is a count of the Data-In PDUs sent in the reply to the origi=
nal
request prior to the SCSI Response PDU that closes it:

https://datatracker.ietf.org/doc/html/rfc7143#section-11.4.8

The error messages in comment #4 suggest a completely garbled connection, e=
.g.
if there are extra bytes in the stream that cause the client to read PDU
headers at the wrong offset.  'PDU 0x0' means that it thinks the opcode of =
the
PDU is 0 (NOP-Out).  However, NOP-out PDUs are only sent by the initiator
(client), not the target.

I wonder if OCI is using AHS (which isn't generally supported in FreeBSD's
iSCSI stack)?  A full pcap might help.

Oh, also, the LoginRespone shows 'iSCSIProtocolLevel=3DNot Understood" in t=
he
reply.  That may be ok though as that just means we can't use features from=
 RFC
7144 I think (reading in RFC 7144 which defines version 2 where as 7143 is
version 1).

--=20
You are receiving this mail because:
You are the assignee for the bug.=



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-259152-227-iheXAwtJCY>