Re: [Wireshark-dev] How to properly finalize capture in a Wireshark extcap plugin?
On Nov 23, 2020, at 7:09 AM, Timmy Brolin wrote: > Reading up on it a bit, turns out there is no such thing as SIGTERM in > Windows. Correct. > There seems to exist several alternative ways of doing it in Windows. > > Such as sending WM_QUIT or WM_CLOSE on the message queue, This assumes that the program you're trying to tell to terminate *has* a message queue to which it pays attention. Extcap programs are character-mode (console) programs, not windows programs; unless there's some hidden thread that's listening to a Windows message queue in those programs, they won't see that message. > or CTRL_BREAK_EVENT via SetConsoleCtrlHandler(). According to a comment in sig_pipe_kill() in capchild/capture_sync.c: /* Remark: This is not the preferred method of closing a process! * the clean way would be getting the process id of the child process, * then getting window handle hWnd of that process (using EnumChildWind$ * and then do a SendMessage(hWnd, WM_CLOSE, 0, 0) * * Unfortunately, I don't know how to get the process id from the * handle. OpenProcess will get an handle (not a window handle) * from the process ID; it will not get a window handle from the * process ID. (How could it? A process can have more than one * window. For that matter, a process might have *no* windows, * as a process running dumpcap, the normal child process program, * probably does.) * * Hint: GenerateConsoleCtrlEvent() will only work if both processes are * running in the same console; that's not necessarily the case for * us, as we might not be running in a console. * And this also will require to have the process id. */ so that might not work either. ___ Sent via:Wireshark-dev mailing list Archives:https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] Qt warning on Windows build.
Hi Chris, Le lun. 23 nov. 2020 à 20:38, Maynard, Christopher via Wireshark-dev < wireshark-dev@wireshark.org> a écrit : > > From: Wireshark-dev On Behalf Of > Anders Broman via Wireshark-dev > > Sent: Thursday, November 19, 2020 3:50 AM > > To: wireshark-dev@wireshark.org > > Cc: Anders Broman > > Subject: [Wireshark-dev] Qt warning on Windows build. > > > > Hi, > > Currently there is one Warnimg produced for the Windows build > > > C:\Development\ewireshark\trunk\ui\qt\widgets\byte_view_text.cpp(187,38): > warning C4996: 'QFont::ForceIntegerMetrics': was declared deprecated > [C:\Development\wsbuild64\ui\qt\qtui.vcxproj] > > > > Regards > > Anders > > > > And after upgrading to Qt 5.15.2, there are more warnings, and since at > least 2 of them are treated as errors, the build now fails: > > Build FAILED. > >"D:\wireshark\builds\win64\master\Wireshark.sln" (default target) > (1) -> >"D:\wireshark\builds\win64\master\ui\qt\qtui.vcxproj.metaproj" > (default >target) (44) -> >"D:\wireshark\builds\win64\master\ui\qt\qtui.vcxproj" (default > target) ( >120) -> >(ClCompile target) -> > D:\wireshark\src\master\ui\qt\widgets\byte_view_text.cpp(187,38): > warn >ing C4996: 'QFont::ForceIntegerMetrics': was declared deprecated > [D:\wir >eshark\builds\win64\master\ui\qt\qtui.vcxproj] > > >"D:\wireshark\builds\win64\master\Wireshark.sln" (default target) > (1) -> >"D:\wireshark\builds\win64\master\ui\qt\qtui.vcxproj.metaproj" > (default >target) (44) -> >"D:\wireshark\builds\win64\master\ui\qt\qtui.vcxproj" (default > target) ( >120) -> > D:\wireshark\src\master\ui\qt\packet_list.cpp(794,46): warning > C4996: >'Qt::MidButton': MidButton is deprecated. Use MiddleButton instead > [D:\w >ireshark\builds\win64\master\ui\qt\qtui.vcxproj] > D:\wireshark\src\master\ui\qt\packet_list.cpp(794,64): warning > C4996: >'Qt::MidButton': MidButton is deprecated. Use MiddleButton instead > [D:\w >ireshark\builds\win64\master\ui\qt\qtui.vcxproj] > D:\wireshark\src\master\ui\qt\print_dialog.cpp(139,32): warning > C4996: > 'QPrinter::pageRect': Use > pageLayout().paintRectPixels(resolution()) in >stead. [D:\wireshark\builds\win64\master\ui\qt\qtui.vcxproj] > D:\wireshark\src\master\ui\qt\print_dialog.cpp(174,55): warning > C4996: > 'QPrinter::pageRect': Use > pageLayout().paintRectPixels(resolution()) in >stead. [D:\wireshark\builds\win64\master\ui\qt\qtui.vcxproj] > D:\wireshark\src\master\ui\qt\print_dialog.cpp(176,21): warning > C4996: > 'QPrinter::pageRect': Use > pageLayout().paintRectPixels(resolution()) in >stead. [D:\wireshark\builds\win64\master\ui\qt\qtui.vcxproj] > D:\wireshark\src\master\ui\qt\print_dialog.cpp(236,24): warning > C4996: > 'QPrinter::pageRect': Use > pageLayout().paintRectPixels(resolution()) in >stead. [D:\wireshark\builds\win64\master\ui\qt\qtui.vcxproj] > > >"D:\wireshark\builds\win64\master\Wireshark.sln" (default target) > (1) -> >"D:\wireshark\builds\win64\master\ui\qt\qtui.vcxproj.metaproj" > (default >target) (44) -> >"D:\wireshark\builds\win64\master\ui\qt\qtui.vcxproj" (default > target) ( >120) -> >(ClCompile target) -> > D:\wireshark\src\master\ui\qt\packet_list.cpp(794,46): error > C2220: th >e following warning is treated as an error > [D:\wireshark\builds\win64\ma >ster\ui\qt\qtui.vcxproj] > D:\wireshark\src\master\ui\qt\print_dialog.cpp(139,32): error > C2220: t >he following warning is treated as an error > [D:\wireshark\builds\win64\m >aster\ui\qt\qtui.vcxproj] > > 7 Warning(s) > 2 Error(s) > You can find a fix attempt here: https://gitlab.com/wireshark/wireshark/-/merge_requests/1011 It does not handle the warning raised by Anders though. Best regards, Pascal. ___ Sent via:Wireshark-dev mailing list Archives:https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] Qt warning on Windows build.
> From: Wireshark-dev On Behalf Of Anders > Broman via Wireshark-dev > Sent: Thursday, November 19, 2020 3:50 AM > To: wireshark-dev@wireshark.org > Cc: Anders Broman > Subject: [Wireshark-dev] Qt warning on Windows build. > > Hi, > Currently there is one Warnimg produced for the Windows build > C:\Development\ewireshark\trunk\ui\qt\widgets\byte_view_text.cpp(187,38): > warning C4996: 'QFont::ForceIntegerMetrics': was declared deprecated > [C:\Development\wsbuild64\ui\qt\qtui.vcxproj] > > Regards > Anders > And after upgrading to Qt 5.15.2, there are more warnings, and since at least 2 of them are treated as errors, the build now fails: Build FAILED. "D:\wireshark\builds\win64\master\Wireshark.sln" (default target) (1) -> "D:\wireshark\builds\win64\master\ui\qt\qtui.vcxproj.metaproj" (default target) (44) -> "D:\wireshark\builds\win64\master\ui\qt\qtui.vcxproj" (default target) ( 120) -> (ClCompile target) -> D:\wireshark\src\master\ui\qt\widgets\byte_view_text.cpp(187,38): warn ing C4996: 'QFont::ForceIntegerMetrics': was declared deprecated [D:\wir eshark\builds\win64\master\ui\qt\qtui.vcxproj] "D:\wireshark\builds\win64\master\Wireshark.sln" (default target) (1) -> "D:\wireshark\builds\win64\master\ui\qt\qtui.vcxproj.metaproj" (default target) (44) -> "D:\wireshark\builds\win64\master\ui\qt\qtui.vcxproj" (default target) ( 120) -> D:\wireshark\src\master\ui\qt\packet_list.cpp(794,46): warning C4996: 'Qt::MidButton': MidButton is deprecated. Use MiddleButton instead [D:\w ireshark\builds\win64\master\ui\qt\qtui.vcxproj] D:\wireshark\src\master\ui\qt\packet_list.cpp(794,64): warning C4996: 'Qt::MidButton': MidButton is deprecated. Use MiddleButton instead [D:\w ireshark\builds\win64\master\ui\qt\qtui.vcxproj] D:\wireshark\src\master\ui\qt\print_dialog.cpp(139,32): warning C4996: 'QPrinter::pageRect': Use pageLayout().paintRectPixels(resolution()) in stead. [D:\wireshark\builds\win64\master\ui\qt\qtui.vcxproj] D:\wireshark\src\master\ui\qt\print_dialog.cpp(174,55): warning C4996: 'QPrinter::pageRect': Use pageLayout().paintRectPixels(resolution()) in stead. [D:\wireshark\builds\win64\master\ui\qt\qtui.vcxproj] D:\wireshark\src\master\ui\qt\print_dialog.cpp(176,21): warning C4996: 'QPrinter::pageRect': Use pageLayout().paintRectPixels(resolution()) in stead. [D:\wireshark\builds\win64\master\ui\qt\qtui.vcxproj] D:\wireshark\src\master\ui\qt\print_dialog.cpp(236,24): warning C4996: 'QPrinter::pageRect': Use pageLayout().paintRectPixels(resolution()) in stead. [D:\wireshark\builds\win64\master\ui\qt\qtui.vcxproj] "D:\wireshark\builds\win64\master\Wireshark.sln" (default target) (1) -> "D:\wireshark\builds\win64\master\ui\qt\qtui.vcxproj.metaproj" (default target) (44) -> "D:\wireshark\builds\win64\master\ui\qt\qtui.vcxproj" (default target) ( 120) -> (ClCompile target) -> D:\wireshark\src\master\ui\qt\packet_list.cpp(794,46): error C2220: th e following warning is treated as an error [D:\wireshark\builds\win64\ma ster\ui\qt\qtui.vcxproj] D:\wireshark\src\master\ui\qt\print_dialog.cpp(139,32): error C2220: t he following warning is treated as an error [D:\wireshark\builds\win64\m aster\ui\qt\qtui.vcxproj] 7 Warning(s) 2 Error(s) - Chris CONFIDENTIALITY NOTICE: This message is the property of International Game Technology PLC and/or its subsidiaries and may contain proprietary, confidential or trade secret information. This message is intended solely for the use of the addressee. If you are not the intended recipient and have received this message in error, please delete this message from your system. Any unauthorized reading, distribution, copying, or other use of this message or its attachments is strictly prohibited. ___ Sent via:Wireshark-dev mailing list Archives:https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] wireshark capture/filtering question
>Message: 1 >Date: Fri, 20 Nov 2020 17:43:33 -0800 >From: Guy Harris >To: Developer support list for Wireshark >Subject: Re: [Wireshark-dev] wireshark capture/filtering question >Message-ID: <31e12e1e-224b-4223-af81-659e1b6bf...@sonic.net> >Content-Type: text/plain; charset=us-ascii > >On Nov 20, 2020, at 11:02 AM, John Dill wrote: > >> Not exactly. What I'm looking to do is to merge our existing 1553 capture >> C code and wireshark capture code (inspired from tshark or dumpcap) into >> the same application. >> >> The 1553 data part would get passed records as is over a TCP socket to a >> dashboard application for display (not injected into Wireshark). This >> application interfaces with a PCMCIA card and the 1553 data is stored >> in a queue of fixed length records. Those records are then read and >> streamed by a C program using TCP packets to a dashboard application >> that reads them, decodes all the data fields and puts them on a GUI for >> display. > >OK, so what programs are involved here? > >Is the PCMCIA card something that plugs into the (presumably) MIL-STD-1553 >serial bus and captures traffic from it? First off, I appreciate the time spent in your response. Sorry, I don't know how far into the weeds to go with this, but I'll do my best. Thanks for your patience in advance. The MIL-STD-1553 interface is an avionics 10 MHz serial data bus that has its own message interface. All the equipment is connected via BNC connectors to bus terminals. There is a central application called the Bus Controller that schedules messages between various avionics devices. The serial bus is shared between all avionics, so each message is seen by all the devices, but unless the message remote terminal (RT) address matches the avionics device, the message is ignored. The PCMCIA card is able to read the 10 MHz waveform and save these messages into the local vendor's "frame" format. Most vendors provide a standard bus monitor program that reads the message data from the PCMCIA card, but they don't have a mechanism to translate the data into engineering units for display. They have an application library that takes care of the low level device driver issues to read 1553 packets into their vendor "frame" format. They typically provide several proof of concept tasks that you can perform with their 1553 card using their API, but nothing complex enough to be really useful. >If so, is that what your existing 1553 capture C code reads from? The 1553 capture C code reads from a Excalibur Systems EXC-1553 PCMCIA/EP card. It is a custom written application that reads 1553 messages in the vendor "frame" format using the vendor provided 1553 library, and has the capability to write the messages to disk, or to send the 1553 messages as packets over TCP to a Java based dashboard application for display. So far, all of this code is written in house (and was not written by me either). >What program sends those records on a TCP socket? Is that the existing C code? The existing in house capture application sends 1553 messages over a custom protocol using the TCP as the connection layer. It doesn't send TCP data until a client application establishes a connection. After the dashboard initiates a socket connection, there is a simple control protocol to the 1553 capture application to start and stop sending 1553 traffic to the dashboard application. >What program reads from the TCP socket? The dashboard application? The dashboard (Java) application reads 1553 packet frames sent from the capture application (C). >And are you describing the code that exists *now*, or the code you're talking >about that, in some fashion, includes some Wireshark code? There is no Wireshark code at this point, it's all completely in-house built software. This is how the code functions now. As an aside, the PCMCIA operates in a Bus Monitor mode, which means it's not supposed to interact in any way with the existing avionics devices on the 1553 bus. >> This application is also capable of writing captured 1553 data >> in fixed length records to a file. The application can also load a 1553 data >> capture file and streaming the records to the dashboard application to >> simulate a playback of a flight at varying playback speeds. > >> The packet part of the data would be captured from a mirror port and >> get filtered by the bpf capabilities to eliminate packets of non-interest, > >BPF doesn't know anything about MIL-STD-1553. You could write BPF filter >language expressions that test fields at particular offsets (or >generate your own BPF machine code), but that would only require a small >part of libpcap's capability - it wouldn't require any Wireshark code at all. > >Or do you mean using BPF to filter TCP packets arriving over, for example, >Ethernet? At the core of this avionics platform is an ethernet switched network. The main operational flight program has its own internal 1553 interface and acts as the Bus
Re: [Wireshark-dev] How to properly finalize capture in a Wireshark extcap plugin?
The signal handler is called when extcap is executed stand-alone, and killed
with Ctrl+C (SIGINT).
But the signal handler is not called when Wireshark executes the extcap.
I have not tried the code in unix. I have no unix machine around.
Reading up on it a bit, turns out there is no such thing as SIGTERM in Windows.
Sources:
https://maruel.ca/post/python_windows_signal/
https://stackoverflow.com/questions/38300117/why-doesnt-sigterm-works-on-windows
There seems to exist several alternative ways of doing it in Windows.
Such as sending WM_QUIT or WM_CLOSE on the message queue, or CTRL_BREAK_EVENT
via SetConsoleCtrlHandler().
Or using SIGINT instead.
I guess Wireshark is in fact not using SIGTERM on windows, since that seems to
be impossible.
So the question is, which of the other methods does Wireshark use to stop the
extcap on Windows?
From: Wireshark-dev On Behalf Of Dario
Lombardo
Sent: den 23 november 2020 14:31
To: Developer support list for Wireshark
Subject: Re: [Wireshark-dev] How to properly finalize capture in a Wireshark
extcap plugin?
Indeed the used signal to terminate the extcap is SIGTERM.
Is your signal handler called? Did you run a debugger to see which signal is
interrupting your code?
Did you try your code on unix?
On Mon, Nov 23, 2020 at 10:31 AM Timmy Brolin mailto:t...@hms.se>>
wrote:
I am writing a extcap plugin for Wireshark (Windows version). The documentation
on how Wireshark stops a extcap capture is a bit sketchy, but it seems it
simply terminates the extcap plugin.
If I run the extcap binary standalone, and stops it with Ctrl+C, everything
works as expected. The written pcapng file contains all blocks. But when
Wireshark runs the extcap binary, the last block, the "interface statistics
block", never shows up in the Wireshark capture.
Is this a bug in Wireshark? Does Wireshark ignore any additional blocks in the
pcapng fifo after it has sent the signal to kill the extcap binary?
The essential parts of the extcap plugin looks like this:
static volatile int keepRunning = 1;
void intHandler(int dummy) {
keepRunning = 0;
}
int main(int argc, char *argv[])
{
... Parse arguments ...
fp = fopen (pcOutputFilename, "wb");
fwrite( , sizeof(sSHB), 1, fp ); // write section header block to
pcapng file.
fwrite( , sizeof(sIDB), 1, fp ); // write interface description block
to pcapng file.
signal(SIGINT, intHandler);
signal(SIGTERM, intHandler);
do{
... Capture frames and write to fp ...
}
while( keepRunning );
fwrite( , sizeof(sISB), 1, fp ); // write interface statistics block to
pcapng file.
fclose(fp);
}
Regards,
Timmy Brolin
___
Sent via:Wireshark-dev mailing list
mailto:wireshark-dev@wireshark.org>>
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
--
Naima is online.
___
Sent via:Wireshark-dev mailing list
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] How to properly finalize capture in a Wireshark extcap plugin?
Indeed the used signal to terminate the extcap is SIGTERM.
Is your signal handler called? Did you run a debugger to see which signal
is interrupting your code?
Did you try your code on unix?
On Mon, Nov 23, 2020 at 10:31 AM Timmy Brolin wrote:
> I am writing a extcap plugin for Wireshark (Windows version). The
> documentation on how Wireshark stops a extcap capture is a bit sketchy, but
> it seems it simply terminates the extcap plugin.
>
> If I run the extcap binary standalone, and stops it with Ctrl+C,
> everything works as expected. The written pcapng file contains all blocks.
> But when Wireshark runs the extcap binary, the last block, the "interface
> statistics block", never shows up in the Wireshark capture.
>
> Is this a bug in Wireshark? Does Wireshark ignore any additional blocks in
> the pcapng fifo after it has sent the signal to kill the extcap binary?
>
> The essential parts of the extcap plugin looks like this:
>
>
>
> static volatile int keepRunning = 1;
>
> void intHandler(int dummy) {
>
> keepRunning = 0;
>
> }
>
>
>
> int main(int argc, char *argv[])
>
> {
>
>... Parse arguments ...
>
>
>
>fp = fopen (pcOutputFilename, "wb");
>
>fwrite( , sizeof(sSHB), 1, fp ); // write section header block to
> pcapng file.
>
>fwrite( , sizeof(sIDB), 1, fp ); // write interface description block
> to pcapng file.
>
>
>
>signal(SIGINT, intHandler);
>
>signal(SIGTERM, intHandler);
>
>
>
>do{
>
> ... Capture frames and write to fp ...
>
>}
>
>while( keepRunning );
>
>
>
>fwrite( , sizeof(sISB), 1, fp ); // write interface statistics block
> to pcapng file.
>
>
>
>fclose(fp);
>
> }
>
>
>
>
>
>
>
> Regards,
>
> Timmy Brolin
>
>
> ___
> Sent via:Wireshark-dev mailing list
> Archives:https://www.wireshark.org/lists/wireshark-dev
> Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
> mailto:wireshark-dev-requ...@wireshark.org
> ?subject=unsubscribe
--
Naima is online.
___
Sent via:Wireshark-dev mailing list
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
[Wireshark-dev] How to properly finalize capture in a Wireshark extcap plugin?
I am writing a extcap plugin for Wireshark (Windows version). The documentation
on how Wireshark stops a extcap capture is a bit sketchy, but it seems it
simply terminates the extcap plugin.
If I run the extcap binary standalone, and stops it with Ctrl+C, everything
works as expected. The written pcapng file contains all blocks. But when
Wireshark runs the extcap binary, the last block, the "interface statistics
block", never shows up in the Wireshark capture.
Is this a bug in Wireshark? Does Wireshark ignore any additional blocks in the
pcapng fifo after it has sent the signal to kill the extcap binary?
The essential parts of the extcap plugin looks like this:
static volatile int keepRunning = 1;
void intHandler(int dummy) {
keepRunning = 0;
}
int main(int argc, char *argv[])
{
... Parse arguments ...
fp = fopen (pcOutputFilename, "wb");
fwrite( , sizeof(sSHB), 1, fp ); // write section header block to
pcapng file.
fwrite( , sizeof(sIDB), 1, fp ); // write interface description block
to pcapng file.
signal(SIGINT, intHandler);
signal(SIGTERM, intHandler);
do{
... Capture frames and write to fp ...
}
while( keepRunning );
fwrite( , sizeof(sISB), 1, fp ); // write interface statistics block to
pcapng file.
fclose(fp);
}
Regards,
Timmy Brolin
___
Sent via:Wireshark-dev mailing list
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
