[Wireshark-dev] Wireshark is now twenty
Today is the 20th anniversary of the announcement Ethereal 0.2.0, the first public release of what is now Wireshark. My goals at the time were pretty modest. I wanted to be able to do my job better, which included learning more about networking, and to contribute back to open source. After that first release the generosity from the community was immediate and overwhelming. It can be measured not only in lines of code, but in knowledge shared, assistance provided, and friendships forged. Supporting Wireshark's ecosystem turned into a career and adventure, and for that I am both humbled and grateful. I'm immensely proud of what we've accomplished so far and look forward to working with all of you in the years to come. Thank you all! Cheers! ___ 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] usbpcap no longer recognized in 2.9
Hey all I noticed today I couldn't get Wireshark to show the usbpcap interface in the latest master build. I'm quite positive this is because of the new addition to the way extcaps are interacted with, specificly (from README.extcap): " Since Wireshark 2.9 this call is extended with --extcap-version x.x, which will allways represent the calling wireshark's version information. This can be used to change behavior depending on the wireshark version in question " I tried calling usbpcap's executable (USBPcapCMD.exe) with the new --extcap-version option and it returns this output: " USBPcapCMD.exe: --extcap-version: unknown option " While this is something that should be solved at usbpcap side, since Wireshark ships with the the latest usbpcap version (which doesn't support this option) in the installer, this might confuse the users. My suggestion is either 1. Allow backward compatibility (calling the all extcaps which do not response 'nicely' to "--extcap-interfaces --extcap-version=2.9" with the old "--extcap-interfaces" args list) 2. Remove the usbpcap from the (NSIS) installer until a version which supports this option exists What do you guys think? Side note 1: I have already opened an issue on usbpcap's GitHub page: https://github.com/desowin/usbpcap/issues/51 Side note 2: There seems to be a misalignment between wireshark and README.extcap. The README says the new options' syntax is "--extcap-version x.x" and even provides an example but in my tests wireshark uses "--extcap-version*=*x.x". I'm assuming one of them is a mistake and should be fixed. Cheers ___ 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] Lua update?
On 12-07-2018 21:04, Peter Wu wrote:
On Thu, Jul 12, 2018 at 07:13:21PM +, Maynard, Chris wrote:
Release notes for 5.3: http://www.lua.org/manual/5.3/readme.html
It’s possible that there are incompatibilities, which would necessitate
modifying Lua scripts , but for me personally, I don’t mind changing my scripts
if I have to. In fact, I *want* to change my scripts in order to make use of
some new features, in particular the bitwise operators[1]. To me, the perfect
time to update would be for the next Wireshark 3.0 release.
Previous discussion starts here:
https://www.wireshark.org/lists/wireshark-dev/201608/msg00082.html.
Maybe João, Pascal, Peter, Hadriel and others would like to weigh in again here?
I was previously concerned with backwards compatibility, but if Lua 5.3
is reallt that attractive, it might be an option to drop support for
older Lua versions (5.1/5.5) and require 5.3 for Wireshark 3.0 (or
whatever new major release). That also makes life easier for Lua
dissector developers who only need to support one version instead of two
(currently 5.1 and 5.2).
When doing so, it is possible that some older dissectors or plugins
cease working. Those depending on the "bitop" module (which exposes
functions such as "bit.lshift(1, 2)") should change their scripts to use
the new syntax in Lua 5.3 ("1 << 2"). Then the "bitop" module would have
to be dropped since it no longer compiles with Lua 5.3:
https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=10881
For some reason, the luabit library is not documented in the Developer's
Guide nor covered by tests. I guess this is a good reason to drop it.
Should the Lua API be extended in the future, it must be covered by
tests such that it clear which public parts are stable.
One potential problem is that even Centos/RHEL 7 still do not ship with
Lua 5.3, they include Lua 5.1 only. EPEL7 has no newer version either.
Debian ships with Lua 5.3 since jessie-backports. Ubuntu ships with it
since 16.04 (and not 14.04).
To make Lua 5.3 available for these Linux distributions, the Lua 5.3
would have to be built as part of the Wireshark build process. I would
prefer not to bundle Lua 5.3 code with Wireshark, but we could provide
instructions on retrieving and building it.
For the Ubuntu PPA, one option is to provide a lua5.3 package.
Note that João has done work before on trying to integrate Lua 5.3, that
could be a good start to continue the process:
https://code.wireshark.org/review/17175
Thanks for the recap. We should also decide what to do with the broken
lrexlib-gregex Lua binding (bug 12997).
___
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
