Wireshark-dev: Re: [Wireshark-dev] Cannot get external capture (extcap) interface to work with
From: hdv <[email protected]>
Date: Wed, 9 Jan 2019 21:42:20 +0100
On 4-1-2019 00:10, Dario Lombardo wrote:


On Thu, Jan 3, 2019 at 5:36 PM hdv <[email protected]> wrote:

I really would expect that the stderr channel could be used to report errors in some way. Tested it, does not display anything until you stop the capture. It would be better to display it immediately. You should assume when anybody uses a plugin we can report errors to the user in a sensible matter. The end user should not need to enable debugging or build the code to get errors. I my example I want to report an error to the user when the plugin cannot make a connection to the external device for example.

...<deleted>...
 

So what is the status of the current extcap plugins, are they still all functional? I can imagine they are harder to test because some are proprietary/need special hardware.

They're expected to be. If they are not, feel free to open bugs on bugzilla. Extcaps in the source tree except ciscodump don't require special hardware at all.

An example of something that is not working as it should be (as far as what I would expect) is the initial error handling, it looks plain broken.

For example take the "ssh remote capture plugin" where you can easily reproduce what I mean: Start it and just fill in an IP number of something that does not exist.

My expectancy is that I will get an error after, say 30 seconds or so that the tool cannot connect.

Instead Wireshark shows in the left lower corner: <live capture in progress>   and on the right: "No packets" forever................

In the process manager you see 3 processes: Wireshark/Dumpcap/sshdump.exe after some time sshdump vanishes from the process list (time out).

But nothing  happens. Only when you explicitly stop the capture (Stop red square) it shows an error:

"Error by extcap pipe: **(sshdump.exe:25304): WARNING **: Error creating connection.

I would expect wireshark to stop immediately when the pipe is broken. By the way this behavious is on WINDOWS, maybe the *nix port is functioning as expected?

Can somebody confirm this?

I assume this is an error to report in bugzilla.

Regards,

Henri