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>
Peter Wu