Change cflow.sysuptime from an FT_UINT32 (milliseconds since the router booted)
to an FT_RELATIVE_TIME (seconds since the router booted). I don't imagine
anyone will care if we show them seconds or milliseconds and it satisfy the
user's request (in that bug) to compare cflow.sysuptime to cflow.timeend (which
is already an FT_RELATIVE_TIME).
(If someone does care, we could always display the field twice, once in
milliseconds and once in seconds.)
svn path=/trunk/; revision=52821
are like the non-TVB versions except that they take a TVB and an offset
instead of (frequently) a pointer into the TVB.
Calling tvb_get_ptr() before modifying the rest of the fields should help fix
https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=7960 (though I can't
reproduce that problem).
Replace a bunch of calls like:
SET_ADDRESS(..., AT_XXX, length, tvb_get_ptr(tvb, offset, length));
with:
TVB_SET_ADDRESS(..., AT_XXX, tvb, offset, length);
svn path=/trunk/; revision=46324
- Use a (slightly) less simplistic hashing algorithm to reduce collisions;
Note: A GHashTable which handles collisions rather than
a home-grown hash table (which does not) needs to be implemented.
- Don't replace an existing template in the cache when a collision occurs;
Fixes Bug #6325https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=6325
svn path=/trunk/; revision=39990
interface scope is always 4 bytes. For that matter, nowhere does it
indicate that the scopes have any particular interpretation except as a
sequence of octets.
Get rid of the checks for a length of 4, and make ScopeSystem an
FT_BYTES. If, by *convention*, they're usually IPv4 or IPv6 addresses,
somebody can throw in code to display them as such if they happen to be
4 or 16 bytes, respectively. Leave ScopeInterface as an integer for
now, in case, by convention, they're interface indices, but still leave
the length check out.
Fixes bug 3954.
svn path=/trunk/; revision=39485
1. If there's no character encoding (ENC_ASCII, ...) specified
then use ENC_ASCII.
2. For all but FT_UINT_STRING, always use ENC_NA
(replacing any existing True/1/FALSE/0
/ENC_BIG_ENDIAN/ENC_LITTLE_ENDIAN).
svn path=/trunk/; revision=39426
Specifically: Replace FALSE|0 and TRUE|1 by ENC_BIG_ENDIAN|ENC_LITTLE_ENDIAN as
the encoding parameter for proto_tree_add_item() calls which directly reference
an item in hf[] which has a type of:
FT_BOOLEAN
FT_IPv4
FT_EUI64
FT_GUID
FT_UINT_STRING
Also: For type FT_ITv6 use ENC_NA. (This was missed in SVN #39260)
svn path=/trunk/; revision=39328
Specifically: Replace FALSE|0 and TRUE|1 by ENC_BIG_ENDIAN|ENC_LITTLE_ENDIAN as
the encoding parameter for proto_tree_add_item() calls which directly reference
an item in hf[] which has a type of:
FT_UINT8
FT_UINT16
FT_UINT24
FT_UINT32
FT_UINT64
FT_INT8
FT_INT16
FT_INT24
FT_INT32
FT_INT64
FT_FLOAT
FT_DOUBLE
svn path=/trunk/; revision=39288
Current NetFlow V9/IPFIX dissector treats IN_BYTES (IE=1) and
IN_PERMANENT_BYTES (IE=85) exactly in the same way. The same applies to IN_PKTS
(IE=2) and IN_PERMANENT_PKTS (IE=86). However, IN_BYTES/IN_PKTS and
IN_PERMANENT_BYTES/IN_PERMANENT_PKTS have different semantics so they should be
distinguishable when they are displayed or specified in a filter. Please find
attached the patch
which does that.
https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=5807
svn path=/trunk/; revision=36661
From me: Use lower-case v9template_max_fields instead of upper-case to avoid
any confusion with that variable being a define. Use STRINGIFY() so we always
keep the default and the displayed default the same. Fix bug introduced by
Andrew's patch where option_scope_field_count was inadvertently changed to
option_field_count. Append "Maximum value can be adjusted ..." message to all
relevant expert infos.
svn path=/trunk/; revision=36643
Jakub Zawadzki