From Yuri Schaeffer
It addresses the following issues:
- Payload was included for all CAPPACKET messages. Even when not flagged by bitmap (bug).
- Frame Checksum (FCS) was not read from bitmap all following data is off by 4. (bug)
- Headers indicated in bitmap could use own subtree
- Payload is malformed because it is assumed the span 'the rest of the packet'. In reality more commands can follow. (bug)
svn path=/trunk/; revision=50228
Rename the "is_int" argument to fill_label_number() to make it clearer
what it indicates, i.e. whether the number is signed or unsigned.
svn path=/trunk/; revision=50224
AC_WIRESHARK_COMPILER_FLAGS_CHECK, because it doesn't just affect CFLAGS
and it doesn't just affect the flags for GCC.
svn path=/trunk/; revision=50222
flags, if the option should be added to the flags for both C and C++,
test both the C and C++ compilers and, if the answers are different,
print a warning; the user might have (intentionally or unintentionally)
selected mismatched compilers, e.g. clang and g++ on OS X.
svn path=/trunk/; revision=50219
that it doesn't fail due to the C++ compiler not supporting -W options
that the C compiler does.
(We should fix that, too, by having separate checks for whether the C
and C++ compilers support particular options.)
svn path=/trunk/; revision=50215
The attached patch fixes the integer type of the WCCP identity mask value.
This is a bitmask which should be printed as hex, it doesn't make sense to
print it as an IPv4 address. See
http://tools.ietf.org/id/draft-wilson-wrec-wccp-v2-01.txt section 5.7.7 and
the attached capture file as an example.
The current draft http://tools.ietf.org/html/draft-mclaggan-wccp-v2rev1-00#section-6.15
doesn't mention "mask" in the names of the field any more, but the description
still describes them as mask values.
svn path=/trunk/; revision=50211
The I and R flags in Map-Notify LISP control packets are shown at an incorrect
position. The attached patch fixes the bug.
svn path=/trunk/; revision=50210
Added a "subtree context" structure to asn1_ctx_t. This should allow other ASN.1 dissector global variables to be replaced when only used for transferring data between fields in a subtree.
svn path=/trunk/; revision=50208
Recent versions of GlusterFS have extended the RPC protocol with new
procedures. The RPC-program-version has not been updated (yet?).
The attached adds support dissecting the FREMOVEXATTR, FALLOCATE and
DISCARD procedures.
svn path=/trunk/; revision=50207
C++ compiler (it might not be one on, for example, OS X, due to "cc"
being a C compiler, "CC" referring to "cc" due to the case-insensitivity
of the default OS X file system, and "CC" being one of the names checked
for in AC_PROG_CXX), so if we really need a C++ compiler, test it with a
program that a C compiler won't compile.
svn path=/trunk/; revision=50204
https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=8718
More zigbee dissection, adding the following clusters:
- appliance identification
- meter identification
- appliance statistics
- appliance events and alert
svn path=/trunk/; revision=50202
on a Mac, right? So of *COURSE* you want to use our shiny new frameworks
rather than those ugly old open-source multi-platform libraries, right?"
warnings.
svn path=/trunk/; revision=50200
Create generic int/uint fill functions from hfinfo_[u]int_value_format.
XXX: to be honest I don't get it why if dev picked up BASE_DEC_HEX and has value string we're truncating it to BASE_DEC...
svn path=/trunk/; revision=50197
... as per the XXX comment removed from tshark.c this was a mess to keep the linker
happy... I couldn't!
I did this without even understanding whether calling main_window_update was realy
necessary in most cases. I guess nothing or more specific update cbs would be best.
svn path=/trunk/; revision=50188
bugs it points out that probably mean the code won't work on machines
that require alignment (e.g., SPARC machines), but we'll turn it on once
we fix them. (clang is fussier than GCC about this.)
svn path=/trunk/; revision=50187
From the comment above wmem_tree_insert32_array():
* If you use ...32_array() calls you MUST make sure that every single node
* you add to a specific tree always has a key of exactly the same number of
* keylen words or things will most likely crash. Or at least that every single
* item that sits behind the same top level node always have exactly the same
* number of words.
So clearly generating thousands of keys with random lengths while testing is
going to cause problems. Generate a set of random lengths, then use those
lengths consistently (but still generating random keys of those lengths).
Should hopefully fix the intermittent build-bot failures.
(unfortunately this does not manifest nicely, and I cannot see an easy way to
assert it so that we catch other people trying to use different-length key
subtrees)
svn path=/trunk/; revision=50184
According to ETSI TS 102 771 (GSE implementation guidelines), "mandatory extension headers" - when GSE's protocol type field is (strictly) less than 256 (0x100) - are of 'pre-defined length (and format) that must be known by all GSE receivers'.
svn path=/trunk/; revision=50180
an error, or not issue warnings, by default if you give them an unknown
-f flag. Instead, test that flag with all compilers, and use -Werror to
force it to error out.
As with C/C++ flags, so with C++-only flags.
svn path=/trunk/; revision=50178
Michael Mann