That reduces the number of get_progfile_dir() calls, leaving only the
calls that are done either to 1) get the pathname in order to display it
or 2) get the pathname in order to reset the library path.
That makes it easier to figure out which get_progfile_dir() calls are
made to find the directory in which (non-extcap) binaries from Wireshark
are installed and which - if any - are made to figure out the directory
in which *the currently-running executable* are stored. (Currently,
get_progfile_dir() attemps to get the former, not the latter, so
extcaps in an extcap subdirectory, for example, will get the parent
directory of that subdirectory, *not* the directory in which they weere
installed.)
If our program file directory has a trailing "/extcap" or "\extcap",
trim it off. This should let extcaps determine the proper data file and
plugin directories. Fixes#15592.
If a field name has been written to the json dumper for
a bytes element (Base64), then a Base64 value must be written
later, even if the value is zero length.
Move the JSON_DUMPER_FLAGS_NO_DEBUG flag to the json_dumper header,
and use it in the protobuf dissector, so that errors in the JSON
dumper state transitions do not abort the application through a
ws_error() call. Use DISSECTOR_ASSERT in that case, since it should
happen only with a dissector bug (as with the zero bytes elements
issue fixed here), not with malformed packets.
Only instantiate the json_dumper and create its output string if
we intend on displaying its output, instead of doing so whenever
we have a message type name.
Fix#18730.
Fix up commit 1eeb0c9934
At initial startup, the hash of configuration files used
by profiles doesn't exist yet or is not completely filled.
(Files are only added to the list after initially parsing
the current configuration.)
So, if copying a global profile to the personal directory
at initial startup, just copy all the files from the global
profile.
Also, don't free to_dir and from_dir if we're returning them
in the case of errors.
Disable UTF-8 debug checks for release builds for optimization
purposes.
Also remove unused macro that currently lacks a proper use case.
Change version info to be more complete about the build type without
being too verbose.
Instead of creating a temp file, unlinking it, and creating a fifo with
the same name, add create_tempdir() so that we can create a temporary
directory and create a fifo inside that.
This should avoid a race condition in Carbon Black Cloud antivirus,
which if the timing is right, will stat the initial temporary *file*,
miss the fact that it's been replaced with a *fifo*, and open and steal
data^W^W read from it, leaving dumpcap to contend with the truncated
remains.
Adding the unexpected magic number to cap_pipe_open_live()'s error
message helped to debug this. Leave it in since it's handy to have in
that case.
Ping #15587
This parameter was introduced as a safeguard for bugs
that generate an unbounded string but its utility for
that purpose is doubtful and the way it is being used
creates problems with invalid truncation of UTF-8
strings.
Rename wmem_strbuf_sized_new() with a better name.
Only dissectors are using this function and there is no use case,
as far as I know, that requires its use. Any limitation of length
is imposed transparently by the UI backend.
This function is problematic because it is not Unicode aware and
will truncate a string on an arbitrary byte boundary for multibyte
strings.
Replace its use with a normal strbuf without a length limite and
remove the function because it is not useful and the ITEM_LABEL_LENGTH
parameter does not belong in wmem anyway.
This change adds a protocol dissector for the Management Component
Transport Protocol (MCTP). This is a failry simple datagram-based
protocol for messaging between components within a single platform,
typically over I2C, serial or PCIe.
This dissector just implements the header fields, and sequence-number
based message reassembly. Inner protocols will be added as follow-up
changes.
Linux has support for AF_MCTP data, so decode from the MCTP SLL ltype.
Signed-off-by: Jeremy Kerr <jk@codeconstruct.com.au>
If a character is not a valid Unicode codepoint, i.e. one of
the code points reserved for surrogate pairs or a code point
above 0x10FFFF, don't add it to a wmem_strbuf when converting
from other encodings but add a replacement character instead, by
using a new wmem_strbuf_append_unichar_validated() function.
Now we produce valid UTF-8 in various situations where UCS-2 or UTF-32
can encode unpaired surrogate codepoints. Consolidate some related
checks that are now redundant.
Also add a replacement character to the end of invalid UCS-2 strings
with an odd number of bytes, as done with UTF-16 and UTF-32.
Fix#18508
Add UNICODE_REPLACEMENT_CHARACTER as a #define for the Unicode
REPLACEMENT CHARACTER code point (0x00FFFD), and use that instead of
0xfffd/0xFFFD/0x00FFFD in cases where that value refers to REPLACEMENT
CHARACTER.
Rewrite for speed and correctness.
This implementation is more strict with invalid
first bytes (continuation bytes, invalid codepoints and
some overlong sequences).
Returns 0 instead of -1 for invalid bytes.
Add a convenience function to truncate a UTF-8 string to no more
than certain length, while ensuring that the string ends with
a complete character instead of a partial sequence (by truncating
up to 3 additional bytes as necessary.)
The common use case is when a valid UTF-8 string is copied into
a buffer via snprintf, strlcpy, or strlcat and truncated, to fix
up the end of the string and keep the string valid.
The buffer holding the string must be large enough, and the string
must be valid up to the point of truncation (aside from the possible
partial sequence at the end). For speed, the function does not check
those conditions.
Ping #18412.
This removes the last dependency of the logging subsystem on the
preferences module. The latter is started much later than the former
and this is an issue.
The Windows-only preference "gui.console_open" is stored in the
registry as HKEY_LOCAL_USER\Software\Wireshark\ConsoleOpen. The semantics
are exactly the same. The preference is read by the logging subsystem
for initialization and then again by the preferences (read/write) so
the user can configure it as before.
The code to store the preference also in the preferences file was
kept, for backward compatibility and because it is not incompatible
with using the Registry concurrently.
The elimination of the prefs dependency also allows moving the Windows
console logic to wsutil and add the functionality to wslog directly,
thereby eliminating the superfluous Wireshark/Logray custom log handler.
To be able to read the ws_log_console_open global variable from
libwireshark it becomes necessary to add a new export macro
symbol called WSUTIL_EXPORT.
Add a command line option --log-fatal-domains= and environment variable
WIRESHARK_LOG_FATAL_DOMAINS that aborts the programs if a domain in
the list is logged to.
Negative matches for fatal log domains not implemented for now,
pending a relevant use-case.
For some programs (e.g: unit tests) we want to init the logging
subsystem but having to pass an error output handler is overkill
and annoying.
In that case with a NULL handler printing to stderr by default is
almost certainly the best thing to do.
wmem_strbuf_grow should set the correct size with regard to max_size,
if set. In any case passing the actual free "raw" size to g_strlcpy is
always the correct thing to do.
Use length and size consistently. strbuf->len does not
include the terminating nul. strbuf->alloc_len includes
the terminating nul.
Use consistent language and use "length" to mean size without
nul byte and "size" to mean size with all bytes, including nul.
Some older dissectors that predate Unicode and parse text protocols
are prone to generate invalid UTF-8 strings. This is a bug and can have
safety implications.
For example passing invalid UTF-8 to proto_tree_add_string() is a
common bug. There are safeguards in format_text() but this should
not be relied on as a general solution to the problem.
For one, as the name implies, it is only used with representation of a
field value, which is not the same as the value itself of an FT_STRING field.
Issue #18317 shows another reason why.
For now this compile flag only enables extra checks for string ftypes,
which covers a subset of proto.h APIs including
proto_tree_append_string(). Later is should be extended to other
interfaces.
This is also not expected to be disabled for release builds because
there are still many dissectors that do not correctly handle strings.
More work is needed to 1) identify them and 2) fix them.
Ping #18317
Like wmem_map_remove(), this frees the key/value pair item
in the map but not the key or the value itself (which may
in fact be the same object.) Not generally a problem, as
they'll get freed by the pool. (If someone wants to manage
memory themselves, they should probably be using a GHashTable.)
A given protocol's packet format may depend, for example, on which
lower-level protocol is transporting the protocol in question. For
example, protocols that run atop both byte-stream protocols such as TCP
and TLS, and packet-oriented protocols such as UDP or DTLS, might begin
the packet with a length when running atop a byte-stream protocol, to
indicate where this packet ends and the next packet begins in the byte
stream, but not do so when running atop a packet-oriented protocol.
Dissectors can handle this in various ways:
For example, the dissector could attempt to determine the protocol over
which the packet was transported.
Unfortunately, many of those mechanisms do so by fetching data from the
packet_info structure, and many items in that structure act as global
variables, so that, for example, if there are two two PDUs for protocol
A inside a TCP segment, and the first protocol for PDU A contains a PDU
for protocol B, and protocol B's dissector, or a dissector it calls,
modifies the information in the packet_info structure so that it no
longer indicates that the parent protocol is TCP, the second PDU for
protocol A might not be correctly dissected.
Another such mechanism is to query the previous element in the layers
structure of the packet_info structure, which is a list of protocol IDs.
Unfortunately, that is not a list of earlier protocols in the protocol
stack, it's a list of earlier protocols in the dissection, which means
that, in the above example, when the second PDU for protocol A is
dissected, the list is {...,TCP,A,B,...,A}, which means that the
previous element in the list is not TCP, so, again, the second PDU for
protocol A will not be correctly dissected.
An alternative is to have multiple dissectors for the same protocol,
with the part of the protocol that's independent of the protocol
transporting the PDU being dissected by common code. Protocol B might
have an "over a byte-stream transport" dissector and an "over a packet
transport" dissector, with the first dissector being registered for use
over TCP and TLS and the other dissector being registered for use over
packet protocols. This mechanism, unlike the other mechanisms, is not
dependent on information in the packet_info structure that might be
affected by dissectors other than the one for the protocol that
transports protocol B.
Furthermore, in a LINKTYPE_WIRESHARK_UPPER_PDU pcap or pcapng packet for
protocol B, there might not be any information to indicate the protocol
that transports protocol B, so there would have to be separate
dissectors for protocol B, with separate names, so that a tag giving the
protocol name would differ for B-over-byte-stream and B-over-packets.
So:
We rename EXP_PDU_TAG_PROTO_NAME and EXP_PDU_TAG_HEUR_PROTO_NAME to
EXP_PDU_TAG_DISSECTOR_NAME and EXP_PDU_TAG_HEUR_DISSECTOR_NAME, to
emphasize that they are *not* protocol names, they are dissector names
(which has always been the case - if there's a protocol with that name,
but no dissector with that name, Wireshark will not be able to handle
the packet, as it will try to look up a dissector given that name and
fail).
We fix that exported PDU dissector to refer to those tags as dissector
names, not protocol names.
We update documentation to refer to them as DISSECTOR_NAME tags, not
PROTO_NAME tags. (If there is any documentation for this outside the
Wireshark source, it should be updated as well.)
We add comments for calls to dissector_handle_get_dissector_name() where
the dissector name is shown to the user, to indicate that it might be
that the protocol name should be used.
We update the TLS and DTLS dissectors to show the encapsulated protocol
as the string returned by dissector_handle_get_long_name(); as the
default is "Application Data", it appeaers that a descriptive name,
rather than a short API name, should be used. (We continue to use the
dissector name in debugging messages, to indicate which dissector was
called.)
Strip the timestamps and function names from extcap errors before
displaying them in a dialog. This keeps us from spewing
```
Error by extcap pipe: ** (falcodump:24913) 15:08:20.263535 [falcodump
WARNING] extcap/falcodump.cpp:593 -- main(): cloudtrail plugin error:
failed to list objects: ExpiredToken: The provided token has expired.
status code: 400, request id: M2PYJOT4JGVAA6B9, host id:
+4V8Q+DGV+80Jd3fdc7tODyVdTRvepNgCD9zuvXeL7kzvp2oikaoi9CLMW+UKt/
aR1G2UXIqyQ8=
```
at the user.
Check for warning messages and set our dialog type accordingly.
Windows processes inherit all inheritable handles when a new process is
created using CreateProcess() with bInheritHandles set to TRUE. This can
lead to undesired object lifetime extension. That is, the child process
will keep ineritable handles alive even if it does not use them. Up to
Windows Vista it was not possible explicitly list handles that should be
inherited. Wireshark no longer works on Windows releases earlier than
Vista, so use the new API without checking Windows version.
Require all callers to win32_create_process() to pass in the list of
handles to inherit. Set the listed handles as inheritable shortly before
calling CreateProcess() and set them as not inheritable shortly after
the process is created. This minimizes possibility for other callers
(especially in 3rd party libraries) to inherit handles by accident.
Do not terminate mmdbresolve process on exit. Instead rely on process
exit when EOF is received on standard input. Previously the EOF was
never received because mmdbresolve inherited both ends of standard input
pipe, i.e. the fact that Wireshark closed the write end was not observed
by mmdbresolve because mmdbresolve kept write handle the standard input
pipe open.
The semantics behind ws_pipe_close() were broken since its introduction.
Forcing process termination on Windows, while simply setting variable on
other systems results in more OS specific code sprinkled all over the
place instead of less. Moreover ws_pipe_close() never handled standard
file handles. It is really hard to come up with sensible ws_pipe_close()
replacement, as process exit is actually asynchronous action. It is
recommended to register child watch using g_child_watch_add() instead.
Do not call ws_pipe_close() when deleting capture interface. Things will
break if extcap is still running when interface opts are being freed and
terminating process won't help.
Rework maxmind shutdown to rely on GIOChannel state. For unknown reason
TerminateProcess() is still needed on Windows. The actual root cause
should be identified and fixed instead of giving up hope that it will
ever work correctly on Windows. In other words, TerminateProcess()
should not be used as a pattern, but rather as a last resort.
Remove ws_read_string_from_pipe() as this function encourages bad design
and is no longer necessary. Extcap stderr is read only after the child
process has finished and thus the read will never block.
Close process information thread handle right away as we don't use it.
Remove unused ws_pipe_t member variables.
Guy Harris