Wireshark-bugs: [Wireshark-bugs] [Bug 8832] New: patch: add support for OSD-2/3 in the SCSI diss
| Bug ID |
8832
|
| Summary |
patch: add support for OSD-2/3 in the SCSI dissector
|
| Classification |
Unclassified
|
| Product |
Wireshark
|
| Version |
SVN
|
| Hardware |
All
|
| OS |
All
|
| Status |
UNCONFIRMED
|
| Severity |
Normal
|
| Priority |
Low
|
| Component |
Dissection engine (libwireshark)
|
| Assignee |
bugzilla-admin@wireshark.org
|
| Reporter |
uce@rjgodoy.com.ar
|
Created attachment 11037 [details]
patch
Build Information:
Version 1.10.0 (SVN Rev 49790 from /trunk-1.10)
iSCSI/SCSI dissectors from revision 50081
Patch from bug 8803 (optional, if that patch is not applied reassembling should
be disabled)
--
OSD-2/3 obsoletes service actions codes assigned by OSD-1, and redefines the
same service actions with a different code (which is usually the former code
ORed with 0x80).
There are many similarities between OSD-2 and OSD-1, but there are also some
differences (CDB continuation, parameter list formats, use of reserved fields,
etc) that have to be handled for each case (e.g. one would not want OSD-2
specific fields in OSD-1 CDBs, and vice-versa).
In this patch, a single OSD-2 service action (LIST 0x8883) was implemented.
This patch is a bit large because it deals with several structures that are
reused by other OSD-2 service actions (and most changes did not make sense
unless they were integrated in the dissector function). It is expected that
future patches will be smaller.
For "overloading" OSD-1 and OSD-2/3 dissection, the same dissector function is
used for both 0x8803 (OSD-1 LIST) and 0x8883. This is necessary because
sometimes the difference between versions is only of a few lines.
For convenience, a variable "osd2" was made available in extra_data (that
variable is initialized as 0 in dissect_osd_opcode).
Whenever each version requires different processing, the following pattern is
applied:
gboolean osd2 = ((scsi_osd_extra_data_t *)cdata->itlq->extra_data)->osd2;
/*dissect common fields*/
if (osd2) {
/*dissect OSD-2 specific field*/
} else {
/*dissect OSD-1 specific field*/
}
/*dissect common fields*/
The dissector funcion for an OSD-2 service action (e.g. dissect_osd_list)
begins with the following assignment
gboolean osd2 = ((scsi_osd_extra_data_t
*)cdata->itlq->extra_data)->svcaction&0x80;
((scsi_osd_extra_data_t *)cdata->itlq->extra_data)->osd2=osd2;
Since OSD-1 fields are reused, a field in an OSD-1 CDB may be assigned with a
value defined in OSD-2 (e.g. GET/SET CDBFMT 1h), or a field in an OSD-2/3 CDB
may be assigned with an obsolete value from OSD-1, and that would go unnoticed.
Since they are invalid CDB, I'm not addressing this concern, but any interested
party might add warnings and checks if required.
There are no nasty consequences of this reuse, because of T10's careful
management of reserved and obsoleted entries (even if there were nasty
consequences, one could add version-specific processing for each version).
Security parameters have the same format in all versions.
Capability parameters are only dissected if their format is 1h (used by OSD-1).
OSD-2/3 uses capability format 2h, and I haven't analyzed which changes are
required.
Document references:
OSD-1r10
OSD-2r4 (the published standard is OSD-2r5)
OSD-3r2 (http://www.t10.org/cgi-bin/ac.pl?t=f&f=osd3r02.pdf)
The following service action codes were #defined
OSD_2_CREATE 0x8882
OSD_2_LIST 0x8883
OSD_2_READ 0x8885
OSD_2_WRITE 0x8886
OSD_2_APPEND 0x8887
OSD_2_CLEAR 0x8889
OSD_2_REMOVE 0x888A
OSD_2_GET_ATTRIBUTES 0x888E
OSD_2_SET_ATTRIBUTES 0x888F
OSD_2_CREATE_AND_WRITE 0x8892
OSD_2_COPY_USER_OBJECTS 0x8893
OSD_2_CREATE_USER_TRACKING_COLLECTION 0x8894
OSD_2_REMOVE_COLLECTION 0x8896
OSD_2_LIST_COLLECTION 0x8897
OSD_2_QUERY 0x88A0
OSD_2_REMOVE_MEMBER_OBJECTS 0x88A1
OSD_2_GET_MEMBER_ATTRIBUTES 0x88A2
OSD_2_SET_MEMBER_ATTRIBUTES 0x88A3
The following helper functions were added:
- dissect_osd_isolation
- dissect_osd_immed_tr
- dissect_osd_list_attr
- dissect_osd2_attribute_list_entry (OSD2 Table 229)
- dissect_osd_attribute_value (code from dissect_osd_attributes_list,
reused by dissect_osd2_attribute_list_entry)
- dissect_osd_offset (dissects a CDB offset field. Version specific
processing is needed because OSD-2/3 specifies that the offset is a signed
integer, while OSD-1 does not.)
The following fields were added:
- hf_scsi_osd_set_attribute_value
- hf_scsi_osd_isolation
- hf_scsi_osd_immed_tr
- hf_scsi_osd_list_attr
- hf_scsi_osd_object_descriptor_format
The following value_string arrays were added:
- scsi_osd_isolation_val (OSD2 table 162)
- scsi_osd_object_descriptor_format_val (OSD2 table 108)
The following value_string arrays were updated:
- scsi_osd_svcaction_vals (OSD2 table 80)
- scsi_osd_getsetattrib_vals (OSD2 table 61)
Changes in dissect_osd_attribute_parameters
- Modified the function signature
- A case for "Set one attribute using CDB fields" (gsatype==1) was added in
dissect_osd_attribute_parameters. That case is only executed if osd2 is true.
- If gsatype==3 the offset is decoded by dissect_osd_offset
Changes in dissect_osd_attributes_list
- Modified the function signature
- Add OSD-2 specific processing for list header and list type 0x09
Additional change: (initialize extra_data even if flags.visited is true)
- itlq->extra_data is initialized if((!pinfo->fd->flags.visited) &&
(!cdata->itlq->extra_data))
+ itlq->extra_data is initialized if((!pinfo->fd->flags.visited) ||
(!cdata->itlq->extra_data))
Changes related to OSD-1:
=> The options byte is no longer dissected. The basic CDB structure defines
the byte at offset 10 as "options byte", but that byte is reserved in LIST
(8803h) command CDB.
=> dissect_osd_attributes_list reuses dissect_osd_attribute_value
=> Decode hf_scsi_osd_set_attributes_list_offset. It was reported as a wire
value (binary encoding of mantissa and exponent), while other offsets were
decoded.
=> dissect_osd_attributes_list: if offset is 0xFFFFFFFF set length to 0
Disclaimer: the example was taken from a software target that I'm developing,
there may be some differences with respect to the actual OSD-2 format, but I
think it is fine.
You are receiving this mail because:
- You are watching all bug changes.
