Set the FI_BITS_OFFSET and FI_BITS_SIZE flags appropriately on [u]int[64]
(and thus chars and booleans) where the bitmask is passed in on the
header_field_info. Also set the flags on bitmask items by ORing the bitmasks
from the constituent fields. These flags are only used right now in the
packet diagram.
This makes the packet diagram display those types of fields correctly without
having to use proto_item_set_bits_offset_len(), so long as the bitmask is
correct and the field width of the type matches the octet length. (If it
doesn't match, that's a dissector bug.)
split bit items are a more complicated case and still not handled correctly.
This adds a protocol post-dissector for Community ID support to
Wireshark/tshark: https://github.com/corelight/community-id-spec
The protocol is disabled by default. It establishes one new filter
value, "communityid".
Includes test cases and baselines to verify correct Community ID
strings based on similar testsuites in the existing Zeek and Python
implementations.
Add a new top-level view that shows each packet as a series of diagrams
similar to what you'd find in a networking textook or an RFC.
Add proto_item_set_bits_offset_len so that we can display some diagram
fields correctly.
Bugs / to do:
- Make this a separate dialog instead of a main window view?
- Handle bitfields / flags
Change-Id: Iba4897a5bf1dcd73929dde6210d5483cf07f54df
Reviewed-on: https://code.wireshark.org/review/37497
Reviewed-by: Gerald Combs <gerald@wireshark.org>
Petri-Dish: Gerald Combs <gerald@wireshark.org>
Tested-by: Petri Dish Buildbot
Reviewed-by: Anders Broman <a.broman58@gmail.com>
XXX comment reworded to be more informative and reflect lack of
consensus on removing RFC 3514.
Change-Id: If15b8f5d7c450192b1b6ebbfa463b19f27de177c
Reviewed-on: https://code.wireshark.org/review/35934
Petri-Dish: João Valverde <j@v6e.pt>
Tested-by: Petri Dish Buildbot
Reviewed-by: João Valverde <j@v6e.pt>
A filter for payload makes it easier to exoprt it.
Change-Id: I0732c60c7fac37283fcbe6508d5e27bcd3c603fd
Reviewed-on: https://code.wireshark.org/review/35519
Petri-Dish: Anders Broman <a.broman58@gmail.com>
Tested-by: Petri Dish Buildbot
Reviewed-by: Anders Broman <a.broman58@gmail.com>
Bug: 15393
Change-Id: I931813ce3492557a5673e6bbd0269d34c0d550b2
Reviewed-on: https://code.wireshark.org/review/31416
Petri-Dish: Michael Mann <mmann78@netscape.net>
Tested-by: Petri Dish Buildbot
Reviewed-by: Michael Mann <mmann78@netscape.net>
The local and group address flags are shared between destination and
source addresses. This makes filtering difficult sometimes. Create
unique fields for them, while moving the existing fields into hiding.
This breaks the output format tests, so the baseline files need to be
updated as well. At the same time document how this can be done.
Bug: 15955
Change-Id: I849bb306f044c09d4ed0836fe92fef8981912500
Reviewed-on: https://code.wireshark.org/review/34139
Petri-Dish: Jaap Keuter <jaap.keuter@xs4all.nl>
Tested-by: Petri Dish Buildbot
Reviewed-by: Alexis La Goutte <alexis.lagoutte@gmail.com>
The v2.5.0rc0-478-g558fe23226, the dissection of ip.frag_offset changed
to be listed under "Flags", this is not correct. The Fragmentation
Offset is a separate field according to the RFC. This change corrects
that behavior. Also, the raw value from the header was shown instead of
the real byte offset, this is also corrected.
Change-Id: I1d6dfc4314091eb6f3eef418c5a17ed37f7a1200
Fixes: v2.5.0rc0-478-g558fe23226 ("[IP] Simplify paring of flags field by using proto_tree_add_bitmask_with_flags().")
Reviewed-on: https://code.wireshark.org/review/33422
Petri-Dish: Sake Blok <sake.blok@SYN-bit.nl>
Tested-by: Petri Dish Buildbot
Reviewed-by: Peter Wu <peter@lekensteyn.nl>
Petri-Dish: Peter Wu <peter@lekensteyn.nl>
Reviewed-by: Sake Blok <sake.blok@SYN-bit.nl>
The outputs of -T ek and -G elastic-mapping don't match. To be effective
the fields in the mapping report and the fields in the traffic output must
be the same.
2 issues have been fixed. The elastic-mapping requires the parent protocol
to be prepended to the field to match the traffic output. The field "dns.a"
has been changed to "dns_dns_a".
The traffic output prints some fields with a leading "text_". This happens
for some fields that have been created under a text only field. One example
is "dns.a", that was printed as "text_dns_a". This has been fixed by accessing
the parent hfinfo resulting in "dns_dns_a" as other fields for the dns
protocol.
Bug: 15759
Change-Id: Ibd000c865102ca49bb6a6394019a475483eae4cc
Reviewed-on: https://code.wireshark.org/review/33099
Petri-Dish: Dario Lombardo <lomato@gmail.com>
Tested-by: Petri Dish Buildbot
Reviewed-by: Eneko Gómez <eneko.gomez.tecnalia@gmail.com>
Reviewed-by: Dario Lombardo <lomato@gmail.com>
Newer versions of elastic are using 'doc' as type. Change the code
according to that.
Fix point (4) of the linked bug.
Bug: 15763
Change-Id: Ia28102a0914c6308eb3516daa57af2e49ce9a4e5
Reviewed-on: https://code.wireshark.org/review/33111
Petri-Dish: Dario Lombardo <lomato@gmail.com>
Tested-by: Petri Dish Buildbot
Reviewed-by: Eneko Gómez <eneko.gomez.tecnalia@gmail.com>
Reviewed-by: Dario Lombardo <lomato@gmail.com>
This is the new standard in recent Elastic versions.
Fix point (3) of the linked bug.
Bug: 15763
Change-Id: I64ef085c2a8ad9d25ced30a337287c8cb77903e4
Reviewed-on: https://code.wireshark.org/review/33112
Petri-Dish: Dario Lombardo <lomato@gmail.com>
Tested-by: Petri Dish Buildbot
Reviewed-by: Eneko Gómez <eneko.gomez.tecnalia@gmail.com>
Reviewed-by: Dario Lombardo <lomato@gmail.com>
The string type is the default in elasticsearch, then there is no
need to put those entries in the mapping report. This shortens a lot
the list.
Small indentation fix, while here.
Change-Id: If304d409a3ee2c30f24b5de4d90be522bbfae41e
Ping-Bug: 15719
Reviewed-on: https://code.wireshark.org/review/33053
Petri-Dish: Dario Lombardo <lomato@gmail.com>
Tested-by: Petri Dish Buildbot
Reviewed-by: Peter Wu <peter@lekensteyn.nl>
This suite uses different output formats to check against fixed
samples.
Change-Id: I8adccfefea35a6d3cfacf3da61e8a72d830ed3a0
Reviewed-on: https://code.wireshark.org/review/31056
Petri-Dish: Dario Lombardo <lomato@gmail.com>
Reviewed-by: Peter Wu <peter@lekensteyn.nl>
Tested-by: Petri Dish Buildbot
Reviewed-by: Dario Lombardo <lomato@gmail.com>
The (optional) JSON-GLib library adds dependencies on GObject, GIO. For
statically linked oss-fuzz builds it also adds libffi and more. To avoid
these dependencies, replace JSON-GLib by some custom code. This allows
`tshark -G elastic-mapping` to be enabled by default without extra deps.
API design goals of the new JSON dumper library:
- Small interface without a lot of abstraction.
- Avoid memory allocations if possible (currently none, but maybe
json_puts_string will be replaced to improve UTF-8 support).
- Do not implement parsing, this is currently handled by jsmn.
Methods to open/close array/objects and to set members are inspired by
the JsonGlib interface. The interfaces to write values is inspired by
the sharkd code (json_puts_string is also borrowed from that).
The only observed differences in the tshark output:
- JSON-GLib ignores duplicates, json_dumper does not and may produce
duplicates and currently print two "ip.opt.sec_prot_auth_unassigned".
- JSON-GLib adds a space before a colon (unimportant formatting detail).
- (Not observed, but UTF-8 strings will be wrong like bug 14948.)
A test was added to catch changes in the tshark output. I also fuzzed
json_dumper with libFuzzer + UBSAN/ASAN and fixed an off-by-one error.
Change-Id: I0c85b18777b04d1e0f613a3d59935ec59be87ff4
Link: https://www.wireshark.org/lists/wireshark-dev/201811/msg00052.html
Reviewed-on: https://code.wireshark.org/review/30732
Petri-Dish: Peter Wu <peter@lekensteyn.nl>
Tested-by: Petri Dish Buildbot
Reviewed-by: Anders Broman <a.broman58@gmail.com>
Add the fileformats and I/O suites. Move some more common code to
subprocesstest.py and add a diffOutput method.
Change-Id: I2ec34e46539022bdce78520645fdca6dfc1a8c1a
Reviewed-on: https://code.wireshark.org/review/27183
Petri-Dish: Gerald Combs <gerald@wireshark.org>
Tested-by: Petri Dish Buildbot
Reviewed-by: Gerald Combs <gerald@wireshark.org>
Chuck Craft