One of the benefits of the extcap-cli is, that we can and currently do, send an API version to the extcap utility which would allow breaking changes while still enabling a compatibility mode for older versions. Because of that, I think 2 would be an ideal scenario, just define the response to the API call.
1) is not an option. We have extcaps implemented in C, Python, Powershell, Delphi, Go, I even know of one implemented as windows batch script. Only a limited version of them would be able to implement the window reliably. Also, the general idea for extcap utilities is, that they are universally usable across platforms, this dependency is a bit too much. So it is either between 2) or 3) and from my POV we should choose the option the promises to be more reliable, no matter about changing the extcap side of things. One thing though. Whatever the solution, we should try to provide a „don’t care“ mode. Otherwise most developers will have to die be into cross-Plattform development stuff, and as most external extcaps I know about are written by sysadmins or internal devs for very specific usecases, I fear that might turn people off from using the api in the first place. Cheers Roland > Am 21.08.2022 um 15:53 schrieb Jirka Novak <j.no...@netsystem.cz>: > > 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 ___________________________________________________________________________ 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
