C6297: Arithmetic overflow: 32-bit value is shifted, then cast to 64-bit value.
Results might not be an expected value
svn path=/trunk/; revision=54104
C6297: Arithmetic overflow: 32-bit value is shifted, then cast to 64-bit value. \
Results might not be an expected value
'offset++' --> 'offset += 1' for consistency;
Add/adjust whitespace;
Add editor modelines
svn path=/trunk/; revision=54102
Currently, the LLC dissector in packet-llc.c displays the values of DSAP IG bit
and SSAP CR bit as separate items in the proto tree. This gives an impression
that these entries are separate fields in the LLC header while in reality, they
are only the least significant bits in DSAP/SSAP octets. In addition, the
importance of these bits is relatively low in today's LLC-based protocols (they
are mostly set to 0), so having them always displayed in the proto tree is
somewhat of a luxury.
Modify the LLC dissector by having added a subtree to both DSAP and SSAP items
that displays the IG and CR bits as bits in a bitfield, and moved the display
of IG and CR bits into these subtrees.
It may seem that adding a text item instead of a FT_UINT8 value is not a
sensible approach because such item is not filterable. However, if filtering by
the entire DSAP/SSAP value (which is the typical way of filtering on SAPs), this
value is always added to the tree in its entirety and indexed by "llc.dsap" and
"llc.ssap" filter strings. If the GI or CR bit are to be matched, "llc.dsap.ig"
and "llc.ssap.cr" filter strings are available. Searching for the value of the
DSAP/SSAP & 0xFE which would be the value currently added by the
proto_tree_add_text() is not done and should not be done, as IEEE stipulates:
"An individual actual address value does not necessarily have any relationship
with a group address of the same actual address value."
(http://standards.ieee.org/develop/regauth/tut/llc.pdf) Following this
consideration, the choice of displaying the SAP "actual address" using
proto_tree_add_text() is acceptable.
svn path=/trunk/; revision=54091
descriptors.
Make sure the length in string descriptors is at least 2, so that we
have a valid string or string-list length.
svn path=/trunk/; revision=54084
longer than the maximum possible amount to read based on the format string. For
this reason, don't use sscanf on tvb_get_ptr directly, copy and null-terminate
the bytes we want.
Fixes an uninitialized value caught by valgrind fuzzing.
svn path=/trunk/; revision=54082
spotlight_get_utf16_string_byte_order(), and have it return
ENC_BIG_ENDIAN or ENC_LITTLE_ENDIAN if it finds a BOM and 0xFFFFFFFF if
it doesn't, to make it a bit clearer what it's doing.
Use tvb_get_string_enc() rather than tvb_get_unicode_string().
svn path=/trunk/; revision=54075
- set pinfo->p2p_dir based on portid
- check for nlmsg type in dissect_netlink_sock_diag()
- sock diag support LINUX_AF_INET6, LINUX_AF_PACKET
- naming cleanup
svn path=/trunk/; revision=54073
encoding for ISO 8859-1; this means that those strings won't be
correctly interpreted if they're interpreted as UTF-8.
svn path=/trunk/; revision=54069
- Display of header bit fields was incorrect;
- Computation of the data length was incorrect;
- Display of trailer 'indicator enable' & 'indicator' bit fields was incorrect;
- 'Display' field of certain hf[] entries was incorrect.
- Pedantic: Use ENC_BIG_ENDIAN instead of ENC_NA in certain places.
See Bug #9539https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=9539
svn path=/trunk/; revision=54067
C6385: Invalid data: accessing 'dgt->out', the readable size is '15' bytes, but '18' bytes might be read
Also: Do some trivial whitespace and formatting changes.
svn path=/trunk/; revision=54048
value_string.c: value_string_ext_validate() always fails on Windows
when called from a different DLL (i.e. a plugin).
So: Add #ifndef _WIN32 around the offending code.
svn path=/trunk/; revision=54047
Cosmetic change in a LF field representation in the RTPproxy dissector
Don't display any value for LF field
Signed-off-by: Peter Lemenkov <lemenkov@gmail.com>
svn path=/trunk/; revision=54045
DLTS: add cipher version for OpenSSL pre 0.9.8f
OpenSSL pre 0.9.8f uses the TLS version 0x0100 and is not completely
compatible with DTLS 1.0 or 1.2. One difference is that the encrypted
pre master from TLS 1.0 does not have an own length, which is needed by
TLS and DTLS 1.0, this makes decrypting impossible. This patch makes it
possible for the code to distinguish between this OpenSSL version and
real DTLS 1.0, because they are not using the same code any more. This
is needed to fix the snakeoil-dtls test.
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
svn path=/trunk/; revision=54043
ssl-utils: remove SIG, rename mode and formatting
The changes seem huge, but actually involve a few structural changes
that do not change functionality, but aim to make maintenance easier and
lines shorter. The following changes were made:
1. Remove the "sig" field and `SIG_*` constants as they are not used
anywhere.
2. Convert `SSL_CIPHER_MODE_*` macros to an enum, change the type in
SslCipherSuite, change the field terminator in cipher_suites and
drop the `SSL_CIPHER_` prefix to make it shorter.
3. Add whitespace to align the cipher suites and convert the numbers to
hex to match common usage (e.g. IANA docs). Done with the awk script
below.
AWK script that takes the lines with `,KEX_` and applies changes (3):
#!/usr/bin/gawk -f
BEGIN { FS="[, {]+" }
{
split($0, c, "}, *");
comment="";if(c[2])comment=" "c[2];
sub("}", "", $10); # comment }
printf(" {0x%04X,%-12s%-16s%2d,%3d,%3d,%-11s %-22s},%s\n",
strtonum($2),
$3 ",", # Key exchange
# $4 is SIG_ - remove
$5 ",", # Cipher
$6, # blocksize
$7, # keysize
$8, # export keysize
$9 ",", # Digest
$10, # mode
comment);
}
Signed-off-by: Peter Wu <lekensteyn@gmail.com>
svn path=/trunk/; revision=54039
C6297: Arithmetic overflow: 32-bit value is shifted, then cast to 64-bit value. Results might not be an expected value
svn path=/trunk/; revision=54019
C6297: Arithmetic overflow: 32-bit value is shifted, then cast to 64-bit value. \
Results might not be an expected value
svn path=/trunk/; revision=54011