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
