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 <[EMAIL PROTECTED]> 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* <[EMAIL PROTECTED] > > <mailto:[EMAIL PROTECTED]>> 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 > > > [email protected] <mailto:[email protected]> > > > http://www.wireshark.org/mailman/listinfo/wireshark-dev > > <http://www.wireshark.org/mailman/listinfo/wireshark-dev> > > > > > > > _______________________________________________ > > Wireshark-dev mailing list > > [email protected] <mailto:[email protected]> > > http://www.wireshark.org/mailman/listinfo/wireshark-dev > > > > > > ------------------------------------------------------------------------ > > > > _______________________________________________ > > Wireshark-dev mailing list > > [email protected] > > http://www.wireshark.org/mailman/listinfo/wireshark-dev > > > > _______________________________________________ > Wireshark-dev mailing list > [email protected] > http://www.wireshark.org/mailman/listinfo/wireshark-dev > _______________________________________________ Wireshark-dev mailing list [email protected] http://www.wireshark.org/mailman/listinfo/wireshark-dev
