There are protocols out there that have 64-bit wide bit mask fields, so
make the internal representation and bitfield decoders 64-bit aware.
For this, the ws_ctz() fallback and bits_count_ones() have to be tweaked
slightly.
Change-Id: I19237b954a69c9e6c55864f281993c1e8731a233
Reviewed-on: https://code.wireshark.org/review/4158
Petri-Dish: Alexis La Goutte <alexis.lagoutte@gmail.com>
Tested-by: Petri Dish Buildbot <buildbot-no-reply@wireshark.org>
Reviewed-by: Alexis La Goutte <alexis.lagoutte@gmail.com>
Reviewed-by: Michael Mann <mmann78@netscape.net>
We rarely, if ever, want to, or need to, explicitly set the captured
length of a packet; we want to set the *reported* length and let the
tvbuff code figure out how much of that data was actually captured.
Change-Id: I9b93d296197989f677d888b10954589dfc1edc59
Reviewed-on: https://code.wireshark.org/review/4138
Reviewed-by: Guy Harris <guy@alum.mit.edu>
Replace some conditional + fprintf + DISSECTOR_ASSERT()s with
DISSECTOR_ASSERT_HINT() or just change the DISSECTOR_ASSERT() to
DISSECTOR_ASSERT_NOT_REACHED() when the hint requires formatting.
Change-Id: I80c7c6579d7755a60d644b5ef60ec4e3299ba0ab
Reviewed-on: https://code.wireshark.org/review/4115
Reviewed-by: Evan Huus <eapache@gmail.com>
Petri-Dish: Evan Huus <eapache@gmail.com>
Tested-by: Petri Dish Buildbot <buildbot-no-reply@wireshark.org>
If we try we may (in the case of setting the length or end) mistakenly assert
out.
Bug: 10329
Change-Id: I52083ba17f6427712a6a363f48f1f7ae51f2b74b
Reviewed-on: https://code.wireshark.org/review/4093
Reviewed-by: Evan Huus <eapache@gmail.com>
Reviewed-by: Jeff Morriss <jeff.morriss.ws@gmail.com>
For field types where it doesn't mean "to the end of the tvbuff", treat
it like other negative length values - as if it were unsigned and thus
Very Large and thus likely to be past the end of the tvbuff. That way,
some of the "we hax0red your SNMP packets" captures, with length fields
of 0xffffffff, report malformed packets rather than dissector bugs.
Change-Id: Id53f828b06b6febe7d79f8539e54523e0b43e5c2
Reviewed-on: https://code.wireshark.org/review/4091
Reviewed-by: Guy Harris <guy@alum.mit.edu>
Change-Id: I2e8d18df71688c654f7acaff51fae7823c08aa6a
Reviewed-on: https://code.wireshark.org/review/3677
Reviewed-by: Michael Mann <mmann78@netscape.net>
Petri-Dish: Michael Mann <mmann78@netscape.net>
Tested-by: Petri Dish Buildbot <buildbot-no-reply@wireshark.org>
Reviewed-by: Jeff Morriss <jeff.morriss.ws@gmail.com>
Reviewed-by: Evan Huus <eapache@gmail.com>
Other minor cleanup while in the neighborhood.
Change-Id: Ib76f4a9f89b5933425760af0a980c6a549031b8f
Reviewed-on: https://code.wireshark.org/review/3537
Petri-Dish: Michael Mann <mmann78@netscape.net>
Tested-by: Petri Dish Buildbot <buildbot-no-reply@wireshark.org>
Reviewed-by: Michael Mann <mmann78@netscape.net>
This is what you get for forward-cherrypicking commits you made on master-1.12.
Change-Id: I8e51181d497dc63c614fe623439506cfe99c6fa3
Reviewed-on: https://code.wireshark.org/review/3385
Reviewed-by: Evan Huus <eapache@gmail.com>
Otherwise the offsets will be wrong when calling, e.g. proto_item_set_end.
Bug:10329
Change-Id: I5ae0c660af90678e446817b65f83c075e7c0b84e
Reviewed-on: https://code.wireshark.org/review/3341
Reviewed-by: Evan Huus <eapache@gmail.com>
... As would be the case if proto_tree_add_text() + proto_item_add_subtree()
were used. (This initialization value is only used when TRY_TO_FAKE_THIS_ITEM()
shortcuts us out.)
As reported/discussed on -dev:
https://www.wireshark.org/lists/wireshark-dev/201407/msg00031.html
Change-Id: I4af63e3cf0a70607d58b4641597b2ce7907fbb8b
Reviewed-on: https://code.wireshark.org/review/3271
Reviewed-by: Michael Mann <mmann78@netscape.net>
Tested-by: Martin Kaiser <wireshark@kaiser.cx>
Reviewed-by: Evan Huus <eapache@gmail.com>
Change-Id: I64bb64787c83ffe712ffd348cceb5449690dd6d0
Reviewed-on: https://code.wireshark.org/review/3247
Reviewed-by: Martin Kaiser <wireshark@kaiser.cx>
Tested-by: Martin Kaiser <wireshark@kaiser.cx>
There is still some const-incorrect usage of them but those can be ironed
out after this change has been made.
Change-Id: Iba0631c804bdab34d7c0232b49967130e3370488
Reviewed-on: https://code.wireshark.org/review/3199
Petri-Dish: Pascal Quantin <pascal.quantin@gmail.com>
Tested-by: Petri Dish Buildbot <buildbot-no-reply@wireshark.org>
Reviewed-by: Michael Mann <mmann78@netscape.net>
Refactor (non-GUI) conversation table functionality from gtk/Qt to epan. Also refactor "common GUI" conversation table functionality.
The idea is to not have to modify the GUI when a dissector adds a new "conversation type"
Change-Id: I11f08d0d7edd631218663ba4b902c4a4c849acda
Reviewed-on: https://code.wireshark.org/review/3113
Reviewed-by: Gerald Combs <gerald@wireshark.org>
Unfortunately, certain proto_hier_tree_model.c functions
assume/require that a cookie generated by
proto_(first|next)_protocol_field() will never have a NULL value.
Bug introduced in gd47ae54.
Change-Id: I42763d02f700e15ca9b3ab9980943d4f8d933ca9
Reviewed-on: https://code.wireshark.org/review/2712
Reviewed-by: Evan Huus <eapache@gmail.com>
This is intended as a replacement for all of the proto_tree_add_text followed by proto_item_add_subtree calls.
Change-Id: I892136d7b9d8b4e100996097eff62ce7af9512d2
Reviewed-on: https://code.wireshark.org/review/2472
Reviewed-by: Michael Mann <mmann78@netscape.net>
Change-Id: I24fe3cc4a3589dadc4528a77fe7ff13d06b1a983
Reviewed-on: https://code.wireshark.org/review/2245
Reviewed-by: Michael Mann <mmann78@netscape.net>
The main limitation that comes to mind for the length of "an Ethernet"
is that a 10BASE5 segment can't be longer than 500 m. :-) Say "a MAC
address" rather than "an Ethernet", as 1) we're fetching an address, not
an actual physical Ethernet and 2) FT_ETHER is really FT_MAC48 and it
used for protocols other than Ethernet.
Change-Id: I402341371006e7933faa5c60dab2e58cfb349eb3
Reviewed-on: https://code.wireshark.org/review/1913
Reviewed-by: Guy Harris <guy@alum.mit.edu>
There are lot of text dissectors which want just to add escaped (not filtrable) text,
add new function proto_tree_add_format_text() which just do this in optimized way.
Change-Id: Ia0e189b620cc0a5b74cfdaef1ad4571d766bb2ab
Reviewed-on: https://code.wireshark.org/review/1678
Reviewed-by: Michael Mann <mmann78@netscape.net>
Reviewed-by: Evan Huus <eapache@gmail.com>
g867a1827e7dc88896ee27a107eb35c4b3973d270 introduced a change to cleanup/fix
handling of bounds checks for -1 length fields, but it ended up guaranteeing a
throw for 0-length tvbs, which isn't good; we ought to be able to add 0-length
FT_PROTOCOL items at the very least.
Better names for the function than _cheat are welcome, but I want to shut up the
buildbot.
Change-Id: I24610f947d03dac32766e2a0ffa0ff7bcc74c3e8
Reviewed-on: https://code.wireshark.org/review/1303
Reviewed-by: Evan Huus <eapache@gmail.com>
Treat FT_BYTES and a few others the same as FT_PROTOCOL: allow a zero length
but throw an exception if the offset is already beyond the end of the TVB
(prior to this change it would assert out). This (when manually applied to
master-1.10) fixes https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=9999 .
While we're at it: tvb_captured_length_remaining() no longer returns -1 (see
r52571) so don't expect it to. Instead just use
tvb_ensure_captured_length_remaining() to throw an exception if the offset is
bad.
Change-Id: I686722a4fed46b86139466afcf64ff02f319c702
Reviewed-on: https://code.wireshark.org/review/1289
Reviewed-by: Evan Huus <eapache@gmail.com>
Reviewed-by: Anders Broman <a.broman58@gmail.com>
This is substantially more memory-efficient, shaving another ~1.5MB off our base
usage. It also lets us remove the annoying extra "last_field" pointer and
simplify proto_register_field_common(). It also accidentally fixed what may
have been a memory leak in proto_unregister_field().
It unfortunately complicates proto_get_next_protocol_field() to require
refetching the protocol each time, but that is itself just an array-lookup under
the covers (and isn't much used), so I don't expect the performance hit to be
noticable.
Change-Id: I8e1006b2326d6563fc3b710b827cc99b54440df1
Reviewed-on: https://code.wireshark.org/review/1225
Reviewed-by: Michael Mann <mmann78@netscape.net>
Reviewed-by: Evan Huus <eapache@gmail.com>
Shaves ~1.5MB off our base memory usage, and provides O(1) operations instead of
O(log n). We don't need the additional operations a tree provides.
Change-Id: I6159d09ee380a2bca0de3bb2d031a874d8eb79d2
Reviewed-on: https://code.wireshark.org/review/1224
Reviewed-by: Michael Mann <mmann78@netscape.net>
Reviewed-by: Evan Huus <eapache@gmail.com>
Add ep_ to routines that may return ephemeral strings.
Change "get_XXX" to "XXX_to_display" if the routine returns a formatted
string if it can't get a name.
Change-Id: Ia0e82784349752cf4285bf82788316c9588fdd88
Reviewed-on: https://code.wireshark.org/review/1217
Reviewed-by: Guy Harris <guy@alum.mit.edu>
This commit adds tvb_get_string_bytes and proto_tree_add_bytes_item routines for
getting GByteArrays fields from the tvb when they are encoded in ASCII hex string form.
The proto_tree_add_bytes_item routine is also usable for normal
binary encoded byte arrays, and has the advantage of retrieving
the array values even if there's no proto tree.
It also exposes the routines to Lua, both so that a Lua script can take
advantage of this, but also so I can write a testsuite to test the functions.
Change-Id: I112a038653df6482a5d0ebe7c95708f207319e20
Reviewed-on: https://code.wireshark.org/review/1158
Reviewed-by: Hadriel Kaplan <hadrielk@yahoo.com>
Reviewed-by: Anders Broman <a.broman58@gmail.com>
This commit adds tvb_get_string_time and proto_tree_add_time_item routines for
getting nstime fields from the tvb when they are encoded in ASCII string form.
The proto_tree_add_time_item routine is also usable for normal
big/little-endian encoded time_t, and has the advantage of retrieving
the value even if there's no proto tree.
It also exposes the routines to Lua, both so that a Lua script can take
advantage of this, but also so I can write a testsuite to test the functions.
Change-Id: I955da10f68f2680e3da3a5be5ad8fdce7ed6808c
Reviewed-on: https://code.wireshark.org/review/1084
Reviewed-by: Anders Broman <a.broman58@gmail.com>
All three types support zero length, so using
-1 (aka length remaining) should be safe.
Change-Id: Ia616d652ce6884f8e12a5ac5782073403810b10b
Reviewed-on: https://code.wireshark.org/review/1072
Reviewed-by: Alexis La Goutte <alexis.lagoutte@gmail.com>
That way we don't have to update the hf_types[] value_string if a new
type is added.
Change-Id: If4fd0a8ff2d6b54d0b70140be407dae9c4ab6b3b
Reviewed-on: https://code.wireshark.org/review/1083
Reviewed-by: Guy Harris <guy@alum.mit.edu>
Add an FT_STRINGZPAD type, for null-padded strings (typically
fixed-length fields, where the string can be up to the length of the
field, and is null-padded if it's shorter than that), and use it. Use
IS_FT_STRING() in more cases, so that less code needs to know what types
are string types.
Add a tvb_get_stringzpad() routine, which gets null-padded strings.
Currently, it does the same thing that tvb_get_string_enc() does, but
that might change if we don't store string values as null-terminated
strings.
Change-Id: I46f56e130de8f419a19b56ded914e24cc7518a66
Reviewed-on: https://code.wireshark.org/review/1082
Reviewed-by: Guy Harris <guy@alum.mit.edu>
Since proto.c was using strcat(), changes to the file won't pass checkAPIs.
So this commit replaces it with the appropriate function, and also replaces
the deprecated tvb_length_remaining and tvb_ensure_length_remaining function
calls with the new versions, since checkAPIs was warning about that too.
This commit does not change the ep_* memorry calls to the new wmem-based
ones though, as that's a bigger deal than this trivial commit I think.
Change-Id: I51e6d5b3a6e03233f2695c890ff4c10d02fdb0c0
Reviewed-on: https://code.wireshark.org/review/905
Reviewed-by: Hadriel Kaplan <hadrielk@yahoo.com>
Reviewed-by: Anders Broman <a.broman58@gmail.com>
(Using sed : sed -i '/^ \* \$Id\$/,+1 d')
Fix manually some typo (in export_object_dicom.c and crc16-plain.c)
Change-Id: I4c1ae68d1c4afeace8cb195b53c715cf9e1227a8
Reviewed-on: https://code.wireshark.org/review/497
Reviewed-by: Anders Broman <a.broman58@gmail.com>
label_mark_truncated()
Change-Id: I7ede5f9776d26ebce2ccf427cf6ff5dec56814cd
Reviewed-on: https://code.wireshark.org/review/465
Reviewed-by: Martin Kaiser <wireshark@kaiser.cx>
Daniel Mack