This reverts commit 5df2925434.
The problem only showed up in tfshark.c, and was caused by tfshark.c
using stuff from ui/urls.h but not *including* ui/urls.h.
Normal DNS response times are in the milli-seconds range, but are currently
listed as seconds.
It is more readable when msec unit is used instead.
Also the average display is hard coded (%.2f) so under normal conditions it
is currently shown as "0.00".
With this change the average value displayed is more useful and high response
times (retransmissions) stand out more clearly.
If you use it, GCC 9.3.0 seems to think there's a missing parenthesis
somewhere, just as the version of clang++ in my version of Xcode does,
even though other versions of GCC don't. I'm clearly missing something
obscure about C here; I give up.
1) Allow AVP_DEBUGGING settings to be made from Preferences, iff compiled so.
2) Flush MATE/AVP debug output once sequential packet parse has completed.
While running a test suite of a DNS server, a lot of DNS messages on
non-standard ports were not recognized. Rather than manually discovering
and decoding every port using an iterative process of checking the
output of the `udp and not dns` filter, have some heuristics to detect
DNS messages automatically.
Enable these heuristics by default assuming that the checks are strong
enough, 8 bytes are essentially fixed to a low number of possibilities.
Should it cause issued, then the heuristics could be disabled (assuming
that non-standard DNS ports are uncommon) or strengthened.
The macOS installer works differently from the way it did when that
message was written (it's now a drag-install for Wireshark, with
separate installers for ChmodBPF and for files to add the Wireshark
binary directory to the default $PATH), and the macOS main screen now
offers a "click this to install" link, running the ChmodBPF installer,
if the user doesn't have permissions to capture. Update the message
to reflect that (although that's wrong if you directly run dumpcap or
run it via TShark - this needs to be cleaned up in some fashion).
Fix a capitalization error while we're at it.
In the code that generates the main screen message to which the dumpcap
message refers, add a comment saying that, if the main screen message
changes, dumpcap's message should also be updated.
Move the maximum number of tree items and maximum tree depth to
preferences instead of hardcoded values. Refer to issue #12584 for
an example VNC capture where real data exceeds the current limit.
* Use parameter names from draft-ietf-dnsop-svcb-https-01 to match the
presentation format. Use keyNNNNN for unknown names in the tree.
* Remove the SvcParams tree and directly display parameters under the
resource record tree. Include the parameter value as well.
* Add odohconfig (draft-pauly-dprive-oblivious-doh-02) support.
* Use the presentation format (base64) for echconfig/odohconfig values.
Instead of grabbing the set of IDBs found at open time, have a loop
using wtap_get_next_interface_description() to read all unread IDBs run
after opening the input file, after reading a packet from the input
file, and after getting an EOF on the input file.
Add a routine wtap_uses_interface_ids() to check whether the file type
and subtype for a dump file uses interface IDs and requires IDBs. If
so, in the aforementioned loop, add the IDBs to the dump stream.
Add a routine wtap_dump_add_idb() to add IDBs to a dump stream. Have it
call a file-format-specific routine to add the IDBs; the only file type
that supports it is pcapng, and it 1) writes out the IDB and 2) adds it
to the set of IDBs for the stream.
Add a wtap_dump_params_init_no_idbs() routine that prevents the IDBs
from the input file from being used to initialize the output file; use
it in cases where we're using the aforementioned loop to copy over IDBs.
Don't require any IDBs to be present when opening a pcapng file for
writing; 1) the simplest pcapng file has just an SHB in it, 2) that
requirement causes dumps that don't provide IDBs at open time to fail,
and 3) the real issue is that we don't want packets with an interface ID
not corresponding to a known IDB, and we already have a check for that.
(There are some hacks here; eventually, when everything processes the
IDBs in such a loop, we may be able to get rid of the "two favors of
dump parameter initialization" hack.)
Fixes#15844.
Addresses the same issue in #15502, but there are other issues there
that also need to be addressed.
In addition, the merge code also needs to be changed to handle this.
Fix Qt 5.15 deprecation warnings in QCustomPlot, similar to 76d92ba7e7.
Use default flags constructors instead of 0.
Use QWheelEvent::angleDelta() instead of QWheelEvent::angle().
Use QWheelEvent::position() instead of QWheelEvent::pos().
Use date::startOfDay() instead of QDateTime(date).
Use QMultiMap instead of QMap where needed.
According to [MS-FSCC] if the file has the REPARSE_TAG attribute, the
EaSize field must be interpreted as a reparse tag for the following
info levels:
* FileFullDirectoryInfo
* FileBothDirectoryInfo
* FileIdFullDirectoryInfo
* FileIdBothDirectoryInfo
From tools/check_typed_item_calls.py output:
epan/dissectors/packet-bssgp.c:655 proto_tree_add_item called for hf_bssgp_bss_area_ind - item type is FT_UINT8 but call has len 2
epan/dissectors/packet-bssgp.c:1468 proto_tree_add_item called for hf_bssgp_unit_val - item type is FT_UINT8 but call has len 3
epan/dissectors/packet-bssgp.c:1469 proto_tree_add_item called for hf_bssgp_gprs_timer - item type is FT_UINT8 but call has len 3
epan/dissectors/packet-bssgp.c:2606 proto_tree_add_item called for hf_bssgp_unit_val - item type is FT_UINT8 but call has len 3
epan/dissectors/packet-bssgp.c:2607 proto_tree_add_item called for hf_bssgp_gprs_timer - item type is FT_UINT8 but call has len 3
epan/dissectors/packet-bssgp.c:2635 proto_tree_add_item called for hf_bssgp_unit_val - item type is FT_UINT8 but call has len 3
epan/dissectors/packet-bssgp.c:2636 proto_tree_add_item called for hf_bssgp_gprs_timer - item type is FT_UINT8 but call has len 3
epan/dissectors/packet-bssgp.c:3276 proto_tree_add_item called for hf_bssgp_cell_acc_mode - item type is FT_UINT8 but call has len 4
It currently wraps wtap_block_create() and wtap_block_copy(); if there
are no remaining use cases for wtap_block_copy() at some point, it can
just *replace* wtap_block_copy().
Stig Bjørlykke