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
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
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
From Jiří Engelthaler
1) Wrong bits definitions for SIQ.BL, SIQ.SB, SIQ.NT, SIQ.IV, QDS.BL, QDS.SB, QDS.NT, QDS.IV
2) Invalid field abbrev for VTI Transient
3) Wrong bit size for SCO.QU, DCO.QU, RCO.QU
4) Changes from BASE_DEC to BASE_HEX
5) Several code style changes
svn path=/trunk/; revision=50145
Put in a whole bunch of stderr output in the wmem tree tests in the hopes that
the next time one of the buildbots randomly (and irreproducibly) fails on this
step we'll have at least a bit of a hint as to where it happened.
svn path=/trunk/; revision=50131
Added support for VHT TPE IE and also tested it
Also fixed a small typo from "IEEE Stc" to "IEEE Std" for all 802.11ac references.
From me:
* Remove some trailing whitespace
* Fix bitmask PWR Info Unit
* Modify expert_info to display error in PWR Info Count
* Fix (possibility) loop
* Fix value_string (not need to have Reserved...)
svn path=/trunk/; revision=50123
We should deprecate the use of hidden fields, at least for fields that arei
useful in filters. To make it easier for users to discover and use the fields.
Change the highly useful field for TCP segment payload length from
being a hidden field to be a generated field instead.
svn path=/trunk/; revision=50112
request for implicit conversion from 'gpointer' to 'char *' not permitted
in C++ [-Werror=c++-compat]
and
enum conversion when passing argument 3 of 'krb5_crypto_init' is invalid
in C++ [-Werror=c++-compat]
svn path=/trunk/; revision=50108
human-readable representing an AX.25 subaddress (e.g. "KA9Q-01") into
the binary form of an AX.25 address, because what it does is translate
the binary form of an AX.25 address to the human-readable form!
We currently have no routine that does the right thing and, even if we
did, given that some bits in the AX.25 subaddress format are used for
purposes other than representing the call sign and substation ID, so the
matching routines for AX.25 addresses need to ignore certain bits.
For now, we just remove the call to get_ax25_name() (which squelches the
pointer-signedness warning that made me look at this code, and find the
problem, in the first place) and replace it with a comment discussing
the problem and a failure.
The other pointer-signedness warning brought up a question of what to do
with G_REGEX_RAW in the g_regex_match_full() call; it didn't bring up an
immediately obvious *answer*, so we throw a cast at the warning and add
another comment. (We fix up alignment while we're at it.)
svn path=/trunk/; revision=50106
when the last comment is removed and we have no other expert info,
the maximum severity is changed from comment to none
svn path=/trunk/; revision=50091
Within BGP Update message for BGP VPLS (RFC 4761) some parts of Extended Community "Layer2 Info" are incorrectly decoded:
1. Encapsulation - Unknown (0x13). Per RFC 4761 encap type 0x13 is "VPLS" (clause 3.2.4);
2. Control Flags - per RFC 4761 (clause 3.2.4) two least-significant bits (6 and 7) are defined as:
"C" (bit 6, Control Word): value 1 - Control Word is required - and value 0 - Control Word is not required; decoding is correct (at least for value 0);
"S" (bit 7, Sequence delivery): value 1 - Sequence delivery is required - and value 0 - Sequence delivery is not required; decoding is incorrect, because for value 0 (sequence delivery is not required) you provide description that "Sequence delivery is required".
Also, there is description (at the same string) "F Flag (reserved) set. IETF document draft-ietf-l2vpn-vpls-multihoming (clause 3.3.1) updates RFC 4761 and defines two additional bits within Control Flags byte - D (bit 0, "Down") and F (bit 2, "Flush"). You provide description that "F Flag (reserved) set" when this flag actually is not set (value 0). Furthermore, you don't provide description about status of flag D (in attached dump in the first packet flag D is set and unset in the second packet).
svn path=/trunk/; revision=50085
Evan Huus