Huge thanks to our Platinum Members Endace and LiveAction,
and our Silver Member Veeam, for supporting the Wireshark Foundation and project.

Wireshark-dev: Re: [Wireshark-dev] Invitation to discuss possible dissector for SCSI-OSD

From: "ronnie sahlberg" <ronniesahlberg@xxxxxxxxx>
Date: Sat, 30 Sep 2006 21:30:05 +0000
Hi,

There is an initial dissector for SCSI OSD in current SVN that
dissects some CDBs.

While implementing this i uncovered some flaws with the iscsi
dissector that did not handle AHS properly,   but it should work now.


There is still a bug in the iscsi dissector where it fails to
automatically detect that there is a HEADER DIGEST provided in the
PDU,   which leads to the dissector of DATA IN/OUT starting off at the
wrong offset (4 bytes to early).


I can not look into this HEADER DIGEST autodetection regression right
now  so for the time being I would suggest just focusing on the CDBs
and ignoring the DATA dissection.


I will look into why the autodetection doesnt work later.



A temporary workaround for this issue is to force the iscsi dissector
to always use crc32 header digests  which can be done by changing the
line (in packet-iscsi.c)

iscsi_session->header_digest=ISCSI_HEADER_DIGEST_AUTO;

into

iscsi_session->header_digest=ISCSI_HEADER_DIGEST_CRC32;





On 9/29/06, Joe Breher <linux@xxxxxxxxxxx> wrote:
Ronnie -

Some example traces should be in your personal inbox. I need to do some
checking to see whether I am at liberty to release them to the public at
large. I'll find some way to make that happen.

For those who may be following along:

I guess I've committed to the task of adding some SCSI-OSD-specific info
to the wiki. I've never edited a wiki before, so please be patient.

It sounds like Ronnie may be willing to at least advise me on design
decisions within the SCSI dissector - or perhaps even actively
contribute to the coding. Such would be very appreciated, as I do not
yet know where to start on this task.

ronnie sahlberg wrote:
> Hi,
>
> Since there are many opcodes in OSD that are from SPC I think the best
> solution would probably be to
> implement everything except opcode 0x7f in the existing dissector  and
> implement the OSD specific bits (opcode 0x7f)
> in a new packet-scsi-osd.c
>
>
> Adding an initial dissector for OSD that at least includes all the
> opcodes that are shared from SPC would be trivial and I can do that
> tonight.
>
>
> Do you have example captures with OSD traffic you can share?
>
>
>
>
> On 9/28/06, *Joe Breher* <linux@xxxxxxxxxxx
> <mailto:linux@xxxxxxxxxxx>> wrote:
>
>     With much embarrassment, I note that I neglected to change the Subject
>     of my last post (quoted herein). This reply should be near my last
>     post
>     in the digest, thereby hopefully eliminating some confusion.
>
>     Joe Breher wrote:
>     > ronnie sahlberg wrote:
>     >
>     >> Please do so. It would be very nice to add one more transport
>     for our
>     >> SCSI dissector.
>     >>
>     >>
>     > Ronnie (et al) -
>     >
>     > It may be time for me to go public with the reason for my desire to
>     > become involved with wireshark development. In essence, I am in
>     need of
>     > a dissector for SCSI-OSD. This is an INCITS T10 Technical Committee
>     > ratified Standard for a command set for Object-based Storage
>     Devices.
>     > This is a full command layer as SBC, SMC, etc, that are already
>     > supported in the wireshark SCSI dissector.
>     >
>     > I still am not familiar enough with the wireshark SCSI dissector
>     code to
>     > have opinions on the matter. Accordingly, now is probably an
>     opportune
>     > time for discussion ;-).
>     >
>     > It is unclear to me at this point whether it makes more sense to
>     extend
>     > the current SCSI dissector, or to develop a new one for OSD. I'd
>     like to
>     > extend the current one. However, there are several unique
>     challenges in
>     > OSD that do not exist in any of the command sets that the current
>     > dissector in packet-scsi.c currently handles. Among these are :
>     > - Variable Length CDBs
>     > - 'opcode' is x7F for all commands - the 'effective opcode' is
>     actually
>     > a two-byte Service Action in bytes CDB[9..8]
>     > - bidirectional data transfers - Data In *and* Data Out 'phases'
>     ('IUs',
>     > 'PDUs', whatever) during the execution of a *single* command.
>     > the list goes on.
>     >
>     > I would love to hear from anyone who either has an interest in these
>     > aspects of SCSI, or has insight into the design decisions behind the
>     > current SCSI dissector.
>     > _______________________________________________
>     > Wireshark-dev mailing list
>     > Wireshark-dev@xxxxxxxxxxxxx <mailto:Wireshark-dev@xxxxxxxxxxxxx>
>     > http://www.wireshark.org/mailman/listinfo/wireshark-dev
>     <http://www.wireshark.org/mailman/listinfo/wireshark-dev>
>     >
>
>     _______________________________________________
>     Wireshark-dev mailing list
>     Wireshark-dev@xxxxxxxxxxxxx <mailto:Wireshark-dev@xxxxxxxxxxxxx>
>     http://www.wireshark.org/mailman/listinfo/wireshark-dev
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> Wireshark-dev mailing list
> Wireshark-dev@xxxxxxxxxxxxx
> http://www.wireshark.org/mailman/listinfo/wireshark-dev
>

_______________________________________________
Wireshark-dev mailing list
Wireshark-dev@xxxxxxxxxxxxx
http://www.wireshark.org/mailman/listinfo/wireshark-dev