like:
udp.srcport == udp.dstport
frame.cap_len != frame.len
(probably you can use it for better ones)
part of bug #7263
svn path=/trunk/; revision=43069
in README.devloper. Remove g_gnuc.h since it's no longer needed. Remove
tvbuff_init(), tvbuff_cleanup(), reassemble_init(), and
reassemble_cleanup() since they were only used for older GLib versions
which didn't support GSlices. Assume we always support the "matches"
operator.
svn path=/trunk/; revision=37978
make FT_STRING and FT_UINT_STRING handle string encodings.
Get rid of FT_EBCDIC in favor of FT_STRING with ENC_EBCDIC.
Add some URLs for DRDA.
Clean up some stuff in TN3270 and TN5250, including using ENC_ values
for proto_tree_add_item().
svn path=/trunk/; revision=37909
* Remove proto_tree_add_eui64 function from 802.15.4 Dissector
* Replace print_eui64/print_eui64 by eui64_to_str/get_eui64_name
* Update Documentation (README.dev)
* Add new function in libwireshark.def
* Support of encoding for tvb_eui64_to_str
* Use FT_EUI64 for ICMPv6, CAPWAP, Zbee ... dissector
svn path=/trunk/; revision=37015
In semcheck.c the display filter string of an expression is checked against the
header_field_info.display value BASE_CUSTOM. But the value of BASE_CUSTOM is
applied as bitmask while the actual type is an enum (BASE_CUSTOM = 6).
With this BASE_DEC, BASE_DEC_HEX and BASE_HEX_DEC are also matching and are not
accepted as filter expression.
Actually: BASE_DEC works but not BASE_HEX. And the problem only shows up when
trying to match a field in one of these bases against a string (from a
value_string).
svn path=/trunk/; revision=35621
- Allow direct access when a range of values begins with a value other than 0;
- Provide value_string_ext_new() for creating extended value strings at runtime;
- Do access to value_string_ext members via a macro (all but value_string.c);
- Update documentation.
svn path=/trunk/; revision=34514
(plus some additional changes by me).
Handle BASE_RANGE_STRING display types properly
We always treat header field info strings as value_string's undiscriminated.
However, if the header field info display is marked as BASE_RANGE_STRING, we
need to treat them as range_string's. This wasn't properly handled in the
filter expression dialog and in the filter toolbar which would cause a crash
upon referencing any fields marked as BASE_RANGE_STRING.
svn path=/trunk/; revision=28931
Try to resolve a crash issue when having a function on the RHS
of a filter test which does not return the same type as the LHS.
svn path=/trunk/; revision=28550
est. Use g_ascii_strcasecmp() and g_ascii_strncasecmp(), and supply our
own versions if they're missing from GLib (as is the case with GLib
1.x).
In the code to build the list of named fields for Diameter, don't use
g_strdown(); do our own g_ascii_-style upper-case to lower-case mapping
in the hash function and use g_ascii_strcasecmp() in the compare
function.
We do this because there is no guarantee that toupper(), tolower(), and
functions that use them will, for example, map between "I" and "i" in
all locales; in Turkish locales, for example, there are, in both
upper case and lower case, versions of "i" with and without a dot, and
the upper-case version of "i" is "I"-with-a-dot and the lower-case
version of "I" is "i"-without-a-dot. This causes strings that should
match not to match.
This finishes fixing bug 2010 - an earlier checkin prevented the crash
(as there are other ways to produce the same crash, e.g. a bogus
dictionary.xml file), but didn't fix the case-insensitive string matching.
svn path=/trunk/; revision=23623
32-bit numbers. Separate signed and unsigned accessors have been
added and used where appropriate.
Definitely not for 0.99.5.
svn path=/trunk/; revision=20472
they have LF at the end of the line on UN*X and CR/LF on Windows;
hopefully this means that if a CR/LF version is checked in on Windows,
the CRs will be stripped so that they show up only when checked out on
Windows, not on UN*X.
svn path=/trunk/; revision=11400
Check slice lengths as well as offsets. Disallow negative/zero
lengths.
Range on RHS of display filter expression wasn't being checked in
every case.
svn path=/trunk/; revision=11083
Error if protocol specified on RHS of display filter comparison.
If user specified "fc", they probably intended a byte value rather than
the fibre channel protocol; fix makes mistake clear.
Fix assertion failure with range on LHS of display filter comparison
and field on RHS.
svn path=/trunk/; revision=10829
Michael Mann