epan/dissectors/packet-umts_fp.c
* Added mac subdissector (MAC) call to HSDSCH TYPE2 frames
epan/dissectors/packet-umts_mac.c
* Added support for HSDSCH TYPE2 frames by means of
not nibble-shifting (4 bits) the SDU if MAC-ehs is used
epan/dissectors/packet-rlc.c
* Added support for "Use special value of the HE field" (3gpp 25.332-7a0
9.2.2.7) commonly used for Release 7 HSDPA.
REMARK: although the specification mandates that the
special value is only allowed when activated by higher
layers (RRC), it is interpreted unconditionally. We assume
this is OK, because a different use in future specifications
is very unlikely.
epan/dissectors/packet-fp_hint.c
* Added decoding of MAC-ehs indicator for HSDSCH frames
* Bumped fpi->release from 6 to 7 to enable proper
HSDSCH TYPE2 frame decoding in the UTMS MAC parser.
In general, this appears not to affect decoding
of (conformant) FP frames of pevious releases.
svn path=/trunk/; revision=34433
In some cases, the UMTS FP dissector currently calls upper-layer dissectors
(e.g. UMTS MAC) only when a proto-tree is present. Effectively, this causes the
RLC reassembly to fail in certain cases.
The attached patch solves the problem by slightly moving the calls to
'call_dissector()'.
svn path=/trunk/; revision=34399
(1) Trailing/leading spaces are removed from 'name's/'blurb's
(2) Duplicate 'blurb's are replaced with NULL
(3) Empty ("") 'blurb's are replaced with NULL
(4) BASE_NONE, NULL, 0x0 are used for 'display', 'strings' and 'bitmask' fields
for FT_NONE, FT_BYTES, FT_IPv4, FT_IPv6, FT_ABSOLUTE_TIME, FT_RELATIVE_TIME,
FT_PROTOCOL, FT_STRING and FT_STRINGZ field types
(5) Only allow non-zero value for 'display' if 'bitmask' is non-zero
svn path=/trunk/; revision=28770
(sorry about the build breakage, these new message formats will be tested soon
and it looks like I forgot to compile-test the last change I made...).
svn path=/trunk/; revision=25220
(where the initial length isn't readily available when item is first added)
Note that this still won't work where an initial length of 0 is given for
the item that will later be extended using proto_item_set_len(), as the
pointer value part of the zero-length array will reamin NULL...
svn path=/trunk/; revision=23253
Note that there is still a problem with 'Apply as filter' filters. They seem to remember the initial length of the item, and not the final length set using proto_item_set_len() (this is the case for groups of TBs/PDUs). Will investigate when time allows...
svn path=/trunk/; revision=23239
Martin Mathieson