| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
|
|
* guint32_to_str_buf() -> uint32_to_str_buf()
* guint64_to_str_buf() -> uint64_to_str_buf()
* guint64_to_gdouble() -> uint64_to_double()
* gdouble_to_guint64() -> double_to_uint64()
* get_nonzero_guint32() -> get_nonzero_uint32()
* get_guint32() -> get_uint32()
* guint8_to_hex() -> uint8_to_hex()
|
|
GetTickCount64 has been available since Windows Vista and
Server 2008. We don't even support those anymore.
This prevents some warnings about using GetTickCount (which
wraps after 49.7 days).
|
|
Ping #19116
|
|
Only if we hae remote capture support should we give an rpcap:// URL as
an example.
|
|
|
|
Even if we're running with real and effective user ID the same,
always drop capabilities other than NET_RAW and NET_ADMIN.
Take a little bit of care to make sure that we always succeed in
dropping them, to take care of the edge case where dumpcap is missing
one of those two but has some other file capabilities it shouldn't
have.
This resolves a particular inconsistency whereby a user running
dumpcap with file capabilities but without sudo or setuid/setgid
could have greater capabilities (e.g., CAP_DAC_OVERRIDE) than
someone running the same file but with sudo, logged in as root, or
setuid/setgid. (See #7672, though this resolves the inconsistency
in the opposite direction from how the person who opened the issue
desired.)
|
|
Avoid having to set an ifdef. The logging is optimized away under
most release types.
Also free the string when debugging.
|
|
This is for, e.g., debugging purposes when running dumpcap standalone.
|
|
Support the -Q option for dumpcap wth the same behavior as tshark.
Fix #14491
|
|
Support the -F option from the command line for dumpcap and wireshark,
only supporting pcapng and pcap. Deprecate the -n and -P options.
Make the output resemble that from libwiretap, but implement it
separately because dumpcap intentionally does not link to libwiretap.
Request nanosecond time stamps for the pcap format as well; we believe
the vast majority of programs should be able to handle them at this
point. The Internet Draft of the pcap format specification treats them
as the same format:
https://datatracker.ietf.org/doc/html/draft-ietf-opsawg-pcap
For now libwiretap still treats them as different formats, which allows
converting explicitly between them; this can be used as a workaround if
someone needs to convert to the microsecond time stamp pcap format.
If someone requests nanosecond time resolution to tshark using the -F
flag, allow it.
Update the documentation.
Fix #18009
|
|
The variable used to control the autostop filesize (or filesize
at which to switch to the next file in multiple file mode) is a
32 bit unsigned integer, but it measures kB. Therefore we can easily
allow larger sizes. There is a small limitation because the QSpinBox
uses a signed integer (we could evade that by allowing larger sizes
only with MB or GB selected), but even with that, it's easy to support
2 TB, which is quite a bit larger.
We have large file support everywhere (tshark, Wireshark, libpcap,
etc.) so the size alone shouldn't be a problem. Such a very big
file might run into issues from being more than 2^31 frames in the
GUI (QTreeView uses an int for the number of rows) or 2^32 frames
viewed in tshark, but that would equally happen with *no* filesize
limit.
The autostop options, like the ring buffer options, must be greater
than zero. The GUI was only enforcing the latter. Set the minimums
for the spinboxes.
Also set maximums for the file size spinboxes, rather than popping up
a warning message when the user puts in a disallowed value. Change
the maximums depending on whether kB, MB, or GB are selected.
Fix the warning message (which shouldn't happen anymore), which was
incorrectly using binary prefixes even though the enforced maximum
value is actually a decimal/metric prefix.
Fix #5691
|
|
This wide-ranging change replaces the vast majority of instances of the "sizeof
arr / sizeof (TYPE)" pattern (and a few more "sizeof arr / sizeof var", "sizeof
arr / sizeof arr[1]", etc.) with the array_length macro.
A small number of cases of "sizeof arr / sizeof (TYPE)" remain; These appear to
be legitimate divisions of some array/variable's size by the size of some
_other_ TYPE unrelated to the array/variable type -- i.e. computing number of
records/samples which will fit in a given buffer.
A few unused variables/macros were removed instead of being updated.
Trivial formatting changes were made in a few places.
As with the previous part of this cleanup, comparison of the built object files
confirms that most of the changes have no net effect and the few actual changes
are trivial and harmless. Some changes are apparent in debug info (to be
expected), in __LINE__ values (also to be expected), and the simplification in
the opcua plugin is reflected in slightly simpler generated code.
|
|
|
|
Only check our block length if we have a block that contains packet,
log, or event data.
|
|
The C standard requires that objects with static storage duration
is initialized to zero.
|
|
|
|
Pass the Capchild log domain (dumpcap's log domain) level from
the parent to dumpcap when setting up the pipe. Move a few of
the debugging level messagesi that previously required a #define
to be set from INFO to DEBUG.
This means that
"--log-debug Capchild" or "--log-level debug" can be used to get
DEBUG level log messages sent via the sync pipe to the parent and
then the console, without having to set a #define in dumpcap.
Related to #19519
|
|
Distinguish log messages from SP_ERROR_MSG; log messages don't
necessarily represent a failure, and they have a level. This
doesn't affect logging while capturing much, as SP_ERROR_MSGs
are just printed to the console, but it makes it possible to log
while retrieving interface information or the stats, where SP_ERROR_MSG
indicates that the command failed.
|
|
Don't use stderr for the sync pipe, because third party libraries
and functions sometimes pollute stderr with other information.
Instead, pass the information necessary to dumpcap as a parameter
to the special capture child option -Z.
On UN*X, that means passing the sync pipe write file descriptor, as
the child is created by fork + exec and shares the file descriptor table.
On Windows, the child process does not share the file descriptor table,
but it does share the HANDLE value for inherited handles, so pass that
instead. (The HANDLE is a void* and technically 64 bit, but only the
lower 32 bits are used for inherited handles that can be shared
and it is permissible to truncate:
https://learn.microsoft.com/en-us/windows/win32/procthread/inheritance
https://learn.microsoft.com/en-us/windows/win32/winprog64/interprocess-communication
https://learn.microsoft.com/en-us/windows/win32/WinProg64/rules-for-using-pointers
though perhaps in the future casting to an intptr_t makes more sense.)
Move the special Windows named signal pipe to its own long option
instead of using the parameter from the capture child option.
This means that we alter argv inside sync_pipe_open_command so change
the static functions and free argv there. Once glib 2.68 and later is
required a GStrvBuilder could be used instead.
Fix #12222
|
|
Treat errors beginning with "Is the server properly installed?" similarly
to "The other host terminated the connection.", and don't tell the user
to report them as Wireshark bugs.
This should clear up at least some of the Wireshark side of #14920.
(Libpcap should do a better job of reporting errors as well, although
that will ultimately involve better libpcap APIs, for which there are
other reasons as well.)
|
|
Value stored to 'status' is never read
|
|
Allow dumpcap to have the "-D" "-L" and "-S" flags all specified.
This is a "welcome mode" that prints out the interfaces and their
capabilities, and then prints out the running statistics.
("-L" and "-S" without "-D" will just print the statistics, but
doesn't give an error.)
In capture child mode, the interface information is sent as a
message on the sync pipe before the success message; the statistics
are sent on the data pipe as usual.
Actually using this in Wireshark will be added next.
Related to #15082
|
|
Move get_pcap_failure_secondary_error_message from static
in dumpcap to capture-pcap-util-int.h This means that when
serializing the capabilities, we can just serialize the
open status enum and the open status string, and recover
the secondary status string when deserializing. This also
lets us make the secondary message a pointer to a const
char* instead of doing as much string copying.
|
|
Since we get both the non monitor mode and monitor mode
link types lists of interfaces that can support it, we can
allow the combination of retrieving the interface list and
capabilities at the same time, because we don't need the user
to specify whether to retrieve the list in or not in monitor
mode.
Allow any combination of retrieving the the interface list and
the two capability types to be retrieved, but don't allow them
in combination with the other run once arguments.
When not in machine readable mode, print the capability types
after the link lists (maybe we should interleave them). When
in machine readable mode, add them to the serialized JSON.
We don't yet pass both flags to dumpcap in capture child mode
from the other applications yet.
Related to #15082
|
|
This is slightly less efficient at the moment, but makes it easier
to change things to get and store the capabilities information
instead of repeatedly querying for it. Eventually we can retrieve
capabilities in the same dumpcap call as the interface list, and cache
the information.
|
|
Use JSON to serialize the machine readable interface list.
This removes any problems with embedded tabs in names and
descriptions, and makes it easier to later get the interface list
and the capabilities in one call (and possibly even a single call
that retrieves both and starts statistics.)
Related to #15082
|
|
Named pipes have special names on Windows
( https://learn.microsoft.com/en-us/windows/win32/ipc/pipe-names )
If we're on Windows, and the interface name given has such a name,
assume it is a pipe and don't bother retrieving the interface list.
Dumpcap and rawshark already have identical code for testing if an
interface name is a pipe. Move that into win32-utils and have
capture_opts, dumpcap, and rawshark all use the common function.
Fix #17721
|
|
But what if it fails? (Unlikely, but....)
|
|
Serialize the machine readable version of the interface capability
output as JSON, using an array to support multiple interfaces.
When querying multiple interfaces, try all of them, exit with
success (unless unexpected errors occur) and report any per-interface
errors and exit codes inside the JSON rather than stopping after
the first interface with error.
Update capture_get_if_capabilities to process the JSON. It (and
sync_if_capabilities_open) still only query a single interface at,
but this will allow modification to handle multiple interfaces at
once later.
Related to #16191, #15082
|
|
If the user gets the "failed to set hardware filter to promiscuous mode"
error, and they're running Npcap 1.71 to 1.73, recommend that they
upgrade to the current version of Npcap.
Clean up the helpful-hint generation code a bit while we're at it.
|
|
Fix misppellings in root and ui directories.
Most of these are comments, but some are in
error messages.
|
|
Some routines that are built only if libpcap 1.10.x is built with remote
capture support, but that are unconditionally declared in pcap/pcap.h,
now have stub implementations in macOS 14 that always fail and set the
error string to "not supported". (This was probably done because those
routines are now declared as "weakly linked symbols":
https://developer.apple.com/library/archive/documentation/MacOSX/Conceptual/BPFrameworks/Concepts/WeakLinking.html
om macOS 14.)
This means CMakeLists.txt finds them when you build on Sonoma, so we end
up calling them.
The only place where we didn't arrange that we *only* use them if the
device name begins with rpcap://, indicating that it's a remote-capture
URL, was the code in dumpcap that produces packet counts for the
sparklines in the Wireshark main screen. That meant that all opens
failed, and dumpcap reported that failure to Wireshark, so no sparklines
were drawn. Check for rpcap:// in that case as well, and use
pcap_open_live() if it's not present.
For all code that calls the routines in question, if the any of the
routines in question fail, check for an error string of "not supported",
and replace it with "Remote capture not supported", so as to make the
cause of failure clearer.
Fixes #19349.
|
|
Commit 549d76b931349199dcc7be365ef59501b7e02916 tweaked the log
API. Change the calls for the optional debugging that aren't
compiled by default.
|
|
|
|
Do that rather than having that code directly call
capture_interface_list(), with the programs providing their own versions
of capture_interface_list().
|
|
Give them all names beginning with sync_pipe_write_
Rename pipe_write_block() to sync_pipe_write_string_msg(), as it writes
a message containing a string, not a "block".
Add sync_pipe_write_uint_msg(), which takes an unsigned integer as an
argument and writes a message containing its value (as a string) as the
body.
Make sync_pipe_write_header() and SP_DECISIZE local to
sync_pipe_write.c, as they're no longer used outside that file.
|
|
For most link-layer header types, the DLT_ value and the LINKTYPE_ value
are the same.
For some DLT_s for which the values are *not* the same on all OSes, or
which weren't defined on some OSes, that's not the case, because, in
order to have a *single* link-layer type value to use in capture files
on *all* platforms, so that the link-layer type is the same no matter
what OS it was captured on, new values were assigned for LINKTYPE_s.
(That's why LINKTYPE_s were created in the first place.)
Therefore, we should map DLT_ values obtained from libpcap to the
corresponding LINKTYPE_ values before using the value in a pcap header
or a pcapng Interface Description Block.
Furthermore, since a pcap or pcapng file being piped to dumpcap might
have been generated by a program that doesn't do DLT_ to LINKTYPE_
mapping (the libpcap from tcpdump.org has done so for many years now,
but OpenBSD's libpcap doesn't), we map them for pcap files as well.
(pcapng files require that we not just blindly copy the pcapng file.
Other things, such as byte-swapped pcapng files, may also require that;
this needs to be looked into.)
Fixes #19230.
|
|
If we have Linux capabilities, and dumpcap gets a permission error,
suggest that the user add the CAP_NET_RAW and CAP_NET_ADMIN capabilities
that dumpcap needs if Wireshark was not installed by a package.
(Distribution packages should set the capabilities.)
Fix #18279
|
|
snprintf(), sensibly, takes a size_t argument specifying the size of the
buffer. g_snprintf(), bogusly, takes a gulong argument specifying the
size of the buffer, so we had to do casts to avoid narrowing complaints,
but we're just using snprintf() now (as we require C11 or later), and
don't need the casts any more.
|
|
When we have multiple capture sources, for each one that is a pcapng
source and supplies its own IDBs, don't create a fake IDB with invalid
linktype WTAP_ENCAP_UNKNOWN and write it to the output file.
Instead, use the IDBs from the source, remapping them as necessary.
For non-pcapng sources, store the output IDB interface ID and write
EPBs using that, since now the input interface ID and the output
interface ID are not necessarily the same, if some of the other
sources are not pcapng.
Update the capture tests that use multiple FIFO sources, because now we
don't add two extra IDBs, one for each FIFO. Instead there are
3 * 11 == 33 total IDBs.
This prevents some various incompatibilites in Wireshark and other
tools when a file has interfaces of more than one link type, and also
has IDBs with an illegal WTAP_ENCAP_UNKNOWN link type.
Fix #19080
|
|
Update the (by default #ifdef'd out) capture child log to file
handling in dumpcap for the API changes in
commit 5ceb916430427316c26455b75f07d50aaa9c147d
|
|
On Linux, look for an error message of "socket: Address family not
supported by protocol"; if we see it, that's EAFNOTSUP, which means
either that 1) your kernel doesn't have PF_PACKET support configured in
or 2) this is a Flatpak package of Wireshark that's "helpfully" been
sandboxed. Display a secondary error message indicating one of those is
likely the problem; mention the Flatpak one first, as that's more likely
than the second (if you can still configure PF_PACKET sockets out, it's
not the default, so it's unlikely to be the case).
See issue #19008.
|
|
Expand the set of CAP_DEVICE_OPEN_ errors and warnings to include
specific errors for many of the errors and warnings libpcap returns.
(This doesn't include the errors that would definitely either be
Wireshark or libpcap bugs, such as PCAP_ERROR_NOT_ACTIVATED and
PCAP_ERROR_ACTIVATED.)
Don't give "make sure you have the right permissions" secondary error
messages if we know that the error isn't a permissions error.
For the PCAP_ERROR_ codes that we handle individually, don't bother with
the pcap_statustostr() string, as it would duplicate the error message
we're providing.
For the PCAP_ERROR_ codes we *don't* handle individually, give both the
pcap_statustostr() string and the pcap_geterr() string, to give the user
as much information as possible (even if that's just so that they can
give *us* as much information as possible to figure out what the problem
is).
This should remove the "how to support packet capturing on Debian"
message for "sorry, we don't support PF_PACKET sockets" error that shows
up if either 1) your kernel doesn't have PF_PACKET support configured in
or 2) this is a Flatpak package of Wireshark that's "helpfully" been
sandboxed. See issue #19008.
|
|
This makes it explicit in the log that the program aborted
because of a logging system exception, usually configured by
the user (fatal log level or domain).
|
|
If AddressSanitizer is enabled, we build dumpcap with it, which
can be useful for catching issues - at least when run standalone.
Disable it when running in capture child mode, and ensure that the
sanitizers don't change dumpcap's exit code, since capture/capture_sync
uses the exitcode value and doesn't expect the sanitizer values.
Also disable LSan if prctl(PR_GET_DUMPABLE) is 2 on Linux, since
that means that the process will fail to run LSan and die with a
fatal error in the attempt due to not being able to ptrace. It
cannot be disabled through the normal method of using environment
variables since not being dumpable also means that /proc/self/environ
isn't readable. (LSan is able to deal with a dumpable value of 0,
temporarily setting it to 1, but not 2, because it's not allowed to
set it back to 2, due to CVE-2006-2451.)
Fix #18907
|
|
Reduce the default update interval for dumpcap to notify its parent
of new packets (or to check if we've met file duration, etc.) from
500 ms to 100 ms, and put in the capture options.
This makes the GUI appear to update more in real time rather than
in visible batches of packets.
This also reduces the amount of ring buffer space needed in cases
where we're doing dissection, and dissection is able to keep up,
but the files can be deleted before tshark gets to them because of
the notification lag. (See #1650.)
|
|
Commit e921b804d0174b2bb5a118df8b454c0dc2e69369 removed the
user data parameter from logging, so remove it here.
Explain how the debugging defines work.
If DEBUG_DUMPCAP is defined and dumpcap is a capture child, don't send
logs to stderr with normal formatting, because that will be connected to
the sync pipe. Don't send them to stdout either, because that can be
connected to a data pipe (e.g., for retrieving interface information.)
Instead, send it to stderr with the special formatting so that the
parent recognizes it.
Use va_copy if both DEBUG_DUMPCAP and DEBUG_CHILD_DUMPCAP are defined,
avoiding undefined behavior that can lead to segfaults.
Set the log level to DEBUG when running as a capture child if the
DEBUG defines are set, because sync_pipe_start doesn't pass along
log level information. If you turned on the extra #define, you
presumably want to debug.
If logging to a file, open the file before any log messages.
Get rid of a check for the log level being below the default level.
It's either redundant of a check already done in ws_log_full, or it
prevents logs from being shown when dumpcap is run standalone with
logging options.
|
|
|
|
|
