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.
Close pipe handles when spawning asynchronous processes, so only the
child process holds handle to the other end of the pipe. Closing the
handles makes it possible to use pipes the same way as on other OS, that
is to rely on blocking read() to end when child process finishes.
Do not call CloseHandle() on signal pipe in capture sync after the
handle ownership was transferred to file descriptor. Close the file
descriptor instead.
Experience has shown that:
1. The current logging methods are not very reliable or practical.
A logging bitmask makes little sense as the user-facing interface (who
would want debug but not crtical messages for example?); it's
computer-friendly and user-unfriendly. More importantly the console
log level preference is initialized too late in the startup process
to be used for the logging subsystem and that fact raises a number
of annoying and hard-to-fix usability issues.
2. Coding around G_MESSAGES_DEBUG to comply with our log level mask
and not clobber the user's settings or not create unexpected log misses
is unworkable and generally follows the principle of most surprise.
The fact that G_MESSAGES_DEBUG="all" can leak to other programs using
GLib is also annoying.
3. The non-structured GLib logging API is very opinionated and lacks
configurability beyond replacing the log handler.
4. Windows GUI has some special code to attach to a console,
but it would be nice to abstract away the rest under a single
interface.
5. Using this logger seems to be noticeably faster.
Deprecate the console log level preference and extend our API to
implement a log handler in wsutil/wslog.h to provide easy-to-use,
flexible and dependable logging during all execution phases.
Log levels have a hierarchy, from most verbose to least verbose
(debug to error). When a given level is set everything above that
is also enabled.
The log level can be set with an environment variable or a command
line option (parsed as soon as possible but still later than the
environment). The default log level is "message".
Dissector logging is not included because it is not clear what log
domain they should use. An explosion to thousands of domains is
not desirable and putting everything in a single domain is probably
too coarse and noisy. For now I think it makes sense to let them do
their own thing using g_log_default_handler() and continue using the
G_MESSAGES_DEBUG mechanism with specific domains for each individual
dissector.
In the future a mechanism may be added to selectively enable these
domains at runtime while trying to avoid the problems introduced
by G_MESSAGES_DEBUG.
Pass working directory parameter to win32_create_process() in
ws_pipe_spawn_sync().
Change-Id: I0abbc4fbf733138b20c2a34845b147530417c91e
Reviewed-on: https://code.wireshark.org/review/34533
Petri-Dish: Michael Mann <mmann78@netscape.net>
Tested-by: Petri Dish Buildbot
Reviewed-by: Michael Mann <mmann78@netscape.net>
Change all wireshark.org URLs to use https.
Fix some broken links while we're at it.
Change-Id: I161bf8eeca43b8027605acea666032da86f5ea1c
Reviewed-on: https://code.wireshark.org/review/34089
Reviewed-by: Guy Harris <guy@alum.mit.edu>
In ws_pipe_wait_for_pipe() on Windows, the WaitForMultipleObjects() waits
on the pending pipe connection events and process handle. If the process
handle is signalled, then it means that the process did exit without
connecting to the pipes.
The WaitForMultipleObjects() was not waiting on the process handle and thus
if the process did fail without connecting to pipes the Wireshark gui was
frozen for 30 seconds.
This change fixes the freeze by increasing the number of handles, so
WaitForMultipleObjects() is aware of the process handle.
Change-Id: Id13824a60baf4be7795cbe1d5ed1c7932edbff45
Reviewed-on: https://code.wireshark.org/review/33028
Reviewed-by: Gerald Combs <gerald@wireshark.org>
On Windows, ws_pipe_spawn_sync always leaks 'winargs', and leaks 'argv'
on some error paths. Fix these and refactor the common argument parsing
functionality to reduce duplication of functionality.
Change-Id: I8fa5ca45aec20b53f6fa243b0dd07241a345f7ab
Reviewed-on: https://code.wireshark.org/review/32932
Petri-Dish: Peter Wu <peter@lekensteyn.nl>
Tested-by: Petri Dish Buildbot
Reviewed-by: Tomasz Moń <desowin@gmail.com>
Reviewed-by: Peter Wu <peter@lekensteyn.nl>
The function returns a GPid, not a gboolean. Callers (mmdbresolv and
extcap) only assume WS_INVALID_PID to be invalid (as documented).
Change-Id: I40b491272a451f569864fa3259009d6d3fcce772
Fixes: v2.5.1rc0-413-g1a0987904f ("Generalize our process spawning code.")
Reviewed-on: https://code.wireshark.org/review/32933
Petri-Dish: Peter Wu <peter@lekensteyn.nl>
Tested-by: Petri Dish Buildbot
Reviewed-by: Tomasz Moń <desowin@gmail.com>
Reviewed-by: Anders Broman <a.broman58@gmail.com>
The ws_pipe_wait_for_pipe() implementation had multiple issues:
* Use auto-reset events with ConnectNamedPipe (should be manual-reset)
* Leaking event handles
* Not checking return value from CreateEvent()
* Waiting on closed handles
This change fixes all the above mentioned issues.
Bug: 15696
Change-Id: Ia0c389a902655f85eccb0c59288b4a7d49da48c9
Reviewed-on: https://code.wireshark.org/review/32896
Petri-Dish: Guy Harris <guy@alum.mit.edu>
Tested-by: Petri Dish Buildbot
Reviewed-by: Tomasz Moń <desowin@gmail.com>
Reviewed-by: Anders Broman <a.broman58@gmail.com>
Callers should not include empty strings in arguments list. Log warning
message instead of silently dropping remaining arguments.
Change-Id: Ia68c7b90cec860e032f81a4008aa005b07ebcfd5
Ping-Bug: 15586
Reviewed-on: https://code.wireshark.org/review/32849
Petri-Dish: Anders Broman <a.broman58@gmail.com>
Tested-by: Petri Dish Buildbot
Reviewed-by: Anders Broman <a.broman58@gmail.com>
This significantly reduces the initialization time when system is using
small pipe buffers. No time is lost on periodic process status checks as
WaitForMultipleObjects() returns when the stdout/stderr data was read
and/or when process finishes.
Bug: 14657
Change-Id: I61fabf986577db7102a3136df83d2d92c7156727
Reviewed-on: https://code.wireshark.org/review/32773
Petri-Dish: Anders Broman <a.broman58@gmail.com>
Tested-by: Petri Dish Buildbot
Reviewed-by: Tomasz Moń <desowin@gmail.com>
Reviewed-by: Anders Broman <a.broman58@gmail.com>
If the PATHEXT environment variable contains .py and extcap is enabled,
then Wireshark did leak 2 pipes for every .py file present in the extcap
directory (regardless if there was .bat wrapper for it or not).
Bug: 15689
Change-Id: Iae402c0075ee8155a7205a59711bbae734da7e9e
Reviewed-on: https://code.wireshark.org/review/32812
Tested-by: Petri Dish Buildbot
Reviewed-by: Guy Harris <guy@alum.mit.edu>
Extcap executables require libwsutil.dll from the program directory.
These were loaded by setting the PATH environment variable, but this
is not thread-safe (and caused sporadic tests failures as a result).
Use SetDllDirectory instead, this also prevents loading DLL files
from arbitrary directories in PATH.
To make this work, the search logic for Npcap has to be modified to
avoid relying on SetDllDirectory. This implies that Npcap cannot be
used on Windows 7 anymore until KB2533623 (July 2011) is applied.
Change-Id: I3fc42ff76e75ae162b6dd31103451fb8f71c09e6
Reviewed-on: https://code.wireshark.org/review/30804
Petri-Dish: Peter Wu <peter@lekensteyn.nl>
Tested-by: Petri Dish Buildbot
Reviewed-by: Anders Broman <a.broman58@gmail.com>
The deadlock can be observed with a slow malloc implementation, e.g.
ASAN_OPTIONS=fast_unwind_on_malloc=0 tshark --version
(This calls extcap_run_all which uses threads and ws_pipe_spawn_sync.)
Change-Id: Iff329c465c53ed177980368cd645f59222f88dd3
Reviewed-on: https://code.wireshark.org/review/30777
Petri-Dish: Peter Wu <peter@lekensteyn.nl>
Tested-by: Petri Dish Buildbot
Reviewed-by: Anders Broman <a.broman58@gmail.com>
This avoids an unnecessary explicit cast. For clarity, rename the
working directory argument to match g_spawn_sync.
Change-Id: Idf7072cd590e686294d953f77da2a52c861a89c0
Reviewed-on: https://code.wireshark.org/review/30763
Petri-Dish: Peter Wu <peter@lekensteyn.nl>
Tested-by: Petri Dish Buildbot
Reviewed-by: Anders Broman <a.broman58@gmail.com>
When Wireshark uses a synchronous spawn (e.g., to launch an extcap)
it would be nice to be able to see what command line is constructed
to launch the process, and to see what comes back. The output will
go to the g_log.
Change-Id: Iec6baeebc026cd80398084c9644fc916ab068e2f
Reviewed-on: https://code.wireshark.org/review/30475
Petri-Dish: Dario Lombardo <lomato@gmail.com>
Tested-by: Petri Dish Buildbot
Reviewed-by: Peter Wu <peter@lekensteyn.nl>
We were not calling TerminateProcess() to stop mmdbresolve.Exe process on
Windows.
Bug: 15248
Change-Id: Ic90cf438a8003a6fefb023b7056984681ce09b46
Reviewed-on: https://code.wireshark.org/review/30449
Petri-Dish: Pascal Quantin <pascal.quantin@gmail.com>
Tested-by: Petri Dish Buildbot
Reviewed-by: Anders Broman <a.broman58@gmail.com>
Check if data is available on stderr before doing a blocking read() to
avoid an infinite read loop when having less data than STDERR_BUFFER_SIZE.
Append data instead of overwrite when doing multiple read() to fetch
available data.
This is a regression from g6a949ed155.
Bug: 15205
Change-Id: I84b232aeafb6123f77f3f5d48bbe89326fe7eb0f
Reviewed-on: https://code.wireshark.org/review/30209
Petri-Dish: Stig Bjørlykke <stig@bjorlykke.org>
Tested-by: Petri Dish Buildbot
Reviewed-by: Roland Knall <rknall@gmail.com>
The Remarks section in WaitForMultipleObjects describes what kind of
handles the function can wait for. Pipe handles are not listed there.
The problem was introduced in c18459e66e
While it might be possible to setup overlapped reads on the pipe handles
and then wait on overlapped events, it would result in quite complex
code. As a tradeoff, simply keep peeking at the pipes every 100 ms.
Change-Id: I6ba4f4bf4c1d2af856027cca36ffd6d4f7f49f36
Bug: 14657
Reviewed-on: https://code.wireshark.org/review/29163
Petri-Dish: Roland Knall <rknall@gmail.com>
Tested-by: Petri Dish Buildbot
Reviewed-by: Roland Knall <rknall@gmail.com>
On Windows the code calling extcap worked as follows:
1. Create stdout and stderr pipes with default buffer size
2. Execute extcap redirecting output to the pipes
3. Wait for extcap process to exit
4. Read the data from stdout pipe
This resulted in deadlock when the extcap wrote more data than the pipe
could buffer. This was especially seen with USBPcap as it is quite
normal to have plenty of USB devices connected.
Fix the issue by contantly reading the stdout data and storing it in
GString. To prevent similar deadlock on the stderr, the stderr data is
being constantly monitored as well (and discarded).
Change-Id: I0f93e6d79617cef0e828aef2b96fad2757227923
Bug: 14657
Reviewed-on: https://code.wireshark.org/review/29159
Petri-Dish: Pascal Quantin <pascal.quantin@gmail.com>
Tested-by: Petri Dish Buildbot
Reviewed-by: Roland Knall <rknall@gmail.com>
DWORD on windows is unsigned, then there is no point in checking
for negative values.
Change-Id: I0b03fb19ebdff86e610cd4571fc30c49b7bd1284
Reviewed-on: https://code.wireshark.org/review/27766
Petri-Dish: Dario Lombardo <lomato@gmail.com>
Tested-by: Petri Dish Buildbot
Reviewed-by: Anders Broman <a.broman58@gmail.com>
Make sure we zero-initialize pipeinsts, otherwise ConnectNamedPipe will
have indeterminate behavior according to the MSDN documentation for the
OVERLAPPED structure.
Change-Id: I38d9680cf01b0a8f9e566a85a7a330f6c0aa9a48
Ping-Bug: 14532
Reviewed-on: https://code.wireshark.org/review/26784
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>
Add ws_pipe_kill_child_on_exit, which associates a child process handle
with a job object that has the JOB_OBJECT_LIMIT_KILL_ON_JOB_CLOSE
flag set.
Call it when we create a process in ws_pipe_spawn_sync and
ws_pipe_spawn_async. Note that we might want to use it elsewhere.
Change-Id: Ia0f6863ea4df0ab8623bb923a49da7776d83bd33
Reviewed-on: https://code.wireshark.org/review/26398
Petri-Dish: Gerald Combs <gerald@wireshark.org>
Tested-by: Petri Dish Buildbot
Reviewed-by: Gerald Combs <gerald@wireshark.org>
Document ws_pipe.h. Define invalid PIDs in one place.
Extcap didn't use stdin before 1a0987904f. Make sure we close it.
Change-Id: I7a69cd9b5137ae82435e64628a22e4d812d58f89
Reviewed-on: https://code.wireshark.org/review/26226
Petri-Dish: Gerald Combs <gerald@wireshark.org>
Tested-by: Petri Dish Buildbot
Reviewed-by: Gerald Combs <gerald@wireshark.org>
Move the contents of extcap_spawn to ws_pipe. Rename various extcap_*
prefixes to ws_pipe_*. Open stdin when we spawn processes.
Change-Id: I9286295443ee955bb6328b0ed6f945ee0bb2a798
Reviewed-on: https://code.wireshark.org/review/26216
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>
Ensure that wsutil/ws_pipe.c includes <sys/select.h> as as both
the timeval struct and the select function are used.
Change-Id: Idbd9e9a5b9cbee9977a423c32e55be81bb6425c3
Reviewed-on: https://code.wireshark.org/review/25616
Petri-Dish: Jaap Keuter <jaap.keuter@xs4all.nl>
Tested-by: Petri Dish Buildbot
Reviewed-by: Guy Harris <guy@alum.mit.edu>
The first is deprecated, as per https://spdx.org/licenses/.
Change-Id: I8e21e1d32d09b8b94b93a2dc9fbdde5ffeba6bed
Reviewed-on: https://code.wireshark.org/review/25661
Petri-Dish: Anders Broman <a.broman58@gmail.com>
Petri-Dish: Dario Lombardo <lomato@gmail.com>
Reviewed-by: Anders Broman <a.broman58@gmail.com>
Fix error: format '%ld' expects argument of type 'long int', but argument 4 has type 'size_t'
Change-Id: I86ec4076bb7e8c11d5cf82187a46a528bf43c514
Reviewed-on: https://code.wireshark.org/review/25109
Petri-Dish: Dario Lombardo <lomato@gmail.com>
Tested-by: Petri Dish Buildbot
Reviewed-by: Dario Lombardo <lomato@gmail.com>
Ask, in a comment, why we're doing PeekNamedPipe() when we're trying
to read everyting in the pipe, up to the EOF, into a string.
On UN*X, do the same "read up to an EOF and then NUL-terminate the
result" stuff that we did on Windows; nothing guarantees that, on all
UN*Xes, in all circumstances, until the end of time, world without end,
amen, we can do one read and get the entire string.
Change-Id: I578802b23fec1051139eaefd9a09fe2a6de06a11
Reviewed-on: https://code.wireshark.org/review/24959
Petri-Dish: Guy Harris <guy@alum.mit.edu>
Tested-by: Petri Dish Buildbot
Reviewed-by: Guy Harris <guy@alum.mit.edu>
Tomasz Moń