Closed JaapKeuter closed 6 years ago
Hey Jaap I think we should mention #51 here so GitHub shows the relation between this pull request and the issue.
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
.
@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:
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?
Let's move this conversation under the open issue https://github.com/desowin/usbpcap/issues/51
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.