wireshark/rawshark.c:1239:15: warning: ‘fs_ptr’ may be used
uninitialized in this function [-Wmaybe-uninitialized]
printf(" %d=\"%s\"", cmd_line_index, fs_ptr);
^
wireshark/rawshark.c:1120:26:
note: ‘fs_ptr’ was declared here
char *fs_ptr;
^
Actually output the packet count for HTTP response status codes,
and align the columns between requests and response. (This CLI-only
stat is largely redundant with http,tree but it might as well work.)
This should allow simultaneous logging to the console and the log
file when running an extcap from the CLI.
One difference is that the extcap error/warning dialogs in the GUI
have extra information in standard wslog format (may or may not
be a good thing).
Remove the update_tools_help target. Despite the comment, the weekly
update job doesn't use it, we don't have targets for our other update
scripts, and it currently causes issues if BUILD_tshark is disabled.
Fixes#17766.
If we have a log file write everything to the file, to provide
a complete picture in the log.
Debug information cannot be written to the parent process when
running in child mode.
This matches the original implementation and allows displaying
logs to the console, including debug information, when running
an extcap from the CLI for testing and development purposes.
This should make extcap logging bug-for-bug compatible with the
behavior before dc7f0b88bb.
Imitate the GLib logic for selecting the console output stream
according to the log level. Levels MESSAGE and above go to
stderr. INFO and below go to stdout, unless stderr is chosen
using ws_log_console_writer_set_use_stderr().
It turns out some old extcap code was subtly dependending
on this behavior.
QUIC V1 keys/constants are defined in draft-33; draft-34 only contains
minor editorial changes.
Nonetheless, some QUIC implementations (i.e. picoquic) announce draft-33
and draft-34 versions in their VN Transport Parameter.
For example see packet 2 in the trace attached to 968fe6ddba.
dissector shows "Unknown command" for many packets summary despite
being able to dissect it properly in the tree item added in that
function. Add offset to match the tree item offset few lines below.
After the recent updates, the `process_app1_segment` function has grown very
large. Split it into three functions and make some extra improvements:
* Indent continuation lines consistently.
* Give variables more descriptive names (e.g. no more `val_16`, `val_32`).
* Remove the need to do arithmetic with the `tiff_start` (and the variable
itself) by using a subset TVB for the TIFF data.
* Remove unnecessary return values.
* Make miscellaneous style improvements.
There should be no difference in behavior, except that the error message
associated with `ei_next_ifd_offset` now shows the correct number (previously
the number was `offset + tiff_start`, when it should have been
`offset - tiff_start`; with the removal of `tiff_start` this bug got fixed
by itself).
Without this, the simple stat tables default to sorting by the first
column in descending order. (An artifact of the QTreeWidget that they
inherit from.) The first column is generally a message type (integer or
string) and ascending order makes more sense.
Some of the stat tables intentionally insert rows in a preferred order
that is different than sorting by the first column (e.g, ANSI A I/F tables
are sorted by the second column), but we can't tell what that is.
QTreeWidget only allows the data to be shown in its original unsorted
order if the widget is marked unsortable, but then the user isn't allowed
to sort at all, and being able to sort by other columns (such as count)
is useful.
The row number to lookup in the stat table is the index retrieved
from my_try_val_to_str_idx, not the original message type.
Ticks the counts in the correct rows of the stats table, and
prevents failed assertions and program halt in stat_tap_ui.c when
getting a message type with a number greater than the number of
rows in the table.
João Valverde