I have checked in a fix for the header digest detection so it should
work now also for data in/out packets
it was simply that when trying to detect whether header digests were
used or not it assumed that all headers are always 48 bytes and
forgot to take into account the AHS.
this is fixed now.
On 9/30/06, ronnie sahlberg <ronniesahlberg@xxxxxxxxx> wrote:
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
>
