Re: [Wireshark-dev] [Wireshark-commits] rev 52578: /trunk/epan/ /trunk/epan/: proto.c tvbuff.c tvbuff.h

[Jakub Zawadzki]

> On Sun, Oct 13, 2013 at 12:54 AM,   wrote:
> > http://anonsvn.wireshark.org/viewvc/viewvc.cgi?view=rev&revision=52578
> >
> > User: eapache
> > Date: 2013/10/13 04:54 AM
> >
> > Log:
[...]
> >  All of this is (theoretically) unnecessary - simply checking the offset 
> > without
> >  worrying about the length will still catch the very-long-loops, since it 
> > is the
> >  offset that increases in each iteration, not the length.
> >
> >  All that to justify:
> >  - implement tvb_ensure_offset_exists which throws an exception if the 
> > offset is
> >not within the tvb
> >  - use it instead of all the complicated other logic in the 
> > pre-short-circuit
> >step of proto_tree_add_item and friends
> >
> >  This gives us back about 3/4 of the performance we lost in the original 
> > patch.
> >  We're still ~2% slower than without any check, but this is the best I can 
> > think
> >  of right now.
> >

On Sun, Oct 13, 2013 at 12:58:12AM -0400, Evan Huus wrote:
> Jeff (and/or anyone else who cares) I'd appreciate a verification that
> my logic here is correct, and that I've not accidentally undone your
> good work.

I think it's fine, unless in loops there're some weird offset integer overflows 
(which returns back to offset + 0), like easy case:

proto_tree_add_item(..., offset, 0xfffe /* -2 */, ...); offset += 
(-2);
proto_tree_add_item(..., offset, +2, ...); offset += (+2);

About tvb_offset_exists() comment, compute_offset() is not returning
exception when offset == tvb->length.

Kuba.
___
Sent via:Wireshark-dev mailing list 
Archives:http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] Help needed building portaudio for windows

[Graham Bloice]

On 12 October 2013 23:10, Joerg Mayer  wrote:

> On Sat, Oct 12, 2013 at 07:45:10PM +0100, Graham Bloice wrote:
> > On 12 October 2013 18:20, Joerg Mayer  wrote:
> >
> > > I still haven't found out how to build portaudio in the
> > > Wireshark-win32-libs
> > > directory. Can someone please provide information where this is
> documented
> > > or how to do it if no such documentation exists?
> > >
> >
> > The portaudio object files are built in ui\gtk\Makefile.nmake from the
> > sources in the portaudio lib directory.  The objects are then directly
> > linked into libgtkui.
>
> I just looked at it and while it would be easy to copy that solution
> I don't like it.
> Is there any reason why zlib and portaudio aren't built by the setup
> target/script instead of the build process?
>

Setup doesn't really know what toolchain you'll be building with.

The reason for compiling zlib is because of crt mismatch so that definitely
needs to be built with the correct toolchain.

Portaudio doesn't distribute binary packages so must be built from source
but it does have CMake support already.
___
Sent via:Wireshark-dev mailing list 
Archives:http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

[Wireshark-dev] Idea for process image dissection

[Roland Knall]

Hello

I just wanted to bring something by you guys, if it would be worth implementing.

I work on the openSAFETY and EPL dissectors. Both are fieldbus
specific implementations. As such the communicate process images as
payloads. This is the same with nearly all other fieldbus
implementations i know (CanOpen, Profinet, SercosIII, ...).

As such, to a unknown user this displays simply as a byte payload. Now
it may be useful, to dissect the payload in some cases, as such we may
be able to search for specific fields triggering in the payload.

For such a dissection, we need to tell a dissector, how to dissect a
specific payload.

I would like to implement a new field type (FT_PIMAGE) and allow the
user using a dialog, to specify a filter and a mapping to dissect the
field.

For instance one definition might be:

(opensafety.msg.node = 0x04)
bit 0 .. SafeDigitalInput01
bit 1 .. SafeDigitalInput02
byte 2-3 .. SafeAnalogInput01

bits/bytes mapping is something that should be defined more clearly.
But basically this would cover the basic types.

The whole implementation should be very generic as such, that if a
dissector only registers the field, but not defines a mapping,
basically it just displays as the FT_BYTES field will.

The definition for each field mapping must be also session specific,
as it will definitely change between dissections. The main usage would
be to track down specific problem, where I want to monitor the
reaction of the fieldbus after a certain condition has occurred. Right
now using simply bytes[] is painstakingly useless.

kind regards,
Roland
___
Sent via:Wireshark-dev mailing list 
Archives:http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] Status Cmake Win32 support

[Graham Bloice]

On 12 October 2013 23:22, Joerg Mayer  wrote:

> On Sat, Oct 12, 2013 at 07:58:45PM +0100, Graham Bloice wrote:
> > >
> > > - Are there other platforms that would benefit from something similar
> to
> > >   what I did with the setenv.bat script?
> >
> >
> > The setenv.bat (I hope that is the file you're referring to) doesn't work
> > with a MSVC2010 solution, as the paths to the libraries directory is
> wrong,
> > it has ...\builddir\lib, it should be ...\builddir\Debug\lib, and the bin
> > directory is wrong, it has \msvc2010\bin, it should be
> > ...\builddir\Debug\bin.  note that the Debug portion of these paths will
> > vary depending on the type of build done, Debug is the default, there are
> > also; MinSizeRel, Release and RelWithDebInfo.  I think there will be a
> > CMake variable for that somewhere.
>
> My whole setup has only been tested with '-G "NMake Makefiles"' in that
> environment it's using \lib and \bin directly. I'd be interested to know
> where that \Debug in the path comes from. cmake has something that I have
> not used so far, which is called CONFIGURATIONS. But unless configurations
> are used I don't know where that Debug is supposed to come from. Do you
> experience this only with the VS generator or with the nmake generator as
> well?
> Once I know where this comes from I have no problem of adding \${whatever}
> to the paths.
> Which reminds me: Configurations are something we should also add to the
> build at some time ;)
>
>
It is definitely a configuration option.  I think CMake builds a single
configuration when building for Makefiles and multi-configuration when
building for Visual Studio.  CMAKE_BUILD_TYPE defines the configuration to
be built when configuring a single configuration project and
CMAKE_CFG_INTDIR specifies the actual configuration in use when building
the project.  In msbuild this is set via a `/p:Configuration=` switch,
in the VS IDE it's a drop down.


> > I've also noted that sometimes the linker has a malformed option on it:
> > '/LARGEADDRESSAWARE;setargv.obj'.
>
> Fixed in revision 52574 by removing both options. None seems to make a
> difference on my system.


LARGEADDRESSAWARE allows a 32 bit process to use 3GB of RAM on a 64 bit OS
that has sufficient RAM instead of the normal 2GB.  Very useful flag to set.
___
Sent via:Wireshark-dev mailing list 
Archives:http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] Status Cmake Win32 support

[Graham Bloice]

On 12 October 2013 23:38, Joerg Mayer  wrote:

> On Sat, Oct 12, 2013 at 07:31:27PM +0100, Graham Bloice wrote:
> > On 11 October 2013 16:09, Joerg Mayer  wrote:
> >
> >
> > > Another milestone hit:
> > >
> > > - Win 32bit: The following executables build and run from the build
> > > directory
> > >   (as well as capture if they should be able to). *: Acutally tested
> > >   $ ls *exe
> > >   capinfos.exe* dumpcap.exe  mergecap.exe  randpkt.exe   reordercap.exe
> > >  tshark.exe*
> > >   dftest.exeeditcap.exe  qtshark.exe*  rawshark.exe  text2pcap.exe
> > > wireshark.exe*
> > >
> > >
> >
> > Using CMake to generate a MSVC2010 solution, I can't get near that number
> > of successful executables.  I have used the CMake generated solution with
> > command line build (msbuild Wireshark.sln) and from within VS.
>
> I can look into this but probably not within the next two weeks as I'm
> currently
> trying to get this to "featurecompleteness" first and because I don't know
> that
> process (msbuild) at all. OK, I don't expect to reach that within two
> weeks, but
> I hope to have the most important items covered by then.
>

>From a Visual Studio command prompt (probably the same one you use for
nmake)  cause CMake to generate the appropriate output (not passing -G does
that for me) then type `msbuild Wireshark.sln`.

It's make on steroids, but also works with Visual Studio solutions.  A
Visual Studio solution (for 2010 onwards) is a set of xml files.  The .sln
file lists all the projects aka targets, and each project file has all the
instructions to build that project.


>
> >  I do have
> > modified CMake files in an attempt to group the "projects" in Visual
> Studio
> > into some sort of logical tree rather than the large flat list.  I don't
> > believe these changes affect the CMake output to actually build things.
> > I've also enabled the use of make-tap-reg.py for creating the tap
> register
> > functions which seems to work.
>
> Sounds good to me. UseMakeDissectorReg.cmake only implements the python
> version,
> no idea why I implemented the shell version in UseMakeTapReg.cmake.
>

I'll try these changes out on a Linux CMake build to make sure they don't
break anything and then commit them.  Should I set UseMakeTapReg to use
Python in all platforms or just Windows?


>
> > Problems I have seen \ am stuck with:
>
> Again vs specific or with nmake as well?
>

All VS2010 solution.

>
> >- epan generated files always get rebuilt, e.g. diam_dict.c and the
> like
> >- epan won't create register.c, make-dissector-reg.py complains about
> a
> >missing file, from the output the filename looks odd, I suspect I'm
> hitting
> >some command line limit:
> >
> > 1>  Generating register.c
> > 1>  Registering 1151 files, 0 cached
> > 1>  Traceback (most recent call last):
> > 1>File "E:/Wireshark/trunk/tools/make-dissector-reg.py", line 126, in
> > 
> > 1>  file = open(filename)
> > 1>  IOError: [Errno 2] No such file or directory:
> > 'E:/Wireshark/trunk/epan\\dissectos/packet-dua.c'
> > 1>C:\Program Files
> > (x86)\MSBuild\Microsoft.Cpp\v4.0\Microsoft.CppCommon.targets(151,5):
> error
> > MSB6006: "cmd.exe" exited with code 1.
>
> That's again interesting. It works for me using cmd (on Win7). I'm not so
> sure
> about the source of the problem. What do you get when you
> dir E:/Wireshark/trunk/epan\\dissectos/packet-dua.c
> Ah, forget it: Where does the spelling dissectos come from?
>

I know, it's really odd.  The command in the solution is built correctly.
___
Sent via:Wireshark-dev mailing list 
Archives:http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] Help needed building portaudio for windows

[Joerg Mayer]

On Sun, Oct 13, 2013 at 09:18:20AM +0100, Graham Bloice wrote:
> > Is there any reason why zlib and portaudio aren't built by the setup
> > target/script instead of the build process?
> >
> 
> Setup doesn't really know what toolchain you'll be building with.
> 
> The reason for compiling zlib is because of crt mismatch so that definitely
> needs to be built with the correct toolchain.
> 
> Portaudio doesn't distribute binary packages so must be built from source
> but it does have CMake support already.

OK, but when we run setup we normally know which toolchain will be used,
so the libs could be built with that toolchain.

Ciao
Jörg

-- 
Joerg Mayer   
We are stuck with technology when what we really want is just stuff that
works. Some say that should read Microsoft instead of technology.
___
Sent via:Wireshark-dev mailing list 
Archives:http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] Status Cmake Win32 support

[Joerg Mayer]

On Sun, Oct 13, 2013 at 09:46:52AM +0100, Graham Bloice wrote:
> > Sounds good to me. UseMakeDissectorReg.cmake only implements the python
> > version,
> > no idea why I implemented the shell version in UseMakeTapReg.cmake.
> >
> 
> I'll try these changes out on a Linux CMake build to make sure they don't
> break anything and then commit them.  Should I set UseMakeTapReg to use
> Python in all platforms or just Windows?

I think requiring python for the build process is OK (I've implemented the
cmake builds that way), IMO we should get rid of the shell based generators
whenever we have perl or python based alternatives. So do it for all
platforms please.

Ciao
   Jörg
-- 
Joerg Mayer   
We are stuck with technology when what we really want is just stuff that
works. Some say that should read Microsoft instead of technology.
___
Sent via:Wireshark-dev mailing list 
Archives:http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] Status Cmake Win32 support

[Graham Bloice]

On 13 October 2013 09:45, Graham Bloice  wrote:

> On 12 October 2013 23:22, Joerg Mayer  wrote:
>
>> On Sat, Oct 12, 2013 at 07:58:45PM +0100, Graham Bloice wrote:
>> > >
>> > > - Are there other platforms that would benefit from something similar
>> to
>> > >   what I did with the setenv.bat script?
>> >
>> >
>> > The setenv.bat (I hope that is the file you're referring to) doesn't
>> work
>> > with a MSVC2010 solution, as the paths to the libraries directory is
>> wrong,
>> > it has ...\builddir\lib, it should be ...\builddir\Debug\lib, and the
>> bin
>> > directory is wrong, it has \msvc2010\bin, it should be
>> > ...\builddir\Debug\bin.  note that the Debug portion of these paths will
>> > vary depending on the type of build done, Debug is the default, there
>> are
>> > also; MinSizeRel, Release and RelWithDebInfo.  I think there will be a
>> > CMake variable for that somewhere.
>>
>> My whole setup has only been tested with '-G "NMake Makefiles"' in that
>> environment it's using \lib and \bin directly. I'd be interested to know
>> where that \Debug in the path comes from. cmake has something that I have
>> not used so far, which is called CONFIGURATIONS. But unless configurations
>> are used I don't know where that Debug is supposed to come from. Do you
>> experience this only with the VS generator or with the nmake generator as
>> well?
>> Once I know where this comes from I have no problem of adding \${whatever}
>> to the paths.
>> Which reminds me: Configurations are something we should also add to the
>> build at some time ;)
>>
>>
> It is definitely a configuration option.  I think CMake builds a single
> configuration when building for Makefiles and multi-configuration when
> building for Visual Studio.  CMAKE_BUILD_TYPE defines the configuration to
> be built when configuring a single configuration project and
> CMAKE_CFG_INTDIR specifies the actual configuration in use when building
> the project.  In msbuild this is set via a `/p:Configuration=` switch,
> in the VS IDE it's a drop down.
>
>
Slight typo the name of the file is actually setpath.bat

Have you looked into using  configure_file() to create the file from a
template?
___
Sent via:Wireshark-dev mailing list 
Archives:http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] Status Cmake Win32 support

[Graham Bloice]

wsutil has stopped linking for me.  It's looking for gmodule-2.0.lib.
Looking at the linker input the library is specified but without the full
path to ...\wireshark-win-32-libs\gtk2\lib.

In fact the linker input for this target isn't very good at all, it has
gmodule-2.0.lib, glib-2.0.lib and intl.lib all listed without paths and
glib-2.0.lib listed with the path to the lib in ...\gtk3\lib!

Another question that might be more difficult to answer, why does CMake
generate a linker command that has absolute paths to the libs and doesn't
specify additional library directories:

/OUT:"E:\Wireshark\build\lib\Debug\wsutil.dll" /INCREMENTAL /NOLOGO /DLL
"kernel32.lib" "user32.lib" "gdi32.lib" "winspool.lib" "shell32.lib"
"ole32.lib" "oleaut32.lib" "uuid.lib" "comdlg32.lib" "advapi32.lib"
"gmodule-2.0.lib" "glib-2.0.lib" "intl.lib"
"e:\Wireshark\wireshark-win32-libs\gtk3\lib\glib-2.0.lib"
"e:\Wireshark\wireshark-win32-libs\gnutls-2.12.18-1.2-win32ws\bin\libgcrypt-11.lib"
"e:\Wireshark\wireshark-win32-libs\gnutls-2.12.18-1.2-win32ws\bin\libgpg-error-0.lib"
"wsock32.lib" "ws2_32.lib" /MANIFEST
/ManifestFile:"wsutil.dir\Debug\wsutil.dll.intermediate.manifest"
/ALLOWISOLATION /MANIFESTUAC:"level='asInvoker' uiAccess='false'" /DEBUG
/PDB:"E:/Wireshark/build/lib/Debug/wsutil.pdb" /SUBSYSTEM:CONSOLE
/PGD:"E:\Wireshark\build\lib\Debug\wsutil.pgd" /TLBID:1 /DYNAMICBASE
/NXCOMPAT /IMPLIB:"E:/Wireshark/build/lib/Debug/wsutil.lib" /MACHINE:X86
/ERRORREPORT:QUEUE
___
Sent via:Wireshark-dev mailing list 
Archives:http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] Idea for faster dissection on second pas

[Turney, Cal]

On Fri, Oct 11, 2013 at 12:37 PM, Evan Huus  wrote:

On Sat, Oct 12, 2013 at 11:46 AM, Anders Broman  wrote:
>> Just looking at performance in general as I got reports that top of trunk
>> was slower than 1.8.
>> Thinking about it fast filtering is more attractive as long as loading isn't
>> to slow I suppose.
>> It's quite annoying to wait 2 minutes for a file to load and >=2 minutes on
>> every filter operation.

> Ya. It was quite surprising to me to find out how much data we're
> generating and throwing away on each dissection pass. Now I'm
> wondering how much of this could be alleviated somehow by a more
> efficient tree representation...

> I think we need to balance memory usage and speed to be able to handle large
> files, up to 500M/1G files as a rule of thumb ?

> It's always a tradeoff. Ideally we would be fast and low-memory, but
> there's only so much we can do given how much data a large capture
file contains.

I think this is an excellent idea provided it is optional because if the 
capture is very large and/or the user's uncommitted memory is very low, it 
could actually reduce performance or even crash the system.  Ideally, the 
amount of extra memory required to cache the tree should be estimated and 
compared to the amount of available uncommitted memory.  If the required amount 
exceeds or falls within some percentage of the available memory, you could 
automatically revert to not caching the tree and display a pop-up or console 
message to that effect.  If I received such a message, I would be highly 
motivated to purchase more physical memory because the savings in time would 
far outweigh the cost (especially considering how cheap memory has become).

A big +1 from me.

Cal 
___
Sent via:Wireshark-dev mailing list 
Archives:http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] Help needed building portaudio for windows

[Gerald Combs]

On 10/13/13 1:18 AM, Graham Bloice wrote:
> On 12 October 2013 23:10, Joerg Mayer  > wrote:
> 
> On Sat, Oct 12, 2013 at 07:45:10PM +0100, Graham Bloice wrote:
> > On 12 October 2013 18:20, Joerg Mayer  > wrote:
> >
> > > I still haven't found out how to build portaudio in the
> > > Wireshark-win32-libs
> > > directory. Can someone please provide information where this is
> documented
> > > or how to do it if no such documentation exists?
> > >
> >
> > The portaudio object files are built in ui\gtk\Makefile.nmake from the
> > sources in the portaudio lib directory.  The objects are then directly
> > linked into libgtkui.
> 
> I just looked at it and while it would be easy to copy that solution
> I don't like it.
> Is there any reason why zlib and portaudio aren't built by the setup
> target/script instead of the build process?
> 
>  
> Setup doesn't really know what toolchain you'll be building with.
>  
> The reason for compiling zlib is because of crt mismatch so that
> definitely needs to be built with the correct toolchain.

The Nuget zlib package has pre-built binaries for the 2010 and 2012
runtimes. If we're looking for an excuse to start using Nuget and/or
Chocolatey this might be a good one.

http://www.nuget.org/packages/zlib/

___
Sent via:Wireshark-dev mailing list 
Archives:http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] [Wireshark-commits] rev 52578: /trunk/epan/ /trunk/epan/: proto.c tvbuff.c tvbuff.h

[Evan Huus]

On Sun, Oct 13, 2013 at 3:54 AM, Jakub Zawadzki
 wrote:
> About tvb_offset_exists() comment, compute_offset() is not returning
> exception when offset == tvb->length.

Ah, OK. Should it? When offset == tvb->length I would think that
should be an exception, since no bytes exist at that location. There
are other places that call compute_offset and don't check the == case
that maybe should...

Evan
___
Sent via:Wireshark-dev mailing list 
Archives:http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] [Wireshark-commits] rev 52578: /trunk/epan/ /trunk/epan/: proto.c tvbuff.c tvbuff.h

[didier]

Hi,
Le dimanche 13 octobre 2013 à 16:43 -0400, Evan Huus a écrit :
> On Sun, Oct 13, 2013 at 3:54 AM, Jakub Zawadzki
>  wrote:
> > About tvb_offset_exists() comment, compute_offset() is not returning
> > exception when offset == tvb->length.
> 
> Ah, OK. Should it? When offset == tvb->length I would think that
> should be an exception, since no bytes exist at that location. There
> are other places that call compute_offset and don't check the == case
> that maybe should...
On the other hand is doing parsing with tree NULL and flags.visited
false or colinfo not null worth it? There's so many bugs, Personally I
gave up on it.

One example with tshark, without a tree tcp flags aren't set anymore in
colinfo (cf packet-tcp.c around line 4228, since
dfa2156e301539929a12dda54752c778c3ee7a39 remove 'check_colinfo')
and so on...

Didier


___
Sent via:Wireshark-dev mailing list 
Archives:http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] [Wireshark-commits] rev 52578: /trunk/epan/ /trunk/epan/: proto.c tvbuff.c tvbuff.h

[Jakub Zawadzki]

On Sun, Oct 13, 2013 at 04:43:28PM -0400, Evan Huus wrote:
> On Sun, Oct 13, 2013 at 3:54 AM, Jakub Zawadzki
>  wrote:
> > About tvb_offset_exists() comment, compute_offset() is not returning
> > exception when offset == tvb->length.
> 
> Ah, OK. Should it? When offset == tvb->length I would think that
> should be an exception, since no bytes exist at that location.

Don't know, right now it works :}

There is some lengthy comment about it before 
check_offset_length_no_exception().

I know about some dissectors which calls tvb_find_guint8() with offset == 
tvb->offset [bug #9034#c5].
___
Sent via:Wireshark-dev mailing list 
Archives:http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe