Re: [Wireshark-dev] Inconsistent availability of proto_tree values during the first of two passes

2017-04-11 Thread Paul Offord
Nice.  I'll take a look.


Sent from Samsung Mobile on O2


 Original message 
From: Guy Harris
Date:12/04/2017 5:35 AM (GMT+00:00)
To: Developer support list for Wireshark
Subject: Re: [Wireshark-dev] Inconsistent availability of proto_tree values 
during the first of two passes

On Apr 11, 2017, at 12:13 AM, Guy Harris  wrote:

> On Apr 10, 2017, at 11:57 PM, Paul Offord  wrote:
>
>> OK - So just to summarize, we need to:
>>
>>   • Short Term - Add a flag somewhere that can be set by a dissector, 
>> post-dissector or tap to request that a proto_tree is produced on the first 
>> pass
>>   • Long Term – Add a facility that allows a dissector, post-dissector 
>> or tap to request a list of specific protocol field values values during the 
>> first pass
>>
>> Is that right?
>
> Something such as that; the short-term solution is exactly that, the 
> long-term solution might involve providing the values of those protocol 
> fields on *every* pass or on the first pass.  (It may also involve the way to 
> deliver them, given that a given protocol might appear more than once in the 
> protocol stack, given various forms of tunneling/encapsulation.)

OK, I've checked in a change that allows a postdissector to specify an array 
(GArray) of hfids for fields that it's going to be extracting from the protocol 
tree.  With that change, when the packets are being read in for the first time, 
*or* redissected after, for example, a preference change, the protocol tree 
will be built if any postdissector has specified any such fields (as well as in 
all the other cases where it currently happens to be built).

I've modified MATE and TRANSUM to use that API if they're enabled.
___
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

Re: [Wireshark-dev] Inconsistent availability of proto_tree values during the first of two passes

2017-04-11 Thread Guy Harris
On Apr 11, 2017, at 12:13 AM, Guy Harris  wrote:

> On Apr 10, 2017, at 11:57 PM, Paul Offord  wrote:
> 
>> OK - So just to summarize, we need to:
>> 
>>  • Short Term - Add a flag somewhere that can be set by a dissector, 
>> post-dissector or tap to request that a proto_tree is produced on the first 
>> pass
>>  • Long Term – Add a facility that allows a dissector, post-dissector or 
>> tap to request a list of specific protocol field values values during the 
>> first pass
>> 
>> Is that right?
> 
> Something such as that; the short-term solution is exactly that, the 
> long-term solution might involve providing the values of those protocol 
> fields on *every* pass or on the first pass.  (It may also involve the way to 
> deliver them, given that a given protocol might appear more than once in the 
> protocol stack, given various forms of tunneling/encapsulation.)

OK, I've checked in a change that allows a postdissector to specify an array 
(GArray) of hfids for fields that it's going to be extracting from the protocol 
tree.  With that change, when the packets are being read in for the first time, 
*or* redissected after, for example, a preference change, the protocol tree 
will be built if any postdissector has specified any such fields (as well as in 
all the other cases where it currently happens to be built).

I've modified MATE and TRANSUM to use that API if they're enabled.
___
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] Can't compile on CentoOS

2017-04-11 Thread Guy Harris
On Apr 11, 2017, at 7:22 AM, Pascal Quantin  wrote:

> As stated in 
> https://www.wireshark.org/docs/wsdg_html_chunked/ChSrcBuildFirstTime.html#_building_on_unix,
>  when using autofoo you are supposed to run ./autogen.sh so as to generate 
> ./configure

...if you're building from a Git checkout rather than from a source tarball.  
The source tarballs include the configure script; the Git repository does *not* 
include the configure script, as it's generated from configure.ac and 
acinclude.m4.
___
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] Can't compile on CentoOS

2017-04-11 Thread Pascal Quantin
2017-04-11 18:28 GMT+02:00 João Valverde :

>
>
> On 04/11/2017 03:22 PM, Pascal Quantin wrote:
>
>> Hi Dan,
>>
>> 2017-04-10 19:43 GMT+02:00 Solis, Daniel M. (ARC-IO)[ASRC RESEARCH &
>> TECHNOLOGY SOLUTIONS]  daniel.m.so...@nasa.gov>>:
>>
>> Hi all,
>>
>> __ __
>>
>> I apologize if this isn’t the right place to post this question, but
>> the “Building and Installing Wireshark” document said “If you cannot
>> determine what the problems are, send an email to
>> the/wireshark-dev/mailing list explaining your problem.”, so here I
>> am.
>>
>> __ __
>>
>> I’m running on an Oracle VM that is running
>> _centos-release-6-7.el6.centos.12.3.x86_64_. And I downloaded the
>> following source package from the git repository. (Although any
>> recent checkin would be fine.)
>>
>> __ __
>>
>> 
>>
>> __ __
>>
>> There is no *configure* file, so I ran *./config.guess* to which I
>> got the following response: *x86_64-unknown-linux-gnu*. So I’m
>> blocked. What do I need to do to get to a compile?
>>
>>
>> As stated in https://www.wireshark.org/docs/wsdg_html_chunked/ChSrcBuildF
>> irstTime.html#_building_on_unix, when using autofoo you are supposed to
>> run ./autogen.sh so as to generate ./configure
>>
>> Alternatively, if you have cmake on your machine, you can run cmake
>> instead of ./autogen.sh followed by ./configure
>>
>
> I think you meant "followed by make" instead?
>

Indeed my wording was not clear. He can either do:
./autogen.sh && ./configure && make
or
cmake && make


>
> Any reason why you are picking the old stable branch?
>>
>> Best regards,
>> Pascal.
>>
>>
>> 
>> ___
>> 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
___
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] Can't compile on CentoOS

2017-04-11 Thread João Valverde



On 04/11/2017 03:22 PM, Pascal Quantin wrote:

Hi Dan,

2017-04-10 19:43 GMT+02:00 Solis, Daniel M. (ARC-IO)[ASRC RESEARCH & 
TECHNOLOGY SOLUTIONS] >:


Hi all,

__ __

I apologize if this isn’t the right place to post this question, but
the “Building and Installing Wireshark” document said “If you cannot
determine what the problems are, send an email to
the/wireshark-dev/mailing list explaining your problem.”, so here I
am.

__ __

I’m running on an Oracle VM that is running
_centos-release-6-7.el6.centos.12.3.x86_64_. And I downloaded the
following source package from the git repository. (Although any
recent checkin would be fine.)

__ __



__ __

There is no *configure* file, so I ran *./config.guess* to which I
got the following response: *x86_64-unknown-linux-gnu*. So I’m
blocked. What do I need to do to get to a compile?


As stated in 
https://www.wireshark.org/docs/wsdg_html_chunked/ChSrcBuildFirstTime.html#_building_on_unix, 
when using autofoo you are supposed to run ./autogen.sh so as to 
generate ./configure


Alternatively, if you have cmake on your machine, you can run cmake 
instead of ./autogen.sh followed by ./configure


I think you meant "followed by make" instead?


Any reason why you are picking the old stable branch?

Best regards,
Pascal.


___
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] Can't compile on CentoOS

2017-04-11 Thread Pascal Quantin
Hi Dan,

2017-04-10 19:43 GMT+02:00 Solis, Daniel M. (ARC-IO)[ASRC RESEARCH &
TECHNOLOGY SOLUTIONS] :

> Hi all,
>
>
>
> I apologize if this isn’t the right place to post this question, but the
> “Building and Installing Wireshark” document said “If you cannot
> determine what the problems are, send an email to the *wireshark-dev* mailing
> list explaining your problem.”, so here I am.
>
>
>
> I’m running on an Oracle VM that is running
> *centos-release-6-7.el6.centos.12.3.x86_64*. And I downloaded the
> following source package from the git repository. (Although any recent
> checkin would be fine.)
>
>
>
>
>
>
>
> There is no *configure* file, so I ran *./config.guess* to which I got
> the following response: *x86_64-unknown-linux-gnu*. So I’m blocked. What
> do I need to do to get to a compile?
>

As stated in
https://www.wireshark.org/docs/wsdg_html_chunked/ChSrcBuildFirstTime.html#_building_on_unix,
when using autofoo you are supposed to run ./autogen.sh so as to generate
./configure

Alternatively, if you have cmake on your machine, you can run cmake instead
of ./autogen.sh followed by ./configure

Any reason why you are picking the old stable branch?

Best regards,
Pascal.
___
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] Can't compile on CentoOS

2017-04-11 Thread Solis, Daniel M. (ARC-IO)[ASRC RESEARCH & TECHNOLOGY SOLUTIONS]
Hi all,

I apologize if this isn't the right place to post this question, but the 
"Building and Installing Wireshark" document said "If you cannot determine what 
the problems are, send an email to the wireshark-dev mailing list explaining 
your problem.", so here I am.

I'm running on an Oracle VM that is running 
centos-release-6-7.el6.centos.12.3.x86_64. And I downloaded the following 
source package from the git repository. (Although any recent checkin would be 
fine.)

  [cid:image003.jpg@01D2B1E7.408E3930]

There is no configure file, so I ran ./config.guess to which I got the 
following response: x86_64-unknown-linux-gnu. So I'm blocked. What do I need to 
do to get to a compile?

Thanks so much,
Dan Solis
___
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] Consolidate the Wireshark developer documentation?

2017-04-11 Thread Remy 'Sieben' Leone
I think it's a very good idea.

The Linux kernel is also on the process of merging all of its documentation
and updating it to Sphinx. They have documentation that is in a very spread
state just like in Wireshark. Maybe Wireshark could follow a similar path?

Here is the current results they have achieved:
https://www.kernel.org/doc/html/latest/

Rémy

Le 11 avr. 2017 06:04, "Guy Harris"  a écrit :

> 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
>
___
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-11 Thread Graham Bloice
For reference, the PowerShell equivalent, note that this will only attempt
to stop a pid once, there may be multiple locking handles for a single pid:

# Stop-ProcessByFileLock
# Stops processes that have an open handle on the path fragment specified

param(
  [parameter(Mandatory=$true)]
  [string]$path
)

$processes = @{}
$handles = handle $path
foreach($line in $handles) {
  if ($line -match "(\S+)\s+pid: (\d*)") {
$processes[$($Matches[1])] = $($Matches[2])
  }
}

foreach($process in $processes.GetEnumerator()) {
Write-Host "Killing process $($process.Name) with pid:$($process.Value)"
Stop-Process -Id $process.Value -Force
}




On 10 April 2017 at 21:36, Maynard, Chris 
wrote:

> 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
> 

Re: [Wireshark-dev] Inconsistent availability of proto_tree values during the first of two passes

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

> OK - So just to summarize, we need to:
>  
>   • Short Term - Add a flag somewhere that can be set by a dissector, 
> post-dissector or tap to request that a proto_tree is produced on the first 
> pass
>   • Long Term – Add a facility that allows a dissector, post-dissector or 
> tap to request a list of specific protocol field values values during the 
> first pass
>  
> Is that right?

Something such as that; the short-term solution is exactly that, the long-term 
solution might involve providing the values of those protocol fields on *every* 
pass or on the first pass.  (It may also involve the way to deliver them, given 
that a given protocol might appear more than once in the protocol stack, given 
various forms of tunneling/encapsulation.)
___
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-11 Thread Paul Offord
OK - So just to summarize, we need to:



  1.  Short Term - Add a flag somewhere that can be set by a dissector, 
post-dissector or tap to request that a proto_tree is produced on the first pass
  2.  Long Term - Add a facility that allows a dissector, post-dissector or tap 
to request a list of specific protocol field values values during the first pass



Is that right?



-Original Message-
From: wireshark-dev-boun...@wireshark.org 
[mailto:wireshark-dev-boun...@wireshark.org] On Behalf Of Guy Harris
Sent: 11 April 2017 04:25
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 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

__

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