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.
