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
then make sure that the FIELD can participate in the relation that
is expressed in the display filter.
Note that tvbuff's *should* be able to participate in == comparisons, etc.,
but those functions need to be added to ftype-tvbuff.c first.
svn path=/trunk/; revision=10175
check, in the semantics-checking phase, that we're testing a field, so
that we can give a better message than, for example, "Unexpected end of
filter string." for an existence test with a misspelled field name.
svn path=/trunk/; revision=10043
New "matches" operater in display filter language. Uses PCRE.
If a "matches" operator is found in a dfilter
while libpcre has not been used to build the binary, then an
exception is thrown after using dfilter_fail() to set an apporporiate
error message.
svn path=/trunk/; revision=9182
Besides "STRING", there is now "UNPARSED_STRING", where the distinction
is that "STRING" was a double-quoted string and "UNPARSED_STRING" is just
a sequence of characters that the scanner didn't know how to scan/parse,
so it's up to the Ftype to parse it.
This gives us more flexibility and prepares the dfilter parsing engine
for the upcoming addition of the "contains" operator.
In the process of doing this, I also re-did the double-quoted string
support in the scanner, so that instead of the naively-simple support we
used to have, double-quoted strings now can have embedded dobule-quotes,
embedded octal sequences, and embedded hexadecimal sequences:
"\"" embedded double-quote
"\110" embedded octal
"\x48" embedded hex
Enhance the dfilter unit test script to be able to run a single collection
of tests instead of having to run all of them all the time.
svn path=/trunk/; revision=8083
frame number, which is always decimal. If you select an FT_FRAMENUM
field, there are menu items that let you go to the frame whose frame
number appears in that field.
Add FT_FRAMENUM fields for the ONC RPC "matching request is in this
frame" and "matching reply is in this frame" protocol tree items.
svn path=/trunk/; revision=6802
pointer, and put "const" into the casts in "VALS()" and "TFS()" macros,
so we don't un-constify pointers to "value_string" arrays and
"true_false_string" structures.
Make some things "const" to keep the compiler happy with the previous
change.
svn path=/trunk/; revision=6684
floating-point numbers, and display all the significant digits for both
single-precision and double-precision floating-point numbers in the
protocol tree, not just what "%g" does (6 digits).
Put in comments explaining how the length of filter strings is computed,
and fix some of the computations.
svn path=/trunk/; revision=6081
Jakub Zawadzki