| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
Use proto_tree_add_uint_format_value() to avoid duplicating
the field info name in the item representation string.
Adjust the hf entries accordingly.
|
|
Originally reported downstream in Gentoo at https://bugs.gentoo.org/933290.
This is the same kind of thing as https://gitlab.com/wireshark/wireshark/-/merge_requests/9029.
|
|
Update `sharkd`'s `frames` method to include a `comments` string array
containing the comments for a frame. The existing boolean `ct` field,
which is `true` if the frame has one or more comments, has not been
modified. Like the existing `ct` field, the new `comments` field is
only included in the response if the frame has comments. A new
`test_sharkd_req_frames_comments` unit test has been added to verify
the functionality of the new `comments` field.
|
|
Add new optional `interval_units` string parameter to `sharkd`'s
`iograph` method to allow specifying what unit should be used with the
existing `interval` parameter. `interval_units` must be either
`s` (seconds), `ms` (milliseconds) or `us` (microseconds) and defaults
to `ms`.
Previously, `iograph`'s `interval` parameter (whose default of `1000`
has not changed) was always assumed to be in milliseconds. This was
unfortunate since b46c1e9f (part of #13682) added support for
intervals as small as 1 microsecond. With the new `interval_units`
parameter, `iograph` can take advantage of this greater precision
while still remaining backwards compatible since requests that don't
include `interval_units` will default to millisecond precision as they
always have.
As part of b46c1e9f, the maximum number of `io_graph_item_t`'s stored
for a graph in the QT GUI was bumped from `1 << 24` to `1 << 25` (see
`max_io_items_` in `ui/qt/io_graph_dialog.h`). `sharkd`'s `iograph`
method, however, has a separate limit `SHARKD_IOGRAPH_MAX_ITEMS` in
`sharkd_session.c`, which remained set to 250,000. This commit
updates `SHARKD_IOGRAPH_MAX_ITEMS` to be `1 << 25` so that `sharkd`
uses the same limit as the GUI.
Note that a significant portion of the diff for `sharkd_session.c` is
due to readjusting the columns for entries in the `name_array` array
used by `sharkd` when parsing method parameters due to the
`interval_units` parameter being longer than existing parameter names.
However, the only significant change to `name_array` is the addition
of the following line:
{"iograph", "interval_units", 2, JSMN_STRING, SHARKD_JSON_STRING, SHARKD_OPTIONAL},
Finally, added a few new `sharkd` unit tests to verify the new
`interval_units` parameter.
|
|
Add new optional `sub_stream` input argument to `sharkd`'s `follow`
method which, if given, specifies the sub-stream index number to
follow (e.g. for HTTP/2 or QUIC streams). If no `sub_stream` argument
is given, all sub-streams are followed (by using the special
`SUBSTREAM_UNUSED` sub-stream index value).
Add new `followers` output field to `sharkd`'s `frame` method which
contains an array of objects each containing `protocol`, `filter`,
`stream` and (for HTTP/2 or QUIC streams) `sub_stream` fields. A new
`followers` array was added to the response instead of adding the
stream and sub-stream indices to the existing `fol` field due to
backwards-compatibility issues. The `fol` field is an array of string
arrays, each subarray containing the same values as the `protocol` and
`filter` fields in the new `followers` array, i.e.:
"fol": [["TCP", "tcp.stream eq 0"], ["TLS", "tcp.stream eq 0"]]
which makes adding new, possibly optional, fields difficult. The
`fol` field should be considered deprecated, any new fields should be
added to `followers`. The new `followers` field is an array of
objects, making adding new fields down the road simple:
"followers": [{"protocol": "TCP", "filter": "tcp.stream eq 0"}, {"protocol": "TLS", "filter": "tcp.stream eq 0"}]
Updated existing and added new `sharkd` unit tests to validate
behavior of new fields/arguments.
|
|
Add new `column_info` field to `sharkd`'s `status` method which
contains additional column information. A new `column_info` field was
added because the existing `columns` field is a simple string array
and therefore new fields could not be added to it in a
backwards-compatible manner. The new `column_info` field includes
each column's title, format string (i.e. `%x` or
`%Cus:<expr>:<occurrence>` if `COL_CUSTOM`) as well as booleans
indicating if the column is visible or resolved.
The existing `sharkd` unit tests `test_sharkd_req_status_no_pcap` and
`test_sharkd_req_status` have been updated to check for the new
`column_info` field.
|
|
As noted in #17923, commit c4731738 broke timereferences and displayed
delta time (`frame.time_delta_displayed`) in the `frames` method of
`sharkd`. This commit adds back to `sharkd_session_process_frames`
the local variables `prev_dis_num`, `current_ref_frame` and
`ref_frame` which are used to determine the `frame_ref_num` and
`prev_dis_num` arguments to each call to `sharkd_dissect_request` in
the main loop of `sharkd_session_process_frames`.
Below is an example on `master` (`b7cc44eb34`, specifically) of a
`frames` request for packets 1 and 800 of the capture
`./test/captures/logistics_multicast.pcapng` where we ask for columns
`frame.time_relative`, `frame.time_delta` and
`frame.time_delta_displayed`:
# ./cmake-build-debug/run/sharkd -
Running as user "root" and group "root". This could be dangerous.
Hello in child.
{"jsonrpc":"2.0","id":1,"method":"load","params":{"file":"./test/captures/logistics_multicast.pcapng"}}
load: filename=./test/captures/logistics_multicast.pcapng
{"jsonrpc":"2.0","id":1,"result":{"status":"OK"}}
{"jsonrpc":"2.0", "id":2, "method":"frames","params":{"filter":"frame.number==1||frame.number==800","column0":"frame.time_relative:1","column1":"frame.time_delta:1","column2":"frame.time_delta_displayed:1"}}
{"jsonrpc":"2.0","id":2,"result":[{"c":["0.000000000","0.000000000","0.000000000"],"num":1},{"c":["191.872111000","0.193716000","0.193716000"],"num":800}]}
Note that the `frame.time_delta_displayed` column value for packet 800
is `0.193716000`, which is time difference between it and packet 799,
not packet 1.
Compare this to the same `frames` request using the changes from this
commit:
# ./cmake-build-debug/run/sharkd -
Running as user "root" and group "root". This could be dangerous.
Hello in child.
{"jsonrpc":"2.0","id":1,"method":"load","params":{"file":"./test/captures/logistics_multicast.pcapng"}}
load: filename=./test/captures/logistics_multicast.pcapng
{"jsonrpc":"2.0","id":1,"result":{"status":"OK"}}
{"jsonrpc":"2.0", "id":2, "method":"frames","params":{"filter":"frame.number==1||frame.number==800","column0":"frame.time_relative:1","column1":"frame.time_delta:1","column2":"frame.time_delta_displayed:1"}}
{"jsonrpc":"2.0","id":2,"result":[{"c":["0.000000000","0.000000000","0.000000000"],"num":1},{"c":["191.872111000","0.193716000","191.872111000"],"num":800}]}
Note that the `frame.time_delta_displayed` column value for packet 800
is now `191.872111000`, the time difference between it and packet 1.
This is the expected value since only packets 1 and 800 are visible
due to the request's `filter` parameter.
A new `test_sharkd_req_frames_delta_times` unit test has been added to
verify this fix and prevent it the bug from being accidentally
sneaking in again. If this fix is accepted, this change should
probably be cherry-picked to the `release-4.2` branch.
Fixes #17923.
|
|
Add `hosts:` tap to `tap` method of `sharkd` which returns a list of
resolved hostnames found in the capture file, thus providing the same
information as `tsharks -z hosts`. The `hosts:` tap accepts an
optional list of comma-separated protocol names `ipv4`, `ip` (synonym
for `ipv4`) or `ipv6`. For example, `hosts:ipv4` returns only IPv4
hosts, `hosts:ipv6` returns only IPv6 hosts and `hosts:ipv4,ipv6`
returns both IPv4 and IPv6 hosts. If no protocol names are
given (i.e. if the request is just `host:`), both IPv4 and IPv6 hosts
are returned. In the response, IPv4 and IPv6 hosts are returned in
separate `ipv4_hosts` and `ipv6_hosts` arrays containing objects with
`name` and `addr` fields. Both arrays are sorted by the `name` field
of each object.
|
|
Add two new fields `capture_types` and `encap_types` to the output of
`sharkd`'s `info` method which replicate the info displayed by
`editcap -F` and `editcap -T`, respectively.
|
|
Commit a4c6a2f1 added a `voip-calls` tap to `sharkd`, but a copy-paste
bug in `sharkd_session_process_tap_voip_calls_cb` caused each call's
`stop_time` field to actually be the call's start time. This commit
fixes this bug and updates the `test_sharkd_req_tap_voip_calls` unit
test accordingly.
|
|
Previously, a `download` method request for an `eo:<name>_<row>`
export object (for example, `eo:http_0` to download the HTTP export
object with row 0) would fail unless a `tap` method for `eo:<name>`
had already been run. This behavior is surprising as the other
resources downloadable via the `download` method do not work this way.
This commit addresses this issue by updating the `download` method to,
when a `eo:<name>_<row>` export object is requested, see if an
`eo:<name>` object list already exists in `sharkd_eo_list`. If it
does not exist, the `download` method first generates the object list
for `eo:<name>` and adds it to `sharkd_eo_list` using `sharkd_retap`
in the same manner that the `tap` method does. After that, the
`download` method looks for the exported object in `sharkd_eo_list`
just as it did before.
This commit also adds a `sha1` field to the list of exported objects
returned by the `tap` method for `eo` objects in
`sharkd_session_process_tap_eo_cb`.
|
|
Add new optional `filter` parameter to `sharkd`'s `tap` method which
sets the `fstring` filter parameter which should be used for all
`register_tap_listener` calls made when creating taps requested in the
method's `tap0`-`tap15` parameters. The value of the new `filter`
parameter is used to set a `tap_filter` local variable in
`sharkd_session_process_tap`. This local variable existed previously
and was already passed into most calls to `register_tap_listener`, but
was always set to an empty string.
|
|
The `fn` attribute indicates the "field name" of the current tree item.
This is useful to have outside of having to parse the `f` attribute.
|
|
Add `voip-calls` and `voip-convs` taps to `sharkd`, which provide the
same information as the `Telephony -> VoIP Calls` GUI menu item. The
`voip-convs` tap accepts an optional comma-separated list of call ID's
allowing the caller to limit which conversations are returned. Both a
single call ID or a `<start>-<end>` call ID range is accepted. For
example, `voip-convs:` returns all conversations, `voip-convs:123`
returns only the conversation with call ID 123 and
`voip-convs:1,5-7,9` returns conversations with call ID's 1, 5, 6, 7
and 9. The call ID for a conversation is returned in the `call`
field. The set of call ID's requested by the caller is stored in a
bit-array which, on a standard Linux amd64 machine, supports storing a
maximum of 65536 call ID's.
Because many of the taps initialized by `voip_calls_init_all_taps` are
not able to be built without it, a basic CLI-based implementation of
`simple_dialog` which prints to `stderr` has been added in
`ui/cli/simple_dialog.c`.
|
|
Add `phs` tap to `sharkd`, providing the same information as
`tshark`'s `-z io,phs` option.
Additionally, modify how `tshark -z io,phs` (and therefore `sharkd`'s
new `phs` tap) handles packet comments (aka `pkt_comment` protocol
frames). Previously, `pkt_comment` protocol frames were handled no
differently from any other protocol in `io,phs`'s `tap_packet`
callback `protohierstat_packet` but were skipped in its `tap_draw`
callback `protohierstat_draw`. This behavior seems to have been first
introduced in 80ae3708. For captures containing packet comments, this
lead to surprising `tshark -z io,phs` output with multiple root-level
`eth` trees. Below is example output of the old behavior for the
`test/captures/protohier-with-comments.pcapng` capture in this
repository with two packet comments, one on an ICMPv6 packet and
another on an SSDP packet:
# tshark -qz io,phs -r ./test/captures/protohier-with-comments.pcapng
===================================================================
Protocol Hierarchy Statistics
Filter:
eth frames:113 bytes:21809
ipv6 frames:38 bytes:7456
icmpv6 frames:35 bytes:3574
udp frames:3 bytes:3882
data frames:3 bytes:3882
ip frames:69 bytes:13993
udp frames:59 bytes:13391
mdns frames:1 bytes:138
ssdp frames:29 bytes:8561
nbns frames:20 bytes:2200
nbdgm frames:1 bytes:248
smb frames:1 bytes:248
mailslot frames:1 bytes:248
browser frames:1 bytes:248
dhcp frames:4 bytes:1864
dns frames:4 bytes:380
igmp frames:10 bytes:602
arp frames:6 bytes:360
eth frames:2 bytes:377
ipv6 frames:1 bytes:110
icmpv6 frames:1 bytes:110
ip frames:1 bytes:267
udp frames:1 bytes:267
ssdp frames:1 bytes:267
===================================================================
Despite the comment in `phs_draw` in `ui/cli/tap-protohierstat.c`,
this does not seem to match the behavior for PHS as shown in the GUI.
The GUI seems to ignore the `pkt_comment` protocol frames and merges
their children up a level. This commit tries to reproduce this
behavior in the `tshark -z io,phs` output by ignoring `pkt_comment`
protocol frames in `protohierstat_packet` instead of
`protohierstat_draw`. The result is output like the following:
# tshark -qz io,phs -r ./test/captures/protohier-with-comments.pcapng
===================================================================
Protocol Hierarchy Statistics
Filter:
eth frames:115 bytes:22186
ipv6 frames:39 bytes:7566
icmpv6 frames:36 bytes:3684
udp frames:3 bytes:3882
data frames:3 bytes:3882
ip frames:70 bytes:14260
udp frames:60 bytes:13658
mdns frames:1 bytes:138
ssdp frames:30 bytes:8828
nbns frames:20 bytes:2200
nbdgm frames:1 bytes:248
smb frames:1 bytes:248
mailslot frames:1 bytes:248
browser frames:1 bytes:248
dhcp frames:4 bytes:1864
dns frames:4 bytes:380
igmp frames:10 bytes:602
arp frames:6 bytes:360
===================================================================
Note that there are no `pkt_comment` protocols and only a single
root-level `eth` protocol. Additionally, the commented ICMPv6 and
SSDP packets have been merged into the first `eth` tree, and the frame
and byte counts have been incremented appropriately.
|
|
Adds several columns to the rtp-stream list: `start_time`, `duration`,
`lost`, `lost_percent`, `min_delta`, `mean_delta` and `min_jitter`.
|
|
Add a GUI option to append a DSB to the open file containing any
used TLS secrets from the session. The marks the file as having
unsaved changes.
Note #19128 - we don't currently have warning about saving a file
with a DSB in a format that doesn't support it, as we do with comments.
No longer export the RSA Session ID, only CLIENT_RANDOM related
information. This has been a long standing TODO.
Fix #18400
|
|
|
|
Sharkd must always return a JSONRPC response to client input.
Fixes two cases in the processing of the "download" request where no
response was sent:
- When the `token` argument was missing
- When the `token` argument did not match an expected pattern
Two new error values were invented for this since there's not much
guidance on how to define error codes. They are currently unique and
only used in these two cases.
|
|
The token format used by rtp-analyse and rtp-download expect the SSRC
field to be a hex string parsable by `ws_hexstrtou32()` as seen in
sharkd_session.c:760. The output from tap:rtp-streams was displaying
it as an unsigned integer.
For consistency, this field is now displayed as a hex string in the
output.
If the call to download an RTP stream did not match any payloads, Sharkd
would not return any information at all.
This now returns an error message indicating that there is no RTP data
available.
Adds three new selftests and sample pcap.
|
|
Fixes a bug when the return value from load_cap_file() is nonzero.
No response is currently returned causing the client to hang. A non-zero
error code can happen for a variety of reasons, one of which is when the
PCAP is truncated.
An error message from cfile_read_failure_message() is displayed on the
console, but no data was returned to the RPC client.
This adds a call to wtap_strerrror() to look up a human consumable error
message for the specific error code returned during wtap_read().
Adds new self-test to suite_sharkd.py
|
|
|
|
Mostly functioning proof of concept for #14329. This work is intended to
allow Wireshark to support multiple packet comments per packet.
Uses and expands upon the `wtap_block` API in `wiretap/wtap_opttypes.h`.
It attaches a `wtap_block` structure to `wtap_rec` in place of its
current `opt_comment` and `packet_verdict` members to hold OPT_COMMENT
and OPT_PKT_VERDICT option values.
|
|
|
|
PEP 394[1] says,
"In cases where the script is expected to be executed outside virtual
environments, developers will need to be aware of the following
discrepancies across platforms and installation methods:
* Older Linux distributions will provide a python command that refers
to Python 2, and will likely not provide a python2 command.
* Some newer Linux distributions will provide a python command that
refers to Python 3.
* Some Linux distributions will not provide a python command at all by
default, but will provide a python3 command by default."
Debian has forced the issue by choosing the third option[2]:
"NOTE: Debian testing (bullseye) has removed the "python" package and
the '/usr/bin/python' symlink due to the deprecation of Python 2."
Switch our shebang from "#!/usr/bin/env python" to "#!/usr/bin/env
python3" in some places. Remove some 2/3 version checks if we know we're
running under Python 3. Remove the "coding: utf-8" in a bunch of places
since that's the default in Python 3.
[1]https://www.python.org/dev/peps/pep-0394/#for-python-script-publishers
[2]https://wiki.debian.org/Python
|
|
We want things like aes-256 keys to be displayed completely.
Change-Id: I746f3282440c036cfb60263be40e3b3a6ed859c2
Signed-off-by: Stefan Metzmacher <metze@samba.org>
Reviewed-on: https://code.wireshark.org/review/35703
Petri-Dish: Alexis La Goutte <alexis.lagoutte@gmail.com>
Tested-by: Petri Dish Buildbot
Reviewed-by: Anders Broman <a.broman58@gmail.com>
|
|
The new value has been chosen to make room for sharkd packet output
as: proto.c:MAX_TREE_LEVELS * 2 + 10% of additional sharkd overhead.
A new regression test for sharkd has been added that requires more
than 15 levels.
Change-Id: Ie54955c79c50c60b95c99b1a3c472888fc4842ac
Reviewed-on: https://code.wireshark.org/review/31624
Petri-Dish: Peter Wu <peter@lekensteyn.nl>
Tested-by: Petri Dish Buildbot
Reviewed-by: Peter Wu <peter@lekensteyn.nl>
|
|
Change-Id: I457613ea154a86098f536b57844ad6606c595a46
Reviewed-on: https://code.wireshark.org/review/31035
Petri-Dish: Dario Lombardo <lomato@gmail.com>
Tested-by: Petri Dish Buildbot
Reviewed-by: Dario Lombardo <lomato@gmail.com>
|
|
All request types have a corresponding test_sharkd_req_* test names
which tests the current (documented) behavior. The frame and download
tests are not very comprehensive though, but it's better than nothing.
(The original test_sharkd_hello_dhcp_pcap test is replaced by
test_sharkd_req_status and test_sharkd_req_frames, although the latter
does not literally check for the "DHCP" column anymore.)
Change-Id: Ic39b954fc50065345ac46e96a7057b7aba2a09e3
Reviewed-on: https://code.wireshark.org/review/30743
Petri-Dish: Peter Wu <peter@lekensteyn.nl>
Tested-by: Petri Dish Buildbot
Reviewed-by: Anders Broman <a.broman58@gmail.com>
|
|
Continue the conversion from use of globals (the config module) to
fixtures. If a program (like wmem_test or tshark) is unavailable, it
will be skipped now rather than failing the test.
The general conversion pattern is:
- Decorate each class with `@fixtures.uses_fixtures` and (for tests that
run tshark) `@fixtures.mark_usefixtures('test_env')`.
- Convert all `config.cmd_*` to `cmd_*` and add an argument.
- Convert all `config.*_dir` to `dirs.*_dir` and add an argument.
- Convert users of `os.path.join(dirs.capture_file, ...)` to use a new
'capture_file' fixture to reduce boilerplate code. Inline variables if
possible (this conversion was done in an automated way using regexes).
Some other changes: tests that do not require a test environment (like
wmem_test) will use 'base_env' which avoids copying config files,
`env=config.test_env` got removed since this is the default. Some test
classes in suite_clopts were combined. Removed unused imports.
Change-Id: Id5480ffaee7d8d56cf2cb3189a38ae9afa7605a1
Reviewed-on: https://code.wireshark.org/review/30591
Petri-Dish: Peter Wu <peter@lekensteyn.nl>
Tested-by: Petri Dish Buildbot
Reviewed-by: Anders Broman <a.broman58@gmail.com>
|
|
Reduces maintenance costs and makes it possible to simplify code.
pytest supports Python 2.7 and Python 3.4 (or newer), so that is more or
less the minimum target for now.
Change-Id: I0347b6c334bf2fc6c9480ff56e9ccfcd48886dde
Reviewed-on: https://code.wireshark.org/review/30193
Tested-by: Petri Dish Buildbot
Petri-Dish: Peter Wu <peter@lekensteyn.nl>
Reviewed-by: Peter Wu <peter@lekensteyn.nl>
|
|
Change-Id: I0e5049700ab9285196ce6b4567bd2d034529e763
Reviewed-on: https://code.wireshark.org/review/28327
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>
|
