Hi,
On Sat, Aug 6, 2022 at 1:09 PM Jirka Novak <j.no...@netsystem.cz> wrote:
Extcap API:
i) When extcap is started, dumpcap pass name of pipe to it and where it
expects captured data.
ii) STDOUT/STDERR is used to report messages/errors of extcap to
wireshark, but it is shown/evaluated at the end of capture which
triggers e.g. #17827. STDIN is closed/not used.
STDOUT/STDERR is now (!7673 [1]) read during capture. STDOUT is
ignored, like it always was. STDERR is collected for later use.
It works, thank you.
Now I want to implement graceful shutdown. I mean that wireshark
notify extcap it should end, cleanup and terminates. If extcap do not
finish graceful shutdown in time (timer), it is killed as before.
I checked latest changes in master and I made additional research... I
see multiple options how to implement graceful shutdown and I propose we
should agree on common direction or at least discuss options.
Lets split the issue in two parts - *nix like systems and Windows/Win32 API.
For *nix like systems changes from !7673 works fine. SIGTERM is send 30
seconds before SIGKILL is sent. So extcap has 30 seconds for graceful
shutdown. If the shutdown is faster than 30 seconds, it makes no issue
to wireshark (no 30 seconds UI hang or so).
If extcap do not require graceful shutdown or do not support it, SIGTERM
is not handled and it will kill extcap immediately.
In !5489 I made extcap/extcap-base.[ch] library calls which allows any C
based extcap to use it. But I plan to extract it to different MR...
For Windows/Win32 we still have no solution. There are two MRs -
!2063 and !5489.
1) !2063 tries to use Win32 WM_CLOSE signal.
2) !5489 tries to use named pipe to pass information from wireshark to
extcap (same way as wireshark controls dumpcap nowadays).
3) I'm non Win32 specialist, but it looks there is another option -
Windows Event Objects (see
https://docs.microsoft.com/en-us/previous-versions/ms811896(v=msdn.10)?redirectedfrom=MSDN#ucmgch09_topic3)
My thoughts...
I think that *nix part is solved, just extcap side library is missing.
We must focus on Windows part.
My goal is to prepare library calls (at least for C) which will hide
details for developer and there will be just callback and/or global flag
that extcap should finish its work. Extcap author can use it if graceful
shutdown is required.
1) Looks limiting to me, because my understanding is that it requires
that extcap must create hidden window to be able to receive WM_xxx signals.
I'm afraid it can be limiting/additional complexity for extcaps. I can't
evaluate whether it has any other consequences for extcap code.
2) It works, but it requires change how command line is parsed, because
name of named pipe must be passed to extcap. !5489 implements it as new
pipe even there are control pipes which are already processed by API.
Patch can be modified in that area.
Library for C is proposed and it automates cli parsing.
3) It makes sense to me even I didn't tried it yet. My understanding of
documentation is that 3) is more preferred in Win32 world.
I see important that name of event must be agreed between wireshark and
extcap. E.g. if generic "Wireshark_shutdown" is used, it shutdowns every
extcap including ones called from different wireshark application. I
think it should not work this way.
Name of Event can be new parameter for extcap, but it requires cmd line
change.
We can try to derive name of Event from filename/pipe to which extcap
writes output. It is different value for every wireshark/extcap
combination. It do not require any changes on command line.
I found no other dependency for use of Events. It looks promising to me.
Pros of 1) and 3) is that Wireshark do not have to care whether extcap
supports it. If it does, it will process signal or event. If it doesn't,
Wireshark can send them and nothing bad happens to wireshark nor extcap.
On the other hand 2) depends on support on extcap side, but proposed
library solves it. In other words, if extcap do not expose support for
it, wireshark do not call it and no graceful shutdown is issued.
What do you think about that options?
Best regards,
Jirka Novak
___________________________________________________________________________
Sent via: Wireshark-dev mailing list <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
