Re: [Wireshark-dev] Future of extcap "API"
Hi, On Tue, Aug 23, 2022 at 6:24 PM Jirka Novak wrote: The problem with GenerateConsoleCtrlEvent() is that the caller has to be attached to the target process console. While we could technically do so, it requires freeing any already open console because process can be attached to at most one console. The pretty much only sane solution to the problem is to have a helper program between Wireshark and extcap. The helper would simply spawn extcap with provided parameters and accept commands from Wireshark e.g. on pipe. The commands would be to gracefully terminate (CTRL_C_EVENT or CTRL_BREAK_EVENT) and forcefully terminate (TerminateProcess()). Note that the helper must not be forcefully terminated as it would leave the extcap running. While far from ideal, I think the helper is the only sensible approach. Note that GLib gspawn-win32-helper does something different, so going back to the GLib helper is not what this is all about. Even I understand reasons, it looks to me very complex. I'm sorry, but my Win32 skills are too low to make it. Nobody says that you have to write it yourself. I understand your desire to have things available quickly, but I believe this should be part of the gradual extcap refinement that is ongoing (and led to seemingly unrelated changes like the leaking handles fixes, GLib event loop integration and significant mmdbresolve speedup) and not just slapped together. Yes, I was looking to "quick" solution as I updated extcap to require graceful shutdown and it is crossplatform. *nix world is solved and I'm working mainly on it, so I can wait with Windows side. I want to help, if I'm capable of it. I agree with you, that it makes sense to invest effort to better and scalable solution. Lets focus on it. There is my view of discussed proposal: wireshark(1) - something(2) - helper(3) - signals(4) - extcap(5) (1) Wireshark should be able to start extcap. Wireshark must be able to query for parameters of a extcap and should support control pipes (UI stuff, works nowadays). (2) We are looking for any solution there. It can be pipe as for dumpcap nowadays, but other options are welcomed. (3) helper is responsible for extcap control. On Win32 it should handle console stuff and allows us to use signals between helper and extcap on Win32. (4) *nix or Win32 console signals are used there (5) Extcap should be simple and we prefer to use OS specific features - signals for graceful shutdown. Extcap can be written in any language, can be single or multiplatform. Extcap should be modified if and only if it requires graceful shutdown. Points to discuss: It the diagram complete? I'm not sure about dumpcap. There is dumpcap started for every extcap, which reads data from extcap and pass it to wireshark. Does helper staff involve it? Helper will help us with solving Win32 stuff. Do we need it just on Windows or on every platform? For *nix it is useless I think, but using same approach on every platform can be useful. There is negotiation between wireshark and extcap before extcap is started - it provides wireshark with name of extcap, supported interface, required parameters... I think it would stay as it is. So helper will not be used there. When extcap prints anything to STDOUT or STDERR, it is passed to Wireshark (there are extcap console works running). STDERR is shown as error/information to a user when extcap is finished. We must pass this thru helper. How helper's STDOUT/STDERR will be handled? Extcap can support control pipes. They are passed to extcap as parameters. I think that control pipes will bypass helper. I mean parameters/names of pipes will be passed thru helper, but helper will not open/close/touch control pipes. Wireshark is the one who creates command line for extcap - name of binary and its parameters. This information should be passed to helper and it will run command line. How to pass this information to helper? I'm afraid that pass it as command line parameters can create issues - e.g. same parameter name for helper (it needs some) and for extcap, special character escaping, ... So I propose some other way, but I have no proposal. How Wireshark will control helper? We can't use signals on Win32. So pipe or windows events? What about writing notes/discussed points to a document/wiki? Best regards, Jirka ___ 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] Wiki editor permission request
Hi, I would like permission to edit the Wireshark wiki. My GitLab username is glzbcrt. -- -George ___ 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] Future of extcap "API"
On Wed, Aug 24, 2022 at 12:15 PM Jirka Novak wrote: > There is my view of discussed proposal: > > wireshark(1) - something(2) - helper(3) - signals(4) - extcap(5) > > (1) Wireshark should be able to start extcap. Wireshark must be able to > query for parameters of a extcap and should support control pipes (UI > stuff, works nowadays). > (2) We are looking for any solution there. It can be pipe as for dumpcap > nowadays, but other options are welcomed. Most likely pipe on Windows. Not needed on UNIX systems. > (3) helper is responsible for extcap control. On Win32 it should handle > console stuff and allows us to use signals between helper and extcap on > Win32. Not needed on UNIX systems. > (4) *nix or Win32 console signals are used there > (5) Extcap should be simple and we prefer to use OS specific features - > signals for graceful shutdown. Extcap can be written in any language, > can be single or multiplatform. Extcap should be modified if and only if > it requires graceful shutdown. > > Points to discuss: > It the diagram complete? No, and it can be misleading as it mixes multiple concepts. The diagram is incomplete as it misses dumpcap. Extcap writes pcap data to pipe that Wireshark created but it is really dumpcap who reads the data from that pipe. > I'm not sure about dumpcap. There is dumpcap started for every extcap, > which reads data from extcap and pass it to wireshark. There is one dumpcap started for all extcaps. When you start capture on multiple extcaps, Wireshark will read single pcapng file that contains the data dumpcap read from the extcap pipes. > Does helper staff involve it? No. > Helper will help us with solving Win32 stuff. Do we need it just on > Windows or on every platform? Just on Windows to overcome the console limitations. > For *nix it is useless I think, but using same approach on every > platform can be useful. The code can be cleanly isolated. There's no point in using same approach on every platform. > There is negotiation between wireshark and extcap before extcap is > started - it provides wireshark with name of extcap, supported > interface, required parameters... > I think it would stay as it is. So helper will not be used there. Not needed. Although Roland mentioned that maybe it could be used to overcome the .bat wrapper in the future. However that would be something unrelated to the graceful shutdown and only makes sense to pursue further once the helper is already there. > When extcap prints anything to STDOUT or STDERR, it is passed to > Wireshark (there are extcap console works running). STDERR is shown as > error/information to a user when extcap is finished. We must pass this > thru helper. > How helper's STDOUT/STDERR will be handled? In general there's no need for helper to write to STDOUT/STDERR as its sole purpose is overcoming API limitation. If extcap fails to spawn then helper can either write error to its (duplex) pipe or simply to the handle that Wireshark sees as extcap STDERR. > Extcap can support control pipes. They are passed to extcap as parameters. > I think that control pipes will bypass helper. I mean parameters/names > of pipes will be passed thru helper, but helper will not > open/close/touch control pipes. Helper doesn't need to know anything about extcaps. > Wireshark is the one who creates command line for extcap - name of > binary and its parameters. This information should be passed to helper > and it will run command line. How to pass this information to helper? I think just appending extcap binary and commandline after "--" helper commandline argument is all that is needed. > I'm afraid that pass it as command line parameters can create issues - > e.g. same parameter name for helper (it needs some) and for extcap, > special character escaping, ... Windows commandline handling is far from perfect, but I don't see major obstacles here. Helper just have to find where the extcap commandline starts in the commandline string the helper was started with. > How Wireshark will control helper? > We can't use signals on Win32. So pipe or windows events? I think single character (e.g. 'q' for graceful termination, and 't' for termination) write to a pipe is all that is needed. The pipe can be duplex as it will be Windows only. > What about writing notes/discussed points to a document/wiki? I don't think there is a need to because the wireshark-dev archive is publicly available. Once there is actual implementation, then the extcap interface documentation should be updated. Best Regards, Tomasz Moń ___ 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
