The script didn't catch as many as I would have liked, but it's a start.
The most common (ab)use of proto_tree_add_uint_format was for appending strings to CRC/checksum values to note good or bad CRC/checksum.
svn path=/trunk/; revision=52045
was done using textual search+replace, not anything syntax-aware, so presumably
it got most comments as well (except where there were typos).
Use a consistent coding style, and make proper use of the WS_DLL_* defines.
Group the functions appropriately in the header.
I ended up getting rid of most of the explanatory comments since many of them
duplicated what was in the value_string.c file (and were out of sync with the
recent updates I made to those in r48633). Presumably most of the comments
should be in the .h file not the .c file, but there's enough churn ahead that
it's not worth fixing yet.
Part of https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=8467
svn path=/trunk/; revision=48634
Use a full 32-bit literal instead of just a 16-bit one. Fixes case where
the value we're &-ing with just slips over 2^16, making us get stuck
in an infinite loop.
I'm not sure this matches the iscsi spec anymore, the comment in the code
about padding bytes is ambiguous as to whether they're leading or trailing.
svn path=/trunk/; revision=45524
Dont implement the complex "extended logical unit addressing format" just
yet. That one is hairy so wait until we actually see it in the wild first.
Add decoding of LUNs using
single level lun structure and flat addressing space modes
svn path=/trunk/; revision=44058
(in some cases by changing proto_tree_add_item() to use
what appears to be the correct 'tree' arg);
Do whitespace cleanup.
svn path=/trunk/; revision=39772
1. If there's no character encoding (ENC_ASCII, ...) specified
then use ENC_ASCII.
2. For all but FT_UINT_STRING, always use ENC_NA
(replacing any existing True/1/FALSE/0
/ENC_BIG_ENDIAN/ENC_LITTLE_ENDIAN).
svn path=/trunk/; revision=39426
Specifically: Replace FALSE|0 and TRUE|1 by ENC_BIG_ENDIAN|ENC_LITTLE_ENDIAN as
the encoding parameter for proto_tree_add_item() calls which directly reference
an item in hf[] which has a type of:
FT_UINT8
FT_UINT16
FT_UINT24
FT_UINT32
FT_UINT64
FT_INT8
FT_INT16
FT_INT24
FT_INT32
FT_INT64
FT_FLOAT
FT_DOUBLE
svn path=/trunk/; revision=39288
FT_NONE
FT_BYTES
FT_IPV6
FT_IPXNET
FT_OID
Note: Encoding field set to ENC_NA only if the field was previously TRUE|FALSE|ENC_LITTLE_ENDIAN|ENC_BIG_ENDIAN
svn path=/trunk/; revision=39260
The standard iscsi dissector only recognizes iscsi traffic to and from port
3260 as specified. However, it doesn't understand traffic in MPIO/MCS
connections where the iscsi target runs on a range of ports (3260-3270 for
eg.); or rather it will ignore all iscsi traffic not on the specified port.
Attached patch adds ability to recognize iscsi traffic over a range of ports.
Default range is set to 3260-3260, so it behaves exactly like the current
dissector.
From me:
Don't surround a bunch of code in proto_register_iscsi() with braces just to
allow a new variable to be declared (without incurring the wrath of
non-C99-compliant compilers): just declare the variable at the top of the
function.
svn path=/trunk/; revision=38492
Use tvb_ip_to_str() and tvb_ip6_to_str().
There's no need to pass the result of tvb_get_ptr() as the 'value' in
proto_tree_add_*(): just use proto_tree_add_item().
Replace some tvb_get_ptr()s with tvb_get_ephemeral_string()s to ensure the
return string is NULL terminated.
svn path=/trunk/; revision=35546
port (3260).
add knowledge about the registered system port for iscsi to the heuristics
so we automatically detect when iscsi is transported over this optional port.
svn path=/trunk/; revision=32881
initiators to a different host/port and thus often redirect to non-3260.
The heuristics to detect iscsi is quite weak since there is very little
in the average iscsi header that can be used to semi-reliably identify
something as iscsi and not random data/something else.
As such, the heuristics also use/rely on the port being 3260 in order
to reduce the otherwise massive numbver of false positives that would arise.
Add decoding of the text key/value pairs and trigger on TargetAddress.
This field would describe a address/port where we can quite reliably
assume that this traffic is indeed iscsi and not something else.
When seeing the iscsi redirect/TargetAddress, use this as a signalling hint
and register a conversation dissector for TCP to that address/port so that
any future packet to/from this port is sent to the iscsi dissector.
If the signalling/redirect is not in the capture, wireshark will not detect
the traffic as iscsi and the user will have to use DecodeAs. and manually
\set it to iscsi.
svn path=/trunk/; revision=32595
