Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add handling of --extcap-version command line parameter #53

Merged
merged 1 commit into from
Jul 25, 2018
Merged

Add handling of --extcap-version command line parameter #53

merged 1 commit into from
Jul 25, 2018

Conversation

JaapKeuter
Copy link
Contributor

Since Wireshark 2.9 the extcap call to query its interface is extended
with the extcap-version parameter. The command line option parser is
not expecting this, emitting a message in stderr.
This change adds the extcap-version parameter to the expected set, to
stop the message being emitted on stderr, leaving out any processing
of the parameter value itself, which USBPcapCMD does not need, yet.

Since Wireshark 2.9 the extcap call to query its interface is extended
with the extcap-version parameter. The command line option parser is
not expecting this, emitting a message in stderr.
This change adds the extcap-version parameter to the expected set, to
stop the message being emitted on stderr, leaving out any processing
of the parameter value itself, which USBPcapCMD does not need, yet.
@theXappy
Copy link

Hey Jaap
I think we should mention #51 here so GitHub shows the relation between this pull request and the issue.

Copy link
Owner

@desowin desowin left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Works fine on my Windows 10 laptop with Wireshark 2.9.0rc0-1285

@desowin desowin self-assigned this Jul 25, 2018
@desowin desowin merged commit 8e55391 into desowin:master Jul 25, 2018
@JaapKeuter JaapKeuter deleted the extcap-version2 branch July 26, 2018 05:35
@guyharris
Copy link

Note that 1) the version argument to --extcap-version is optional, so if there's an argument to the --extcap-version option, it shouldn't print the extcap version (it should presumably check whether it supports that version and fail if it doesn't), and if there isn't an argument to that option, it should continue to report the version.

Note also that the only way to pass an optional argument to an option that is supported by all versions of getopt_long() is --extcap-version=X.Y, not --extcap-version X.Y, so Wireshark will pass it as --extcap-version=X.Y; if you're not using getopt_long() or something compatible with it as an option parser, you must also support --extcap-version=X.Y.

@desowin
Copy link
Owner

desowin commented Jul 27, 2018

@guyharris I will change the argument parser to support the optional argument.

However, I am somehow lost in understanding --extcap-version. Could you please answer following questions to clarify:

  1. When Wireshark calls --extcap-version=X.Y then the X.Y is the Wireshark version, eg. 2.9, right? Is this "should presumably check whether it supports that version and fail if it doesn't" supposed to check if the wireshark version is too old? For example, assume that some extcap makes it mandatory to use some extcap feature that is supported in Wireshark since some version A.B. Then the extcap will check the passed X.Y against the A.B and if it is lower, it'll fail. Is this the intention?
  2. If wireshark calls --extcap-version without any argument, the extcap should print its version (eg. 1.2.0.4 for the upcoming USBPcap), right?

Regardless if --extcap-version is called with or without parameter, if extcap does not fail, it should print the tool version (the 1.2.0.4 for upcoming USBPcap)?

And if extcap is called without --extcap-version at all, but with the --extcap-interfaces (old version of Wireshark), is it safe to print the "extcap {version=a.b.c.d}{help=someurl}" alongside the interfaces?

@desowin
Copy link
Owner

desowin commented Jul 27, 2018

Let's move this conversation under the open issue #51

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants