[Wireshark-dev] Consolidate the Wireshark developer documentation?

2017-04-10 Thread Guy Harris 
Currently, for Wireshark developer documentation, we have:

the Wireshark Developer's Guide at

https://www.wireshark.org/docs/wsdg_html_chunked/index.html

a bunch of README files in the doc directory of the source code at


https://code.wireshark.org/review/gitweb?p=wireshark.git;a=tree;f=doc

the Wireshark Lua API wiki at

https://wiki.wireshark.org/LuaAPI

Should some or all of the rest of the documentation be merged into the 
Developer's Guide?
___
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] Inconsistent availability of proto_tree values during the first of two passes

2017-04-10 Thread Guy Harris 
On Apr 10, 2017, at 3:04 PM, Paul Offord  wrote:

>> If a tree isn't being generated, because it isn't necessary (e.g., if the 
>> code calling the dissectors is only trying to get the column contents) 
>> there's presumably no need for TRANSUM - or any other dissector or 
>> post-dissector - to add anything to the non-existent tree.
> 
> Agreed, except in the case of TRANSUM the user will probably want to add a 
> TRANSUM-computed value as a column.  For example, if you use tshark to just 
> output the Packet List entries (summary lines) it's likely that 
> TRANSUM-computed values would be included in that listing.

That's not a TRANSUM-specific issue.  If the user wants to use *any* custom 
columns, from *any* dissector or post-dissector field, the protocol tree 
currently has to be generated - and, given that custom columns work, we 
*already* arrange to construct the protocol tree whenever we're asking for 
columns and at least one column is a custom column (see various calls to 
have_custom_cols()), so if the code calling the dissectors is only trying to 
get the column contents *but* at least one column is a custom column, the tree 
will be constructed.

___
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] Change in wireshark[master]: Add support for BASE_VALS_NO_UNKNOWN

2017-04-10 Thread Michael Mann 


I was never sold on the BASE_VALS_NO_UNKNOWN name, but I figured it was easy 
enough to search/replace if someone found something better.
I would consider BASE_SPECIAL_VALS an upgrade.
 
 
-Original Message-
From: Guy Harris 
To: Developer support list for Wireshark 
Sent: Mon, Apr 10, 2017 6:19 pm
Subject: Re: [Wireshark-dev] Change in wireshark[master]: Add support for 
BASE_VALS_NO_UNKNOWN

On Apr 10, 2017, at 1:31 PM, Michael Mann (Code Review) 
 wrote:

> Michael Mann has submitted this change and it was merged.
> 
> Change subject: Add support for BASE_VALS_NO_UNKNOWN
> ..
> 
> 
> Add support for BASE_VALS_NO_UNKNOWN
> 
> BASE_VALS_NO_UNKNOWN is a special value_string value for only a single
> (maybe 2) numerical value(s).  If a field has the numerical value
> that doesn't match anything in the value_string, just the number
> is supplied for the field (no "Unknown")
> 
> Dissectors that had this use case have been converted in the patch.

The use case for this appears to be for fields that normally have a numerical 
value, and where particular numerical values have no special significance, but 
where certain numerical values have a special meaning - for example, a field 
that's normally a timeout in milliseconds, but where a value of 0 means "time 
out immediately" and a value of 0x means "never time out".

Would a more descriptive name for it be something such as BASE_SPECIAL_VALS?
___
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


___
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] Change in wireshark[master]: Add support for BASE_VALS_NO_UNKNOWN

2017-04-10 Thread Guy Harris 
On Apr 10, 2017, at 1:31 PM, Michael Mann (Code Review) 
 wrote:

> Michael Mann has submitted this change and it was merged.
> 
> Change subject: Add support for BASE_VALS_NO_UNKNOWN
> ..
> 
> 
> Add support for BASE_VALS_NO_UNKNOWN
> 
> BASE_VALS_NO_UNKNOWN is a special value_string value for only a single
> (maybe 2) numerical value(s).  If a field has the numerical value
> that doesn't match anything in the value_string, just the number
> is supplied for the field (no "Unknown")
> 
> Dissectors that had this use case have been converted in the patch.

The use case for this appears to be for fields that normally have a numerical 
value, and where particular numerical values have no special significance, but 
where certain numerical values have a special meaning - for example, a field 
that's normally a timeout in milliseconds, but where a value of 0 means "time 
out immediately" and a value of 0x means "never time out".

Would a more descriptive name for it be something such as BASE_SPECIAL_VALS?
___
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] Inconsistent availability of proto_tree values during the first of two passes

2017-04-10 Thread Paul Offord 
> Building up state from a chronological scan of the packets is what you have 
> to do in the first pass, with any information you can't recompute from the 
> contents of a single packet saved for use when re-dissecting a packet.

Yes, that's the case for TRANSUM.  TRANSUM analyses the packets that make up 
Request and Response APDU pairs and computes values.  These computed values are 
added to the protocol tree of the first packet of the Request APDU during the 
second and subsequent scan. 

> If a tree isn't being generated, because it isn't necessary (e.g., if the 
> code calling the dissectors is only trying to get the column contents) 
> there's presumably no need for TRANSUM - or any other dissector or 
> post-dissector - to add anything to the non-existent tree.

Agreed, except in the case of TRANSUM the user will probably want to add a 
TRANSUM-computed value as a column.  For example, if you use tshark to just 
output the Packet List entries (summary lines) it's likely that 
TRANSUM-computed values would be included in that listing.

> So this is a case where a "generate the tree on the first pass" indication is 
> what's needed (and that would probably not be needed for post-dissectors that 
> only need *particular* field values if there were a way for a post-dissector 
> to get the values of those fields without generating a protocol tree, but 
> that's the "needs more work" improvement I've mentioned elsewhere).

Agreed.

-Original Message-
From: wireshark-dev-boun...@wireshark.org 
[mailto:wireshark-dev-boun...@wireshark.org] On Behalf Of Guy Harris
Sent: 10 April 2017 18:39
To: Developer support list for Wireshark 
Subject: Re: [Wireshark-dev] Inconsistent availability of proto_tree values 
during the first of two passes

On Apr 10, 2017, at 12:30 AM, Paul Offord  wrote:

>> So would you need the full protocol tree *every* time the packet is 
>> dissected, or just the *first* time (meaning you'd save the results of the 
>> first-pass processing and not require it later)?
> 
> TRANSUM only needs the values in the first pass, but during the second pass 
> it adds a section to the end of the visible tree using proto_tree_add_xx 
> function and I assume that means it needs the full tree at that point.  I 
> imagine other dissectors and post-dissectors would also need the full tree on 
> the second pass.

There's "the first pass", which is guaranteed to occur, and then there's 
"everything else", which is not guaranteed to include a second sequential pass 
through all the packets; if it does, that's an implementation detail.  Building 
up state from a chronological scan of the packets is what you have to do in the 
first pass, with any information you can't recompute from the contents of a 
single packet saved for use when re-dissecting a packet.

If a tree isn't being generated, because it isn't necessary (e.g., if the code 
calling the dissectors is only trying to get the column contents) there's 
presumably no need for TRANSUM - or any other dissector or post-dissector - to 
add anything to the non-existent tree.

So this is a case where a "generate the tree on the first pass" indication is 
what's needed (and that would probably not be needed for post-dissectors that 
only need *particular* field values if there were a way for a post-dissector to 
get the values of those fields without generating a protocol tree, but that's 
the "needs more work" improvement I've mentioned elsewhere).
___
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

__

This message contains confidential information and is intended only for the 
individual named. If you are not the named addressee you should not 
disseminate, distribute or copy this e-mail. Please notify the sender 
immediately by e-mail if you have received this e-mail by mistake and delete 
this e-mail from your system.

Any views or opinions expressed are solely those of the author and do not 
necessarily represent those of Advance Seven Ltd. E-mail transmission cannot be 
guaranteed to be secure or error-free as information could be intercepted, 
corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The 
sender therefore does not accept liability for any errors or omissions in the 
contents of this message, which arise as a result of e-mail transmission.

Advance Seven Ltd. Registered in England & Wales numbered 2373877 at Endeavour 
House, Coopers End Lane, Stansted, Essex CM24 1SJ

__
This email has been scanned by the Symantec Email

Re: [Wireshark-dev] buildbot down?

2017-04-10 Thread Maynard, Chris 
Here's a batch file that *might* also help?  It makes use of both handle.exe 
and taskkill.exe to hopefully achieve what you're looking for?

  :: Forcefully kills the process with the given open file containing the
  :: specified pattern.  For example, running the following will kill the 
first
  :: process found with a file open that contains the string 
"wireshark_pcapng"
  :: anywhere in the name:
  ::
  :: killprocbyfile.bat wireshark_pcapng
  ::

  @ECHO OFF

  IF ["%~1"] == [""] GOTO USAGE

  @ECHO OFF
  FOR /F "TOKENS=1-3 USEBACKQ" %%I IN (`HANDLE.EXE "%1"`) DO (
  IF "%%J" == "pid:" (
  ECHO Killing %%I PID: %%K
  TASKKILL.EXE /F /PID %%K
  GOTO :EOF
  )
  )
  GOTO :EOF

  :USAGE
  ECHO Usage: %~0 ^

- Chris

> -Original Message-
> From: wireshark-dev-boun...@wireshark.org [mailto:wireshark-dev-
> boun...@wireshark.org] On Behalf Of Maynard, Chris
> Sent: Monday, April 10, 2017 2:12 PM
> To: Developer support list for Wireshark 
> Subject: Re: [Wireshark-dev] buildbot down?
>
> Would taskkill.exe help?
>
> For example, "taskkill.exe /im dumpcap.exe" , etc.
>
> I've also used WMIC in the past to save ProcessID's of tasks so you can later 
> kill
> specific instances of a task instead of all of them with the same name.  I'd 
> refer
> you to the dumpcap.bat file posted on https://wiki.wireshark.org/Tools for how
> I did that.
>
> - Chris
> [1]:
> https://www.microsoft.com/resources/documentation/windows/xp/all/proddoc
> s/en-us/taskkill.mspx?mfr=true
>
> - Chris
>
> > -Original Message-
> > From: 
> > wireshark-dev-boun...@wireshark.org
> >  [mailto:wireshark-dev-
> > boun...@wireshark.org] On Behalf Of Gerald 
> > Combs
> > Sent: Monday, April 10, 2017 2:06 PM
> > To: Developer support list for Wireshark 
> > >
> > Subject: Re: [Wireshark-dev] buildbot down?
> >
> > On 4/9/17 1:23 AM, Graham Bloice wrote:
> > >
> > >
> > > On 9 April 2017 at 01:54, Gerald Combs  > > > wrote:
> > >
> > > On 4/8/17 10:47 AM, Peter Wu wrote:
> > > >
> > > > There is another problem though with the Petri-Dish builder, a 
> > > previous
> > > > build on the Petri-Dish Windows x86 builder failed and left a 
> > > process on
> > > > the machine, breaking all following builds. Gerald, can you have a 
> > > look?
> > >
> > > It's back up.
> > >
> > > > Maybe it is an idea to add a pass that kills all
> > > > dumpcap/tshark/wireshark processes before starting the build?
> > (Assuming
> > > > that no other builds happen in parallel).
> > >
> > > Is there a straightforward equivalent to "kill -9 $( lsof -t
> > > /path/to/buildbot )" on Windows?
> > >
> > >
> > > Difficult to identify which process you want to kill with
> > > Stop-Process.  With PS 4.0 and later you can run ((Get-Process
> > > -IncludeUserName).where({$_.username -AND $_.username -notmatch
> > > "^NT"})) to get the processes owned by the user account running the
> > > command, but there's still too many in there that shouldn't be stopped.
> > >
> > > Maybe Get-Process | Where-Object -Property ProcessName -match
> > > ".*(Process1|Process2|Process3).*" | Stop-Process would do if the
> > > number of processes to look for isn't too bad.
> >
> > How difficult would it be to parse the output of the Sysinternals
> > "Handle" utility in PS? That would presumably tell us which process
> > has the build directory locked while limiting the risk of clobbering
> > any other Buildbot instances that happen to be running.
> >
> 
> > ___
> > 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
> CONFIDENTIALITY NOTICE: This message is the property of International Game
> Technology PLC and/or its subsidiaries and may contain proprietary,
> confidential or trade secret information.  This message is intended solely for
> the use of the addressee.  If you are not the intended recipient and have
> received this message in error, please delete this message from your system.
> Any unauthorized reading, distribution, copying, or other use of this message 
> or
> its attachments is strictly prohibited.
>
> 
> ___
> Sent via:Wireshark-dev mailing list 
>

Re: [Wireshark-dev] buildbot down?

2017-04-10 Thread Maynard, Chris 
Would taskkill.exe help?

For example, "taskkill.exe /im dumpcap.exe" , etc.

I've also used WMIC in the past to save ProcessID's of tasks so you can later 
kill specific instances of a task instead of all of them with the same name.  
I'd refer you to the dumpcap.bat file posted on 
https://wiki.wireshark.org/Tools for how I did that.  

- Chris
[1]: 
https://www.microsoft.com/resources/documentation/windows/xp/all/proddocs/en-us/taskkill.mspx?mfr=true

- Chris

> -Original Message-
> From: wireshark-dev-boun...@wireshark.org [mailto:wireshark-dev-
> boun...@wireshark.org] On Behalf Of Gerald Combs
> Sent: Monday, April 10, 2017 2:06 PM
> To: Developer support list for Wireshark 
> Subject: Re: [Wireshark-dev] buildbot down?
> 
> On 4/9/17 1:23 AM, Graham Bloice wrote:
> >
> >
> > On 9 April 2017 at 01:54, Gerald Combs  > > wrote:
> >
> > On 4/8/17 10:47 AM, Peter Wu wrote:
> > >
> > > There is another problem though with the Petri-Dish builder, a 
> > previous
> > > build on the Petri-Dish Windows x86 builder failed and left a process 
> > on
> > > the machine, breaking all following builds. Gerald, can you have a 
> > look?
> >
> > It's back up.
> >
> > > Maybe it is an idea to add a pass that kills all
> > > dumpcap/tshark/wireshark processes before starting the build?
> (Assuming
> > > that no other builds happen in parallel).
> >
> > Is there a straightforward equivalent to "kill -9 $( lsof -t
> > /path/to/buildbot )" on Windows?
> >
> >
> > Difficult to identify which process you want to kill with
> > Stop-Process.  With PS 4.0 and later you can run ((Get-Process
> > -IncludeUserName).where({$_.username -AND $_.username -notmatch
> > "^NT"})) to get the processes owned by the user account running the
> > command, but there's still too many in there that shouldn't be stopped.
> >
> > Maybe Get-Process | Where-Object -Property ProcessName -match
> > ".*(Process1|Process2|Process3).*" | Stop-Process would do if the
> > number of processes to look for isn't too bad.
> 
> How difficult would it be to parse the output of the Sysinternals "Handle" 
> utility
> in PS? That would presumably tell us which process has the build directory
> locked while limiting the risk of clobbering any other Buildbot instances that
> happen to be running.
> 
> ___
> 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
CONFIDENTIALITY NOTICE: This message is the property of International Game 
Technology PLC and/or its subsidiaries and may contain proprietary, 
confidential or trade secret information.  This message is intended solely for 
the use of the addressee.  If you are not the intended recipient and have 
received this message in error, please delete this message from your system. 
Any unauthorized reading, distribution, copying, or other use of this message 
or its attachments is strictly prohibited.

___
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] buildbot down?

2017-04-10 Thread Gerald Combs 
On 4/9/17 1:23 AM, Graham Bloice wrote:
> 
> 
> On 9 April 2017 at 01:54, Gerald Combs  > wrote:
> 
> On 4/8/17 10:47 AM, Peter Wu wrote:
> >
> > There is another problem though with the Petri-Dish builder, a previous
> > build on the Petri-Dish Windows x86 builder failed and left a process on
> > the machine, breaking all following builds. Gerald, can you have a look?
> 
> It's back up.
> 
> > Maybe it is an idea to add a pass that kills all
> > dumpcap/tshark/wireshark processes before starting the build? (Assuming
> > that no other builds happen in parallel).
> 
> Is there a straightforward equivalent to "kill -9 $( lsof -t
> /path/to/buildbot )" on Windows?
> 
> 
> Difficult to identify which process you want to kill with
> Stop-Process.  With PS 4.0 and later you can run ((Get-Process
> -IncludeUserName).where({$_.username -AND $_.username -notmatch "^NT"})) to
> get the processes owned by the user account running the command, but
> there's still too many in there that shouldn't be stopped.
> 
> Maybe Get-Process | Where-Object -Property ProcessName -match
> ".*(Process1|Process2|Process3).*" | Stop-Process would do if the number of
> processes to look for isn't too bad.

How difficult would it be to parse the output of the Sysinternals "Handle" 
utility in PS? That would presumably tell us which process has the build 
directory locked while limiting the risk of clobbering any other Buildbot 
instances that happen to be running.
___
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] Inconsistent availability of proto_tree values during the first of two passes

2017-04-10 Thread Guy Harris 
On Apr 10, 2017, at 12:30 AM, Paul Offord  wrote:

>> So would you need the full protocol tree *every* time the packet is 
>> dissected, or just the *first* time (meaning you'd save the results of the 
>> first-pass processing and not require it later)?
> 
> TRANSUM only needs the values in the first pass, but during the second pass 
> it adds a section to the end of the visible tree using proto_tree_add_xx 
> function and I assume that means it needs the full tree at that point.  I 
> imagine other dissectors and post-dissectors would also need the full tree on 
> the second pass.

There's "the first pass", which is guaranteed to occur, and then there's 
"everything else", which is not guaranteed to include a second sequential pass 
through all the packets; if it does, that's an implementation detail.  Building 
up state from a chronological scan of the packets is what you have to do in the 
first pass, with any information you can't recompute from the contents of a 
single packet saved for use when re-dissecting a packet.

If a tree isn't being generated, because it isn't necessary (e.g., if the code 
calling the dissectors is only trying to get the column contents) there's 
presumably no need for TRANSUM - or any other dissector or post-dissector - to 
add anything to the non-existent tree.

So this is a case where a "generate the tree on the first pass" indication is 
what's needed (and that would probably not be needed for post-dissectors that 
only need *particular* field values if there were a way for a post-dissector to 
get the values of those fields without generating a protocol tree, but that's 
the "needs more work" improvement I've mentioned elsewhere).
___
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] Inconsistent availability of proto_tree values during the first of two passes

2017-04-10 Thread Paul Offord 
> Given that there are no such APIs, one would have to be added and, if we're 
> going  to be adding APIs, an API by which a post-dissector can specify that, 
> at least on the first pass through the packets, it requires a protocol tree 
> would be better, as it wouldn't encourage people to write code that works 
> only in Wireshark but not in TShark.

OK but just to be clear, I'm not trying to write a Wireshark-only 
post-dissector.  This is a port of transum.lua which supports Wireshark and 
tshark.

> So would you need the full protocol tree *every* time the packet is 
> dissected, or just the *first* time (meaning you'd save the results of the 
> first-pass processing and not require it later)?

TRANSUM only needs the values in the first pass, but during the second pass it 
adds a section to the end of the visible tree using proto_tree_add_xx 
function and I assume that means it needs the full tree at that point.  I 
imagine other dissectors and post-dissectors would also need the full tree on 
the second pass.

-Original Message-
From: wireshark-dev-boun...@wireshark.org 
[mailto:wireshark-dev-boun...@wireshark.org] On Behalf Of Guy Harris
Sent: 10 April 2017 06:43
To: Developer support list for Wireshark 
Subject: Re: [Wireshark-dev] Inconsistent availability of proto_tree values 
during the first of two passes

On Apr 9, 2017, at 10:37 PM, Paul Offord  wrote:

> Ah that was going to be my next question :-)
> 
> Any ideas?

Given that there are no such APIs, one would have to be added and, if we're 
going  to be adding APIs, an API by which a post-dissector can specify that, at 
least on the first pass through the packets, it requires a protocol tree would 
be better, as it wouldn't encourage people to write code that works only in 
Wireshark but not in TShark.  (The only such code should be taps with a GUI.  
Even the taps that produce tables of information shouldn't be program-dependent 
- there should be a layer that shows the table in text form in TShark and as a 
table window in Wireshark.)

So would you need the full protocol tree *every* time the packet is dissected, 
or just the *first* time (meaning you'd save the results of the first-pass 
processing and not require it later)?
___
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

__

This message contains confidential information and is intended only for the 
individual named. If you are not the named addressee you should not 
disseminate, distribute or copy this e-mail. Please notify the sender 
immediately by e-mail if you have received this e-mail by mistake and delete 
this e-mail from your system.

Any views or opinions expressed are solely those of the author and do not 
necessarily represent those of Advance Seven Ltd. E-mail transmission cannot be 
guaranteed to be secure or error-free as information could be intercepted, 
corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The 
sender therefore does not accept liability for any errors or omissions in the 
contents of this message, which arise as a result of e-mail transmission.

Advance Seven Ltd. Registered in England & Wales numbered 2373877 at Endeavour 
House, Coopers End Lane, Stansted, Essex CM24 1SJ

__
This email has been scanned by the Symantec Email Security.cloud service.
For more information please visit http://www.symanteccloud.com
__
___
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