Re: [Wireshark-dev] MSVC 2015 (VC14) notes/issue

[Anders Broman]

Graham Bloice skrev den 2015-08-12 19:18:
On 12 August 2015 at 17:57, Pascal Quantin > wrote:


Hi,

Le 12 août 2015 6:21 PM, "Bill Meier" mailto:wme...@newsguy.com>> a écrit :
>
> [Resend]
>
> I see that several people (Anders, ...) been building with
MSVC-2015 (VC14) and have fixed a number of issues.
>
> So: I decided to download VC14 and give it a try (using NMake).
>
> A few questions:
>
> Are you using CMake or NMake ?



I used nmake


>
> If using NMake, I assume that you've updated config.nmake & etc.
Is there some reason you've not committed the changes ?



Graham asked me to hold off until all issues was fixed ad as LUA, GeoIP 
and Qt was excluded I was in no hurry.


>
> If not, I've made what I think are the required changes for
NMake. Do you think it's Ok to commit them ?

I have no objections, it'll be easier to make sure it continues to work 
if the changes are committed.


>
>
>
> Have you been able to do a complete build ?



Yes


>
> So far:
>
> 1. Compiling packet-pdc.c gets:
>
> [...]\packet-pdc.c(205) : fatal error C1001: An internal error
has occurred in the compiler.
> (compiler file 'f:\dd\vctools\compiler\utc\src\p2\main.c', line 246)
>  To work around this problem, try simplifying or changing the
program near the locations listed above.
> Please choose the Technical Support command on the Visual C++
>  Help menu, or open the Technical Support help file for more
information
>
> INTERNAL COMPILER ERROR in 'C:\Program Files\Microsoft Visual
Studio 14.0\VC\BIN\cl.exe'
> Please choose the Technical Support command on the Visual C++
> Help menu, or open the Technical Support help file for more
information
>
> I've figured out what to change to fix this.
> (I've also extracted a much smaller test file which causes the
error and will submit the file to Microsoft).
>



I didn't encounter that problem...


>
>
> 2. I had to disable building with geoip because:
>
> C:\Program Files\Windows
Kits\10\include\10.0.10150.0\ucrt\stdio.h(1925): warning C4005:
'snprintf': macro redefinition (compiling source file packet-
> ip.c)
> [...]\GeoIP-1.5.1-2-win32ws\include\GeoIP.h(36): note: see
previous definition of 'snprintf' (compili
> ng source file packet-ip.c)
> C:\Program Files\Windows
Kits\10\include\10.0.10150.0\ucrt\stdio.h(1927): fatal error
C1189: #error:  Macro definition of snprintf conflicts with Stan
> dard Library function declaration (compiling source file
packet-ip.c)



Yes me too and that's also a comment about it in my commit, same for the 
next point..


>
>
> 3. I disabled building with LUA because there's apparently yet
no LUA library (dll) for use with VC14.

I might have a look at it when coming back from vacation if the
packager I used last time did not update the library (I have no
reliable Internet access right now, yes this is still possible
nowadays :)). But I was not in a hurry as there is no Qt package
compiled with MSVC2015 yet, so we still have a strong dependency
on MSVC2013.

Pascal.

FYI Windows CMake doesn't currently seem to configure without Qt, I'm 
not too fussed about that as on Windows the Qt version is the main build.


The QT folks had previously indicated VS2015 support would be released 
as a 5.5.x release so it's likely not too far off: 
https://blog.qt.io/blog/2015/04/29/windows-10-support-in-qt/


Enjoying your vacation in the mountains Pascal?


--
Graham Bloice


___
Sent via:Wireshark-dev mailing list 
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://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://wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] Windows file wildcard support

[Anders Broman]

Hi,
I don't build with CMAKE currently so I can't test but it might still be a 
problem with setargv
We get this warning on the buildboot:
> LINK : warning LNK4044: unrecognized option '/RELEASE;setargv.obj'; ignored 
> [C:\buildbot\wireshark\wireshark-master-32\windows-8.1-x86\build\cmbuild\epan\epan.vcxproj]

Regards
Anders

-Original Message-
From: wireshark-dev-boun...@wireshark.org 
[mailto:wireshark-dev-boun...@wireshark.org] On Behalf Of Hadriel Kaplan
Sent: den 20 augusti 2015 14:26
To: Developer support list for Wireshark
Subject: [Wireshark-dev] Windows file wildcard support

Howdy,
Can someone with a Windows build platform try building the current repo and run 
the mergecap test suite and figure out how to get the file wildcarding to work? 
The Windows buildbots are failing due to the test suite failing, and it's 
failing because the wildcard method doesn't seem to work in Windows.

It used to work, using nmake, but the buildbots use cmake and it's not working. 
I thought it was just that setargv.obj wasn't being linked in (as happened in 
bug 10354), but even when I added it in this change it's still not working:

https://code.wireshark.org/review/#/c/10143/

Unfortunately I don't have a Windows platform so I'm just shooting in the dark 
trying to get it to work on the buildbots. (it works fine for
Linux/Mac)

-hadriel
___
Sent via:Wireshark-dev mailing list 
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://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://wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] Bug in Wireshark Display filter engine caused by optimization of proto tree during dissect

[Anders Broman]

Den 21 aug 2015 16:37 skrev "Richard Sharpe" :
>
> On Fri, Aug 21, 2015 at 7:34 AM, Jeff Morriss 
wrote:
> > On 08/21/15 10:09, Richard Sharpe wrote:
> >>
> >> Hi folks,
> >>
> >> Below are my findings on the problem I mentioned earlier under the
> >> title of Is this a bug in the display filter engine or something I
> >> have done wrong.
> >>
> >> The problem is that unless the display filter explicitly mentions a
> >> field it will usually be optimized out of the proto tree.
> >>
> >> I would like more input on how to solve this problem.
> >>
> >> One approach I can think if is that the Header Field abbrev field can
> >> include fields that it depends on, eg:
> >>
> >>  {&hf_ieee80211_ff_dmg_params_bss,
> >>   {"BSS Type", "wlan.dmg_params.bss(radiotap.channel.freq)",
> >>FT_UINT8, BASE_DEC, VALS(bss_type), 0x03,
> >>NULL, HFILL }},
> >>
> >> Where the field in parens specifies what other fields this on might
> >> depend on. The filter parser would have to parse them out and include
> >> them in the array of fields of interest.
> >>
> >> However, I wonder if there is an easier way.
> >>
> >> This only seems to be a problem for protocols that depend in some way
> >> on protocols above them.
> >
> >
> > Sorry, I had marked your earlier emails as something to come back
> > to--because I didn't have time, on first reading them, to investigate or
> > think about it.
> >
> > It appears that the 802.11 dissector calls
> > proto_tree_traverse_post_order()/is_80211ad() in order find the value
of a
> > field (hf) named "Channel frequency"; if the value is one of the AD
> > frequencies then the dissector, well, treats it as AD.
> >
> > Isn't this backwards from how Wireshark normally does things?
Shouldn't we
> > be storing the channel frequency somewhere (historically that would be
in
> > pinfo though there's been some effort to get stuff out of there) so
later
> > dissectors can (easily) get the value?
> >
> > (Regardless I think you're fundamentally right: because we fake (most)
items
> > proto_tree_traverse_post_order() can't work unless tree is set.)
>
> Right, this would be a better approach if people are not too
> uncomfortable in storing this piece of info.
>
> Thus, the radiotap (and perhaps one other in the tree that seems to
> know the channel frequency) could store it as a value in the pinfo.
>
> These changes would be much less intrusive in the rest of the
> infrastructure and confined to the ieee80211 series of dissect

It should probably be stored using p_add_packet_data () rather than pinfo
IMHO.

>
> --
> Regards,
> Richard Sharpe
> (何以解憂？唯有杜康。--曹操)
>
___
> Sent via:Wireshark-dev mailing list 
> Archives:https://www.wireshark.org/lists/wireshark-dev
> Unsubscribe: https://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://wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] Bug in Wireshark Display filter engine caused by optimization of proto tree during dissect

[Anders Broman]

Den 21 aug 2015 16:57 skrev "Hadriel Kaplan" :
>
> To be clear, I think he meant: p_add_proto_data()
> (as discussed in the README.dissector section titled "Per-packet
information")
>
> -hadriel

Yes, it's not so easy to look things up on your smartphone while commuting
:-)

>
> On Fri, Aug 21, 2015 at 10:44 AM, Anders Broman 
wrote:
> >
> > Den 21 aug 2015 16:37 skrev "Richard Sharpe" <
realrichardsha...@gmail.com>:
> >>
> >> On Fri, Aug 21, 2015 at 7:34 AM, Jeff Morriss <
jeff.morriss...@gmail.com>
> >> wrote:
> >> > On 08/21/15 10:09, Richard Sharpe wrote:
> >> >>
> >> >> Hi folks,
> >> >>
> >> >> Below are my findings on the problem I mentioned earlier under the
> >> >> title of Is this a bug in the display filter engine or something I
> >> >> have done wrong.
> >> >>
> >> >> The problem is that unless the display filter explicitly mentions a
> >> >> field it will usually be optimized out of the proto tree.
> >> >>
> >> >> I would like more input on how to solve this problem.
> >> >>
> >> >> One approach I can think if is that the Header Field abbrev field
can
> >> >> include fields that it depends on, eg:
> >> >>
> >> >>  {&hf_ieee80211_ff_dmg_params_bss,
> >> >>   {"BSS Type", "wlan.dmg_params.bss(radiotap.channel.freq)",
> >> >>FT_UINT8, BASE_DEC, VALS(bss_type), 0x03,
> >> >>NULL, HFILL }},
> >> >>
> >> >> Where the field in parens specifies what other fields this on might
> >> >> depend on. The filter parser would have to parse them out and
include
> >> >> them in the array of fields of interest.
> >> >>
> >> >> However, I wonder if there is an easier way.
> >> >>
> >> >> This only seems to be a problem for protocols that depend in some
way
> >> >> on protocols above them.
> >> >
> >> >
> >> > Sorry, I had marked your earlier emails as something to come back
> >> > to--because I didn't have time, on first reading them, to
investigate or
> >> > think about it.
> >> >
> >> > It appears that the 802.11 dissector calls
> >> > proto_tree_traverse_post_order()/is_80211ad() in order find the
value of
> >> > a
> >> > field (hf) named "Channel frequency"; if the value is one of the AD
> >> > frequencies then the dissector, well, treats it as AD.
> >> >
> >> > Isn't this backwards from how Wireshark normally does things?
Shouldn't
> >> > we
> >> > be storing the channel frequency somewhere (historically that would
be
> >> > in
> >> > pinfo though there's been some effort to get stuff out of there) so
> >> > later
> >> > dissectors can (easily) get the value?
> >> >
> >> > (Regardless I think you're fundamentally right: because we fake
(most)
> >> > items
> >> > proto_tree_traverse_post_order() can't work unless tree is set.)
> >>
> >> Right, this would be a better approach if people are not too
> >> uncomfortable in storing this piece of info.
> >>
> >> Thus, the radiotap (and perhaps one other in the tree that seems to
> >> know the channel frequency) could store it as a value in the pinfo.
> >>
> >> These changes would be much less intrusive in the rest of the
> >> infrastructure and confined to the ieee80211 series of dissect
> >
> > It should probably be stored using p_add_packet_data () rather than
pinfo
> > IMHO.
> >
> >>
> >> --
> >> Regards,
> >> Richard Sharpe
> >> (何以解憂？唯有杜康。--曹操)
> >>
> >>
___
> >> Sent via:Wireshark-dev mailing list 
> >> Archives:https://www.wireshark.org/lists/wireshark-dev
> >> Unsubscribe: https://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://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://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://wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] Can I compile only the plugins on Windows?

[Anders Broman]

Den 30 aug 2015 10:15 skrev "Adir Shemesh" :
>
> I already have Wireshark compiled, but I'm developing a plugin and
compiling everything takes a lot of time.
> In Linux I can use "make -C plugins" but I couldn't find a solution for
windows.
>

Run the nmake command in the plugins directory, you may have to manually
copy the dll to run dir.
Regards
Anders
>
>
___
> Sent via:Wireshark-dev mailing list 
> Archives:https://www.wireshark.org/lists/wireshark-dev
> Unsubscribe: https://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://wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] MSVC 2015 (VC14) notes/issue

[Anders Broman]

From: wireshark-dev-boun...@wireshark.org 
[mailto:wireshark-dev-boun...@wireshark.org] On Behalf Of Alexis La Goutte
Sent: den 31 augusti 2015 09:43
To: Developer support list for Wireshark
Subject: Re: [Wireshark-dev] MSVC 2015 (VC14) notes/issue



On Sun, Aug 30, 2015 at 11:25 PM, Bill Meier 
mailto:wme...@newsguy.com>> wrote:
On 8/12/2015 12:21 PM, Bill Meier wrote:

2. I had to disable building with geoip because:

#error:  Macro definition of snprintf conflicts with Stan
dard Library function declaration (compiling source file packet-ip.c)



A little digging finds that the Windows Wireshark version of the GeoIP 
library(1.5.2) is a bit old; The current version (on GitHub [1]) is 1.6.6 and 
has had various fixes made since 1.5.2.

I also note that the 1.6.6 GeoIP.h no longer has the macro definition for 
snprintf so the MSVC2015 GeoIP compile problem obviously won't occur using the 
latest version.

I don't really know to create the GeoIP libraries (and couldn't easily do a 64 
bit version anyway) so I'll leave this as a ToDo for others (Gerald ?).

(Obviously there's no urgency for this).

[1] https://github.com/maxmind/geoip-api-c

May be directly move to GeoIP 2 ?
https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=10658

I think the code is available from here:
https://github.com/maxmind/libmaxminddb
Regards
Anders


Cheers,

Bill



___
Sent via:Wireshark-dev mailing list 
mailto:wireshark-dev@wireshark.org>>
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://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://wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] MSVC 2015 (VC14) notes/issue

[Anders Broman]

Den 31 aug 2015 10:24 skrev "Pascal Quantin" :
>
>
> Le 31 août 2015 10:09 AM, "Anders Broman"  a
écrit :
> >
> >
> >
> >
> >
> > From: wireshark-dev-boun...@wireshark.org [mailto:
wireshark-dev-boun...@wireshark.org] On Behalf Of Alexis La Goutte
> > Sent: den 31 augusti 2015 09:43
> > To: Developer support list for Wireshark
> > Subject: Re: [Wireshark-dev] MSVC 2015 (VC14) notes/issue
> >
> >
> >
> >
> >
> >
> >
> > On Sun, Aug 30, 2015 at 11:25 PM, Bill Meier  wrote:
> >
> > On 8/12/2015 12:21 PM, Bill Meier wrote:
> >
> >
> > 2. I had to disable building with geoip because:
> >
> > #error:  Macro definition of snprintf conflicts with Stan
> > dard Library function declaration (compiling source file packet-ip.c)
> >
> >
> >
> > A little digging finds that the Windows Wireshark version of the GeoIP
library(1.5.2) is a bit old; The current version (on GitHub [1]) is 1.6.6
and has had various fixes made since 1.5.2.
> >
> > I also note that the 1.6.6 GeoIP.h no longer has the macro definition
for snprintf so the MSVC2015 GeoIP compile problem obviously won't occur
using the latest version.
> >
> > I don't really know to create the GeoIP libraries (and couldn't easily
do a 64 bit version anyway) so I'll leave this as a ToDo for others (Gerald
?).
> >
> > (Obviously there's no urgency for this).
> >
> > [1] https://github.com/maxmind/geoip-api-c
> >
> >
> >
> > May be directly move to GeoIP 2 ?
> > https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=10658
> >
> >
> >
> > I think the code is available from here:
> >
> > https://github.com/maxmind/libmaxminddb
>
> Hi all,
>
> I propose to do it in 2 steps as changing the library is more work than
upgrading the current one:
> - first recompile version 1.6.6 and see if it solves the build issue with
MSVC2015 (I'm gonna cross compile it as I have the environment). I will
send an email once it is ready for testing (as I did for Lua).
> - then eventually change the library (and keep backward compatibility
with the older one?).
>
> Cheers,
> Pascal.
>

Sounds good to me.
Regards
Anders

>
>
___
> Sent via:Wireshark-dev mailing list 
> Archives:https://www.wireshark.org/lists/wireshark-dev
> Unsubscribe: https://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://wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] Integrating the HAPViewer code.

[Anders Broman]

>>Hi Anders,
>>
>>Thank you for your email. Here are some comments:
>>
>>Hi,
>>Here's my take on how to do it, please correct me if I'm wrong or fill in any 
>>missing details.
>>
>>Licensing and author files needs to be sorted out before any code can be 
>>committed.

>I moved license and author information into the individual files as you have 
>asked and pushed it.


>>Building the code should be optional and depending on availability of the 
>>GRAPViz library and configuration of makefiles. This is >>independent of 
>>platform.

>Currently, this is not the case as the code is built in any case. The idea was 
>to include the extension by default ;-). Joking aside, what I >have tried was 
>to support Windows and Ubuntu. Therefore, I included and changed everything 
>that was needed to make it work.
>For sure, it is possible to build it optionally depending on the availability 
>of graphviz.

>>I would suggest that it's easiest to try this out on a *nix system first as 
>>it's a bit more complicated build wise and for the installer on >>Windows. I 
>>don't know much about auto tools or cmake files so someone else needs to help 
>>out here. When we have it working on *nix >>the source code could be 
>>committed in my opinion which would make it a bit simpler to work on a 
>>separate patch to get the build system >>in place for Windows and many 
>>problems may have been sorted out.
>>As I understand it the code would have to be protected by #ifdef 
>>HAVE_GRAPHVIZ or something like it. No header files from graphviz >>should be 
>>included instead a graphviz dev package would be required on the build 
>>system. Once it builds with and without the graphviz >>library we can move on 
>>to windows.

>I  agree with your explanation, it is not easy to support both systems. Alexis 
>asked me to split the patch and remove the graphviz dll’s. >Right now, my 
>patch does not include the dll files and therefore, it supports only *nix 
>systems. Building Wireshark with “Host Flows” on >Ubuntu requires the graphviz 
>dev package and the following commands:
>./autogen.sh
>./configure CXX=g++ CXXFLAGS="-std=c++11 -Wno-error=literal-suffix 
>-Wno-error=unused-parameter" --with-geoip
>make
>
>Currently, there is no condition whether the graphviz library is available or 
>not and therefore, whether the feature should be built or not. >This needs to 
>be done.

>>Personally, I do not know how to add a condition to the build process (such 
>>as --without-HAPviewer) but I can extend the code by >>#ifdef >HAVE_GRAPHVIZ 
>>or something similar. After these changes, the source code should work on 
>>*nix.

>On windows we need the graphviz windows package in our package storage the 
>nmake setup target should download it and unpack it to a >directory where the 
>makefile will find the headers and copy whatever is needed first to the run 
>directory wireshark-gtk2 or a subfolder (with >nmake at least). Then the 
>installer will need to include needed files and unpack them to appropriate 
>directories when installing. In your >original patch it looked like graphviz 
>came with it's own GTK dlls, is that really needed? it would bloat the 
>installation a bit.
>In my original patch, I included the graphviz windows package in the source 
>code (I missed the idea to put the package in the package >storage). During 
>the built process, I copied whatever is needed to the run directory or to the 
>appropriate directories when installing. I >have to check whether the graphviz 
>GTK dlls are really needed or the standard GTK dlls are sufficient.
>
>Best Regards,
>Pascal
I copied in this from gerrit as it seems easier to discuss it here
It seems like licensing may still be a problem ☹
Pascal Q:
Finally I see that QGV is released under the LGPLv3 license, which is not 
compatible with GPLv2 according to 
http://www.gnu.org/licenses/license-list.html#LGPLMy understanding is that 
Wiresahrk is released under GPLv2, and not GPLv2 or later, so this could be a 
blocker point. Gerald, am I correct or did I misunderstand the license we are 
using?
Wireshark is "GPLv2 or later". As I understand things, shipping packages linked 
with an LGPLv3 library would mean that we would be distributing Wireshark under 
the GPLv3. I'm not opposed to downstream projects doing this, and I'm not 
opposed to switching licenses. It *is* something that should be decided by the 
community, however.QGV's license isn't entirely clear. Although much of the 
source code says LGPLv3, the LICENSE.txt file says LGPLv2.1. I opened a ticket 
asking for cla

Re: [Wireshark-dev] Greetings and Where to Start

[Anders Broman]

Hi,
If the object is
> in optimizing code using data structures
In what way to make it run faster? Wiresharks innards are quite complicated and 
may take a while to get the hang of but if it would be possible
To optimize in terms of memory usage or execution speed it would be very 
beneficial for the performance.

-  The packet list handling /ui/qt/ packet_list.cpp would be the place 
to start

-  Reassembly (epan/reassembly.c)

-  Conversations(hastable sizes and lookup) (epan/conversations.c)

-  Epan/proto.c
You’d probably need a large capture file and run profiling on it to find the 
hot spots which may vary depending on the protocol mix in the capture and
Whether the GUI version (Wirsehark) or the cl version ( tshark) are used and if 
filters are applied or not.

Regards
Anders

From: wireshark-dev-boun...@wireshark.org 
[mailto:wireshark-dev-boun...@wireshark.org] On Behalf Of Breanna 
Devore-McDonald
Sent: den 8 september 2015 09:12
To: wireshark-dev@wireshark.org
Subject: [Wireshark-dev] Greetings and Where to Start

Hello,

My name is Breanna and I am a junior Computer Science/ Cyber Security undergrad 
at the University of Notre Dame. I am currently in a Data Structures course 
which requires me to find an interesting open-source project to *hopefully* 
contribute to, using the knowledge I should gain throughout the semester in 
optimizing code using data structures. I recently heard of Wireshark through my 
Computer Networks course and I am very interested and would love to find a way 
to contribute. However, I have no idea where to start. Do you think there's any 
place in the Wireshark code where I could help? (Or maybe, if it seems 
Wireshark is not the right fit for me, do you know of any projects that could 
fit?)

Any help would be greatly appreciated!
-Breanna

--
Breanna DeVore-McDonald
University of Notre Dame '17
Computer Science
bdevo...@nd.edu
530-276-4805
___
Sent via:Wireshark-dev mailing list 
Archives:https://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] Index of multiple protocol frames in one packet?

[Anders Broman]

Den 6 okt 2015 08:07 skrev "Petr Gotthard" :
>
> Hello,
>
> Is there a way to distinguish multiple frames of the same protocol in one
TCP/IP packet? I have several small AMQP frames which all fit into a single
IP frame, so they share a single packet_info structure.When I call
p_add_proto_data() for the second AMQP frame, it (obviously) overwrites
data stored for the first frame, so I need to distibguish between them
somehow.
>
> Is there a counter that would tell me "this is a third AMQP frame in this
pinfo"? I found packet_info->curr_layer_num, but this is useful for nested
frames (like IP in IP). Is there something similar for groupped frames,
please?

Curr_layer_number is supposed to be used as the key in p_add_proto_data()

Regards
Andets

>
>
> Thanks,
> Petr
>
___
> Sent via:Wireshark-dev mailing list 
> Archives:https://www.wireshark.org/lists/wireshark-dev
> Unsubscribe: https://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://wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] Index of multiple protocol frames in one packet?

[Anders Broman]

From: wireshark-dev-boun...@wireshark.org 
[mailto:wireshark-dev-boun...@wireshark.org] On Behalf Of Pascal Quantin
Sent: den 12 oktober 2015 17:43
To: Developer support list for Wireshark
Subject: Re: [Wireshark-dev] Index of multiple protocol frames in one packet?



2015-10-12 17:35 GMT+02:00 Jeff Morriss 
mailto:jeff.morriss...@gmail.com>>:
On 10/06/15 02:17, Pascal Quantin wrote:


2015-10-06 8:07 GMT+02:00 Petr Gotthard 
mailto:petr.gotth...@centrum.cz>
>>:

Hello,

Is there a way to distinguish multiple frames of the same protocol
in one TCP/IP packet? I have several small AMQP frames which all fit
into a single IP frame, so they share a single packet_info
structure.When I call p_add_proto_data() for the second AMQP frame,
it (obviously) overwrites data stored for the first frame, so I need
to distibguish between them somehow.

Is there a counter that would tell me "this is a third AMQP frame in
this pinfo"? I found packet_info->curr_layer_num, but this is useful
for nested frames (like IP in IP). Is there something similar for
groupped frames, please?


Hi Peter,

I'm not sure we have such counter, but
https://code.wireshark.org/review/#/c/10579/ suggested the use of
tvb_raw_offset as key for p_(add|get)_proto_data() functions which seems
a good tradeoff.

Actually there is such a counter in frame_data: subnum.  But it's not widely 
used: for now it's only used in EPL, RRC, and UMTS_FP.

Thanks for the hint Jeff (I did not know this one).
It appears that frame_data.c is only setting it to 0, and that increment need 
to be handled directly by dissectors. So it means that for a wider usage, 
(tcp|udp)_dissect_pdus() function (among others) should be modified so as to 
increment it when calling a new subdissector.
Cheers,
Pascal.

Pinfo-> curr_layer_num is supposed to handle it I think but the problem may be 
to have the TCP/UDP/?/ Dissector call the same dissector again if the complete 
tvb wasn’t used. If the dissector itself is looping over the data it should 
probably use call_disector() or something rather than do an internal loop.
Regards
Anders

___
Sent via:Wireshark-dev mailing list 
Archives:https://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] Supported GnuTLS/glib/libgcrypt versions?

[Anders Broman]

Den 15 okt 2015 19:43 skrev "Jeff Morriss" :
>
> On 10/14/15 14:25, Peter Wu wrote:
>>
>> On Mon, Oct 12, 2015 at 02:02:18PM -0400, Jeff Morriss wrote:
>>>
>>> But you do raise a good point: I should start doing test compiles of
the 2.0
>>> rc on RHEL 6.  I hadn't realized my users would have to continue using
the
>>> Gtk+ GUI.  Too bad...
>>
>>
>> I have started testing with cmake + CentOS 6, it is not doing bad. At
>> least these fixes are needed to fix the build:
>> https://code.wireshark.org/review/10916
>> https://code.wireshark.org/review/11041
>
>
> Funny, I actually didn't have any problems (once I updated my
(customized) RPM spec file with some of the changes from master).  But
rpmbuild is using autotools and building from the source tarball.
>
>
 Speaking of bumping library versions, can we also bump the glib and
 libgcrypt versions? Current versions are glib 2.14 and libgcrypt
 1.1.92. If we could go to glib 2.28 (Feb 2011) and gcrypt 1.5.0 (Jun
 2011), it would enable us to use newer functions such as
 g_list_free_full.
>>>
>>>
>>> The glib change is OK for me (for RHEL 6) but it does appear to mean
we'd
>>> lose support for all SLES versions; I'd tend to think that would be a
bad
>>> thing.
>>
>>
>> I made a mistake, SLES 12 includes glib2 2.38.2, the wiki is now updated
>> to reflect that. For now the minimum gcrypt version is 1.4.2
>> (https://code.wireshark.org/review/11043).
>
>
> So bumping the glib version means we'd lose SLES 11.  Given how recent
(for an enterprise version) SLES 12 is I'd guess there are still a lot of
SLES 11 users out there.
>
>
I'm need to build on SLES11 so please don't break that.

>
___
> Sent via:Wireshark-dev mailing list 
> Archives:https://www.wireshark.org/lists/wireshark-dev
> Unsubscribe: https://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://wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] GTP sequence number equal to zero problem

[Anders Broman]

Hi,
You are supposed to try to fix the compilation errors even if you can’t verify 
the fix yourself. If you follow the link to the failing build bot and then 
click on
stdio
 of that link you can see the error log at least some of it should be pretty 
obvious how to fix. Once done we will rerun the build boot for you.

Regards
Anders
From: wireshark-dev-boun...@wireshark.org 
[mailto:wireshark-dev-boun...@wireshark.org] On Behalf Of POZUELO Gloria 
(BCS/PSD)
Sent: den 4 november 2015 10:38
To: Developer support list for Wireshark
Subject: Re: [Wireshark-dev] GTP sequence number equal to zero problem

Hello again,

I’ve received an email in which I’m notified that there’s a buildbot failure on 
Ubuntu regarding to this fix. Do I have to do something else concerning to this 
fix or do you take over this problem? I’m developing for Windows platform, so I 
don’t have the needed platform to debug that compilation error.

Regards.

From: 
wireshark-dev-boun...@wireshark.org 
[mailto:wireshark-dev-boun...@wireshark.org] On Behalf Of POZUELO Gloria 
(BCS/PSD)
Sent: Tuesday 3 November 2015 16:33
To: Developer support list for Wireshark
Subject: Re: [Wireshark-dev] GTP sequence number equal to zero problem

Thank you Pascal. I’ll fix the bug then ☺

Regards.

From: 
wireshark-dev-boun...@wireshark.org 
[mailto:wireshark-dev-boun...@wireshark.org] On Behalf Of Pascal Quantin
Sent: Tuesday 3 November 2015 16:27
To: Developer support list for Wireshark
Subject: Re: [Wireshark-dev] GTP sequence number equal to zero problem



2015-11-03 16:13 GMT+01:00 POZUELO Gloria (BCS/PSD) 
mailto:gloria.pozu...@bics.com>>:
Hi all,

I’m developing an extension for the GTPv1 dissector and while I was debugging 
I’ve encountered something that it seems to me a bit confusing. In the 
dissect_gtp_common function from the packet-gtp.c source, there is a section 
that makes the matching between requests and responses. The thing is that I 
have a pcap in which I have a create PDP context request with sequence number 
equal to 0, then when in the code asks if the message has sequence number, it 
never enters in that part because, I guess, that 0 is equal than NULL.

If (seq_no) {
/* matching is done */
}

I don’t know If this is a little bug or maybe the sequence number can’t be 
equal to 0. Can someone help me?

Thanks!

Regards.


Hi Gloria,
at first glance this seems to be a bug. Per 3GPP 29.060 chapter 
9.3.1.1:
9.3.1.1 Usage of Sequence Number
The sending GGSN and SRNC shall use 0 for the value of the Sequence Number of 
the first G-PDU in a tunnel, only during the PDP context activation, and shall 
increment the Sequence Number for each following G-PDU. The value shall wrap to 
zero after 65535.
The receiving GGSN and SRNC shall set the content of a counter to zero, only 
during the PDP context activation. When the receiving GGSN and SRNC receives a 
valid G-PDU, it shall increment this counter by one. This counter shall wrap to 
zero after 65535. It defines the "Expected Sequence Number".

Could you please fill a bug on https://bugs.wireshark.org and even better, 
upload a fix on Gerrit (see 
https://www.wireshark.org/docs/wsdg_html_chunked/ChSrcContribute.html for 
details) ? Presumably we should have a booleab telling whether a sequence 
number was retrieved or not and test it (instead of seq_no being different from 
0).
Regards,
Pascal.



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

[Wireshark-dev] The GTK version of the internals menu dissector tables crashes.

[Anders Broman]

(lt-wireshark-gtk:3404): Gtk-CRITICAL **: gtk_tree_view_get_model: assertion 
'GTK_IS_TREE_VIEW (tree_view)' failed
**
ERROR:dissector_tables_dlg.c:159:decode_proto_add_to_list: code should not be 
reached
___
Sent via:Wireshark-dev mailing list 
Archives:https://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] The GTK version of the internals menu dissector tables crashes.

[Anders Broman]

Hi,
The switch needs FT_GUID ... should that be handled as FT_BYTES or FT_STRING, 
new tab for GUI tables?

From: wireshark-dev-boun...@wireshark.org 
[mailto:wireshark-dev-boun...@wireshark.org] On Behalf Of Anders Broman
Sent: den 6 november 2015 14:39
To: wireshark-dev@wireshark.org
Subject: [Wireshark-dev] The GTK version of the internals menu dissector tables 
crashes.

(lt-wireshark-gtk:3404): Gtk-CRITICAL **: gtk_tree_view_get_model: assertion 
'GTK_IS_TREE_VIEW (tree_view)' failed
**
ERROR:dissector_tables_dlg.c:159:decode_proto_add_to_list: code should not be 
reached
___
Sent via:Wireshark-dev mailing list 
Archives:https://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] Dissect using val_to_str from external file

[Anders Broman]

Hi,
If I remember correctly there is a problem to use data between .dlls on 
Windows. You can copy the value string to your plugin I suppose.
Regards
Anders

-Original Message-
From: wireshark-dev-boun...@wireshark.org 
[mailto:wireshark-dev-boun...@wireshark.org] On Behalf Of Jo
Sent: den 11 november 2015 14:39
To: Developer support list for Wireshark
Subject: Re: [Wireshark-dev] Dissect using val_to_str from external file

Hello,

I did this now for the functions in my other question
(http://seclists.org/wireshark/2015/Nov/78) but I have no idea how to get this 
working for val_to_str() in my plugin file.

In my source file, i include  and Visual Studio does only 
complain at compile time about unresolved external symbols (LNK2001). Can 
someone please help me on how to access ipproto_val_ext from a plugin?

No plugin from the Wireshark sources seem to use external val_to_str() calls as 
of now.

Bye,
Jo

2015-11-11 12:20 GMT+01:00 Graham Bloice :
>
>
> On 11 November 2015 at 10:33, Jo  wrote:
>>
>> Hello Graham,
>>
>> Thank you.
>>
>> Is this set of exported symbols meant to be extended on user request?
>> Or what is the correct way to gain access to symbols that are not yet 
>> marked for export?
>>
>
> If you can manage with local changes, edit away.
>
> If you want to push those changes back to Wireshark so you don't have 
> to apply your local change every time you update your sources then 
> submit a change (https://wiki.wireshark.org/Development/SubmittingPatches).
>
> --
> Graham Bloice
>
> ___
> Sent via:Wireshark-dev mailing list 
> Archives:https://www.wireshark.org/lists/wireshark-dev
> Unsubscribe: https://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://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://wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] When is the preference variable updated?

[Anders Broman]

Hi,
If you look in epan/prefs.h you can see that the second argument is a callback 
function
prefs_register_protocol(int id, void (*apply_cb)(void));

In packet-sip.c
sip_module = prefs_register_protocol(proto_sip, proto_reg_handoff_sip);

So proto_reg_handoff_sip is called every time the preference is changed and at 
startup so you need to arrange
To handle the value there.

Regards
Anders

From: wireshark-dev-boun...@wireshark.org 
[mailto:wireshark-dev-boun...@wireshark.org] On Behalf Of Paul Offord
Sent: den 12 november 2015 15:08
To: wireshark-dev@wireshark.org
Subject: [Wireshark-dev] When is the preference variable updated?

Hi,

Frankly I feel a bit stupid asking this but I've been trying to figure it out 
for about 6 hours and I think I need help.  I have a dissector which I register 
like this:

static int tmsvc_port = 0;

void
proto_register_tmsvc(void)
{
module_t *tmsvc_module;

proto_tmsvc = proto_register_protocol("TM Syncro Service",
  "TmSyncro",
  "tmsvc");

tmsvc_module = prefs_register_protocol(proto_tmsvc, NULL);

prefs_register_uint_preference(tmsvc_module, "port",
   "TmSyncro service port",
   "When set to a value greater than 0 the 
TmSyncro service is started and accessible via the port number"
   10,
   &tmsvc_port);

}

Immediately after the prefs_register_uint_preference call I check the 
tmsvc_port value and its still 0 (and I've tried other initialisation values 
and they remain unchanged).  I was expecting tmsvc_port to be set to the value 
I last set by editing the preferences through the Wireshark menu system.

If I check with Menu -> Edit -> Preferences -> Protocols -> TmSyncro sure 
enough the value I last set is there.

When does my variable get updated?  Or alternatively, how can I retrieve the 
saved preference value?

Thanks and regards...Paul

Paul Offord FBCS CITP
Chief Technical Officer
Advance7

Phone:  01279 211 668
Mobile:  07764 931 431
Email:  paul.off...@advance7.com
LinkedIn:  https://uk.linkedin.com/in/paulofford


__

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://wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] Buildbots

[Anders Broman]

From: wireshark-dev-boun...@wireshark.org 
[mailto:wireshark-dev-boun...@wireshark.org] On Behalf Of Dario Lombardo
Sent: den 20 november 2015 10:52
To: Developer support list for Wireshark
Subject: Re: [Wireshark-dev] Buildbots


On Thu, Nov 19, 2015 at 5:59 PM, Graham Bloice 
mailto:graham.blo...@trihedral.com>> wrote:
There's also the:

2.0 buildbot - https://buildbot.wireshark.org/wireshark-2.0/waterfall
1.12 buildbot - https://buildbot.wireshark.org/wireshark-1.12/waterfall
Debian LTS buildbot - https://buildbot.wireshark.org/wireshark-lts/waterfall

These are all listed on the develop page - 
https://www.wireshark.org/develop.html#buildbot

I believe they are automatically triggered on commits to the respective 
branches.


Is there a reason why the projects contain different buildbots (e.g. the 
petri-dish doesn't contain the osx buildbot)?

Availability of HW I think.

Regards
Anders

___
Sent via:Wireshark-dev mailing list 
Archives:https://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] Setting up git for gerrit

[Anders Broman]

Hi,
Have you tried GIT GUI that worked better for me…You need your HTTP password 
from “settings” on gerrit.
Regards
Anders

From: wireshark-dev-boun...@wireshark.org 
[mailto:wireshark-dev-boun...@wireshark.org] On Behalf Of Paul Offord
Sent: den 30 november 2015 10:04
To: Developer support list for Wireshark
Subject: Re: [Wireshark-dev] Setting up git for gerrit

Just to complete the story so far.  SSH appears to be set up correctly.  I get 
this:

C:\Development\Wireshark>ssh -p 29418 
usern...@code.wireshark.org
Enter passphrase for key '/home/my_userid/.ssh/id_rsa':

  Welcome to Gerrit Code Review

  Hi Paul Offord, you have successfully connected over SSH.

  Unfortunately, interactive shells are disabled.
  To clone a hosted Git repository, use:

  git clone ssh://usern...@code.wireshark.org:29418/REPOSITORY_NAME.git

Connection to code.wireshark.org closed.

If I then try git review I get this:

C:\Development\Wireshark>git review
Problem running 'git remote update origin'
Fetching origin
Permission denied (publickey).
fatal: Could not read from remote repository.

Please make sure you have the correct access rights
and the repository exists.
error: Could not fetch origin

There definitely seems to be a problem with the linkage between git and SSH.

Best regards…Paul

From: 
wireshark-dev-boun...@wireshark.org 
[mailto:wireshark-dev-boun...@wireshark.org] On Behalf Of Paul Offord
Sent: 30 November 2015 08:32
To: Developer support list for Wireshark 
mailto:wireshark-dev@wireshark.org>>
Subject: Re: [Wireshark-dev] Setting up git for gerrit

Hi Graham,

That may explain why I am having a frustrating time with this.  I’ve spent 
about 6 hours so far trying to push a fix to gerrit – I had all but given up.  
In answer to your questions:


•git --version is git version 2.6.2.windows.1

•git-review --version is git-review version 1.25.0

•where.exe ssh.exe gives C:\cygwin64\bin\ssh.exe

•python --version give Python 2.7.10

Best regards…Paul

From: 
wireshark-dev-boun...@wireshark.org 
[mailto:wireshark-dev-boun...@wireshark.org] On Behalf Of Graham Bloice
Sent: 30 November 2015 07:40
To: Developer support list for Wireshark 
mailto:wireshark-dev@wireshark.org>>
Subject: Re: [Wireshark-dev] Setting up git for gerrit



On 29 November 2015 at 23:19, Paul Offord 
mailto:paul.off...@advance7.com>> wrote:
Hi,

I’m trying to setup git so that I can submit a change to gerrit.  Although I 
can use git pull to update the code, when I try git review I get:

C:\Development\Wireshark>git review
bash: /dev/tty: No such device or address
error: failed to execute prompt script (exit code 1)
fatal: could not read Username for 'https://code.wireshark.org': Invalid 
argument

I’m pretty sure this is an authentication issue.  I’ve set my SSH public key in 
gerrit and an HTTPS password.  Details of the access are:

C:\Development\Wireshark>git remote -v
origin  https://code.wireshark.org/review/wireshark (fetch)
origin  https://code.wireshark.org/review/wireshark (push)

What should git remote –v look like if I have things setup correctly?

Thanks and regards…Paul


Note that the latest git for Windows causes some issues with git review, 
depending on how you install it.

So firstly your environment, what is your git version (git --version), 
git-review version (git-review --version) and do you have ssh.exe from 
path\to\git\usr\bin on the path (where.exe ssh.exe)?

Are you running a Windows native python, what version of python?



--
Graham Bloice

__

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
__

Re: [Wireshark-dev] Wireshark Performance

[Anders Broman]

Hi,
Running valgrind on my standard pcap we have gone from
==36946== Callgrind, a call-graph generating cache profiler
==36946== Copyright (C) 2002-2013, and GNU GPL'd, by Josef Weidendorfer et al.
==36946== Using Valgrind-3.10.0.SVN and LibVEX; rerun with -h for copyright info
==36946== Command: /home/ericsson/wireshark/.libs/lt-tshark -Y frame -nr 
/home/ericsson/etxrab/TCT_SIP_traffic.pcapng
==36946==
==36946== For interactive control, run 'callgrind_control -h'.
==36946==
==36946== Events: Ir
==36946== Collected : 18211043816
==36946==
==36946== I   refs:  18,211,043,816

to

==4865==
==4865== Events: Ir
==4865== Collected : 1595333469530
==4865==
==4865== I   refs:  1,595,333,469,530

The big difference seems to be

Latest  June
87.95  37.92 6 076 548  g_hastable_lookup  5.56 2.98 6 515 523

Looking deeper
49.43 25 142 686 213 conversation_match_exact 0.32 576 548

Regards
Anders


From: wireshark-dev-boun...@wireshark.org 
[mailto:wireshark-dev-boun...@wireshark.org] On Behalf Of POZUELO Gloria 
(BCS/PSD)
Sent: den 2 december 2015 14:01
To: Developer support list for Wireshark; alexis.lagou...@gmail.com
Subject: Re: [Wireshark-dev] Wireshark Performance

I’ve been testing the performance a little more and it seems that the loading 
time has increased not only for GTP protocol. I have sniffed a pcap composed by 
22844 packets and if you open it up with both versions, v2.0 lasts 0.520s and 
v2.1 lasts 1.433s. But as you saw before for GTP protocol is even worse, I’ll 
try to get a pcap example that I can share.

Regards.

From: 
wireshark-dev-boun...@wireshark.org 
[mailto:wireshark-dev-boun...@wireshark.org] On Behalf Of POZUELO Gloria 
(BCS/PSD)
Sent: Wednesday 2 December 2015 09:13
To: alexis.lagou...@gmail.com; Developer 
support list for Wireshark
Subject: Re: [Wireshark-dev] Wireshark Performance

I can’t share this one, because it has user data and it’s confidential, but we 
are going to generate another one that can be share. We are using GTP protocol, 
if that gives you a clue.

From: 
wireshark-dev-boun...@wireshark.org 
[mailto:wireshark-dev-boun...@wireshark.org] On Behalf Of Alexis La Goutte
Sent: Wednesday 2 December 2015 09:08
To: Developer support list for Wireshark
Subject: Re: [Wireshark-dev] Wireshark Performance

You can directly add the text output of load time...
It is possible to share your pcap ?

On Wed, Dec 2, 2015 at 9:04 AM, POZUELO Gloria (BCS/PSD) 
mailto:gloria.pozu...@bics.com>> wrote:
I attach the screen captures better.

From: 
wireshark-dev-boun...@wireshark.org 
[mailto:wireshark-dev-boun...@wireshark.org]
 On Behalf Of POZUELO Gloria (BCS/PSD)
Sent: Wednesday 2 December 2015 08:53
To: Developer support list for Wireshark
Subject: [Wireshark-dev] Wireshark Performance

Hello,
Here is the loading time difference between the v2.0 and the last automated 
build for win64 
Wireshark-win64-2.1.0-875-g9779ae3.exe
[Imágenes integradas 2][Imágenes integradas 1]
Regards.



 DISCLAIMER
http://www.bics.com/maildisclaimer/

___
Sent via:Wireshark-dev mailing list 
mailto:wireshark-dev@wireshark.org>>
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://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://wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] Wireshark Performance

[Anders Broman]

From: wireshark-dev-boun...@wireshark.org 
[mailto:wireshark-dev-boun...@wireshark.org] On Behalf Of Anders Broman
Sent: den 2 december 2015 15:41
To: Developer support list for Wireshark; alexis.lagou...@gmail.com
Subject: Re: [Wireshark-dev] Wireshark Performance

Hi,
Running valgrind on my standard pcap we have gone from
==36946== Callgrind, a call-graph generating cache profiler
==36946== Copyright (C) 2002-2013, and GNU GPL'd, by Josef Weidendorfer et al.
==36946== Using Valgrind-3.10.0.SVN and LibVEX; rerun with -h for copyright info
==36946== Command: /home/ericsson/wireshark/.libs/lt-tshark -Y frame -nr 
/home/ericsson/etxrab/TCT_SIP_traffic.pcapng
==36946==
==36946== For interactive control, run 'callgrind_control -h'.
==36946==
==36946== Events: Ir
==36946== Collected : 18211043816
==36946==
==36946== I   refs:  18,211,043,816

to

==4865==
==4865== Events: Ir
==4865== Collected : 1595333469530
==4865==
==4865== I   refs:  1,595,333,469,530

The big difference seems to be

Latest  June
87.95  37.92 6 076 548  g_hastable_lookup  5.56 2.98 6 515 523

Looking deeper
49.43 25 142 686 213 conversation_match_exact 0.32 576 548

decode_udp_ports seems much more expensive

Regards
Anders


From: 
wireshark-dev-boun...@wireshark.org<mailto:wireshark-dev-boun...@wireshark.org> 
[mailto:wireshark-dev-boun...@wireshark.org] On Behalf Of POZUELO Gloria 
(BCS/PSD)
Sent: den 2 december 2015 14:01
To: Developer support list for Wireshark; 
alexis.lagou...@gmail.com<mailto:alexis.lagou...@gmail.com>
Subject: Re: [Wireshark-dev] Wireshark Performance

I’ve been testing the performance a little more and it seems that the loading 
time has increased not only for GTP protocol. I have sniffed a pcap composed by 
22844 packets and if you open it up with both versions, v2.0 lasts 0.520s and 
v2.1 lasts 1.433s. But as you saw before for GTP protocol is even worse, I’ll 
try to get a pcap example that I can share.

Regards.

From: 
wireshark-dev-boun...@wireshark.org<mailto:wireshark-dev-boun...@wireshark.org> 
[mailto:wireshark-dev-boun...@wireshark.org] On Behalf Of POZUELO Gloria 
(BCS/PSD)
Sent: Wednesday 2 December 2015 09:13
To: alexis.lagou...@gmail.com<mailto:alexis.lagou...@gmail.com>; Developer 
support list for Wireshark
Subject: Re: [Wireshark-dev] Wireshark Performance

I can’t share this one, because it has user data and it’s confidential, but we 
are going to generate another one that can be share. We are using GTP protocol, 
if that gives you a clue.

From: 
wireshark-dev-boun...@wireshark.org<mailto:wireshark-dev-boun...@wireshark.org> 
[mailto:wireshark-dev-boun...@wireshark.org] On Behalf Of Alexis La Goutte
Sent: Wednesday 2 December 2015 09:08
To: Developer support list for Wireshark
Subject: Re: [Wireshark-dev] Wireshark Performance

You can directly add the text output of load time...
It is possible to share your pcap ?

On Wed, Dec 2, 2015 at 9:04 AM, POZUELO Gloria (BCS/PSD) 
mailto:gloria.pozu...@bics.com>> wrote:
I attach the screen captures better.

From: 
wireshark-dev-boun...@wireshark.org<mailto:wireshark-dev-boun...@wireshark.org> 
[mailto:wireshark-dev-boun...@wireshark.org<mailto:wireshark-dev-boun...@wireshark.org>]
 On Behalf Of POZUELO Gloria (BCS/PSD)
Sent: Wednesday 2 December 2015 08:53
To: Developer support list for Wireshark
Subject: [Wireshark-dev] Wireshark Performance

Hello,
Here is the loading time difference between the v2.0 and the last automated 
build for win64 
Wireshark-win64-2.1.0-875-g9779ae3.exe<https://www.wireshark.org/download/automated/win64/Wireshark-win64-2.1.0-875-g9779ae3.exe>
[Imágenes integradas 2][Imágenes integradas 1]
Regards.



 DISCLAIMER
http://www.bics.com/maildisclaimer/

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

___
Sent via:Wireshark-dev mailing list 
Archives:https://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 Performance

[Anders Broman]

Hi,
It’s probably deeper down, dissect_stun_heur has gone from 3.51 to 14.06.
@ Gloria can you try to turn the stun heuristic off to see if it makes a 
difference?
Regards
Anders

From: wireshark-dev-boun...@wireshark.org 
[mailto:wireshark-dev-boun...@wireshark.org] On Behalf Of Evan Huus
Sent: den 2 december 2015 16:02
To: Developer support list for Wireshark
Subject: Re: [Wireshark-dev] Wireshark Performance

The only recent change to conversation_match_exact was the conversion from 
address macros to functions, but in all cases the macros were just pointing to 
the functions anyways so I can't imagine that would have a huge effect on 
performance?

On Wed, Dec 2, 2015 at 9:45 AM, Anders Broman 
mailto:anders.bro...@ericsson.com>> wrote:


From: 
wireshark-dev-boun...@wireshark.org<mailto:wireshark-dev-boun...@wireshark.org> 
[mailto:wireshark-dev-boun...@wireshark.org<mailto:wireshark-dev-boun...@wireshark.org>]
 On Behalf Of Anders Broman
Sent: den 2 december 2015 15:41
To: Developer support list for Wireshark; 
alexis.lagou...@gmail.com<mailto:alexis.lagou...@gmail.com>
Subject: Re: [Wireshark-dev] Wireshark Performance

Hi,
Running valgrind on my standard pcap we have gone from
==36946== Callgrind, a call-graph generating cache profiler
==36946== Copyright (C) 2002-2013, and GNU GPL'd, by Josef Weidendorfer et al.
==36946== Using Valgrind-3.10.0.SVN and LibVEX; rerun with -h for copyright info
==36946== Command: /home/ericsson/wireshark/.libs/lt-tshark -Y frame -nr 
/home/ericsson/etxrab/TCT_SIP_traffic.pcapng
==36946==
==36946== For interactive control, run 'callgrind_control -h'.
==36946==
==36946== Events: Ir
==36946== Collected : 18211043816
==36946==
==36946== I   refs:  18,211,043,816

to

==4865==
==4865== Events: Ir
==4865== Collected : 1595333469530
==4865==
==4865== I   refs:  1,595,333,469,530

The big difference seems to be

Latest  June
87.95  37.92 6 076 548  g_hastable_lookup  5.56 2.98 6 515 523

Looking deeper
49.43 25 142 686 213 conversation_match_exact 0.32 576 548

decode_udp_ports seems much more expensive

Regards
Anders


From: 
wireshark-dev-boun...@wireshark.org<mailto:wireshark-dev-boun...@wireshark.org> 
[mailto:wireshark-dev-boun...@wireshark.org] On Behalf Of POZUELO Gloria 
(BCS/PSD)
Sent: den 2 december 2015 14:01
To: Developer support list for Wireshark; 
alexis.lagou...@gmail.com<mailto:alexis.lagou...@gmail.com>
Subject: Re: [Wireshark-dev] Wireshark Performance

I’ve been testing the performance a little more and it seems that the loading 
time has increased not only for GTP protocol. I have sniffed a pcap composed by 
22844 packets and if you open it up with both versions, v2.0 lasts 0.520s and 
v2.1 lasts 1.433s. But as you saw before for GTP protocol is even worse, I’ll 
try to get a pcap example that I can share.

Regards.

From: 
wireshark-dev-boun...@wireshark.org<mailto:wireshark-dev-boun...@wireshark.org> 
[mailto:wireshark-dev-boun...@wireshark.org] On Behalf Of POZUELO Gloria 
(BCS/PSD)
Sent: Wednesday 2 December 2015 09:13
To: alexis.lagou...@gmail.com<mailto:alexis.lagou...@gmail.com>; Developer 
support list for Wireshark
Subject: Re: [Wireshark-dev] Wireshark Performance

I can’t share this one, because it has user data and it’s confidential, but we 
are going to generate another one that can be share. We are using GTP protocol, 
if that gives you a clue.

From: 
wireshark-dev-boun...@wireshark.org<mailto:wireshark-dev-boun...@wireshark.org> 
[mailto:wireshark-dev-boun...@wireshark.org] On Behalf Of Alexis La Goutte
Sent: Wednesday 2 December 2015 09:08
To: Developer support list for Wireshark
Subject: Re: [Wireshark-dev] Wireshark Performance

You can directly add the text output of load time...
It is possible to share your pcap ?

On Wed, Dec 2, 2015 at 9:04 AM, POZUELO Gloria (BCS/PSD) 
mailto:gloria.pozu...@bics.com>> wrote:
I attach the screen captures better.

From: 
wireshark-dev-boun...@wireshark.org<mailto:wireshark-dev-boun...@wireshark.org> 
[mailto:wireshark-dev-boun...@wireshark.org<mailto:wireshark-dev-boun...@wireshark.org>]
 On Behalf Of POZUELO Gloria (BCS/PSD)
Sent: Wednesday 2 December 2015 08:53
To: Developer support list for Wireshark
Subject: [Wireshark-dev] Wireshark Performance

Hello,
Here is the loading time difference between the v2.0 and the last automated 
build for win64 
Wireshark-win64-2.1.0-875-g9779ae3.exe<https://www.wireshark.org/download/automated/win64/Wireshark-win64-2.1.0-875-g9779ae3.exe>
[Imágenes integradas 2][Imágenes integradas 1]
Regards.



 DISCLAIMER
http://www.bics.com/maildisclaimer/

___
Sent via:Wireshark-dev mailing list 
mailto:wireshark-dev@wireshark.org>>
Archives:https:

Re: [Wireshark-dev] Wireshark Performance

[Anders Broman]

Hi,
I’m betting on this change ☺
https://code.wireshark.org/review/gitweb?p=wireshark.git;a=commitdiff;h=9e54fcee5224aef800155514cac5e40d9e38a23e

From: wireshark-dev-boun...@wireshark.org 
[mailto:wireshark-dev-boun...@wireshark.org] On Behalf Of Pascal Quantin
Sent: den 2 december 2015 16:26
To: Developer support list for Wireshark
Subject: Re: [Wireshark-dev] Wireshark Performance



2015-12-02 16:12 GMT+01:00 POZUELO Gloria (BCS/PSD) 
mailto:gloria.pozu...@bics.com>>:
Where can I find that option?

On Windows, Ctrl + Shift + E, or in the menu Analyze -> Enabled protocols. 
Unselect stun_udp.

From: 
wireshark-dev-boun...@wireshark.org<mailto:wireshark-dev-boun...@wireshark.org> 
[mailto:wireshark-dev-boun...@wireshark.org<mailto:wireshark-dev-boun...@wireshark.org>]
 On Behalf Of Anders Broman
Sent: Wednesday 2 December 2015 16:08

To: Developer support list for Wireshark
Subject: Re: [Wireshark-dev] Wireshark Performance

Hi,
It’s probably deeper down, dissect_stun_heur has gone from 3.51 to 14.06.
@ Gloria can you try to turn the stun heuristic off to see if it makes a 
difference?
Regards
Anders

From: 
wireshark-dev-boun...@wireshark.org<mailto:wireshark-dev-boun...@wireshark.org> 
[mailto:wireshark-dev-boun...@wireshark.org] On Behalf Of Evan Huus
Sent: den 2 december 2015 16:02
To: Developer support list for Wireshark
Subject: Re: [Wireshark-dev] Wireshark Performance

The only recent change to conversation_match_exact was the conversion from 
address macros to functions, but in all cases the macros were just pointing to 
the functions anyways so I can't imagine that would have a huge effect on 
performance?

On Wed, Dec 2, 2015 at 9:45 AM, Anders Broman 
mailto:anders.bro...@ericsson.com>> wrote:


From: 
wireshark-dev-boun...@wireshark.org<mailto:wireshark-dev-boun...@wireshark.org> 
[mailto:wireshark-dev-boun...@wireshark.org<mailto:wireshark-dev-boun...@wireshark.org>]
 On Behalf Of Anders Broman
Sent: den 2 december 2015 15:41
To: Developer support list for Wireshark; 
alexis.lagou...@gmail.com<mailto:alexis.lagou...@gmail.com>
Subject: Re: [Wireshark-dev] Wireshark Performance

Hi,
Running valgrind on my standard pcap we have gone from
==36946== Callgrind, a call-graph generating cache profiler
==36946== Copyright (C) 2002-2013, and GNU GPL'd, by Josef Weidendorfer et al.
==36946== Using Valgrind-3.10.0.SVN and LibVEX; rerun with -h for copyright info
==36946== Command: /home/ericsson/wireshark/.libs/lt-tshark -Y frame -nr 
/home/ericsson/etxrab/TCT_SIP_traffic.pcapng
==36946==
==36946== For interactive control, run 'callgrind_control -h'.
==36946==
==36946== Events: Ir
==36946== Collected : 18211043816
==36946==
==36946== I   refs:  18,211,043,816

to

==4865==
==4865== Events: Ir
==4865== Collected : 1595333469530
==4865==
==4865== I   refs:  1,595,333,469,530

The big difference seems to be

Latest  June
87.95  37.92 6 076 548  g_hastable_lookup  5.56 2.98 6 515 523

Looking deeper
49.43 25 142 686 213 conversation_match_exact 0.32 576 548

decode_udp_ports seems much more expensive

Regards
Anders


From: 
wireshark-dev-boun...@wireshark.org<mailto:wireshark-dev-boun...@wireshark.org> 
[mailto:wireshark-dev-boun...@wireshark.org] On Behalf Of POZUELO Gloria 
(BCS/PSD)
Sent: den 2 december 2015 14:01
To: Developer support list for Wireshark; 
alexis.lagou...@gmail.com<mailto:alexis.lagou...@gmail.com>
Subject: Re: [Wireshark-dev] Wireshark Performance

I’ve been testing the performance a little more and it seems that the loading 
time has increased not only for GTP protocol. I have sniffed a pcap composed by 
22844 packets and if you open it up with both versions, v2.0 lasts 0.520s and 
v2.1 lasts 1.433s. But as you saw before for GTP protocol is even worse, I’ll 
try to get a pcap example that I can share.

Regards.

From: 
wireshark-dev-boun...@wireshark.org<mailto:wireshark-dev-boun...@wireshark.org> 
[mailto:wireshark-dev-boun...@wireshark.org] On Behalf Of POZUELO Gloria 
(BCS/PSD)
Sent: Wednesday 2 December 2015 09:13
To: alexis.lagou...@gmail.com<mailto:alexis.lagou...@gmail.com>; Developer 
support list for Wireshark
Subject: Re: [Wireshark-dev] Wireshark Performance

I can’t share this one, because it has user data and it’s confidential, but we 
are going to generate another one that can be share. We are using GTP protocol, 
if that gives you a clue.

From: 
wireshark-dev-boun...@wireshark.org<mailto:wireshark-dev-boun...@wireshark.org> 
[mailto:wireshark-dev-boun...@wireshark.org] On Behalf Of Alexis La Goutte
Sent: Wednesday 2 December 2015 09:08
To: Developer support list for Wireshark
Subject: Re: [Wireshark-dev] Wireshark Performance

You can directly add the text output of load time...
It is possible to share your pcap ?

On Wed, Dec 2, 2015 at 9:04 AM, POZUELO Gloria (BCS/PSD) 
mailto:gloria.pozu.

Re: [Wireshark-dev] UI Proposal for better Analysis for Android devices

[Anders Broman]

From: wireshark-dev-boun...@wireshark.org 
[mailto:wireshark-dev-boun...@wireshark.org] On Behalf Of VIKRAM VENKATESH HEGDE
Sent: den 29 december 2015 06:57
To: wireshark-dev@wireshark.org
Subject: [Wireshark-dev] UI Proposal for better Analysis for Android devices


Dear All,



Its my pleasure to contribute to Wireshark Open Source community. Off late our 
team is contributing to Zigbee cluster dissectors.

We have a UI feature proposal to contribute to open source which will result in 
improved and better analysis of issues with respect to android devices also 
providing user with a good use experience. Below are the details of the 
proposed solution, also attached are the screenshots of the idea in which one 
reflects the existing flow graph available in Wireshark, and the other 
screenshot represents the change we are proposing to enhance the UI and 
separate packet  and system logs and show the system logs in separate panel:



Title


UI Feature in Wireshark for better analysis


Abstract


The proposed solution addresses enhancement of UI for GTK, in which unlike the 
existing Wireshark, the logs which are generated from the android device 
connected via usb to system and the packet data are separated out to show it in 
different panes. Thus providing an additional functionality of viewing the log 
data and packet data separately and also having a time synchronization 
functionality to map the packet data with the log entry and vice-versa. This 
will be useful for user to analyze the particular scenario in more depth as the 
user will be able to analyze whether the issue lies in network based on the 
packets or whether the issue lies in the device software implementation based 
on the system logs.


Background (if necessary)


The code contribution is an enhancement of existing Wireshark to provide user 
with more functionality and better analysis of the issues. Also enhancing the 
user experience by showing the log data and packet data together and mapping 
functionality based on the time.








Detailed Description


Added the below functionalities:

v  Modified the UI to show device system logs and packet logs separately.

v  Time Synchronization and mapping between packet data and system logs so that 
user can get the issues addressed more clearly.

The system logs that are captured using the existing android dump are shown in 
the form of packets along with the other network traffic in the Wireshark main 
packet window.  This implementation adds large number of additional packets in 
the Wireshark packet window as every log line is shown as a packet. To reduce 
this overhead we are segregating the log viewer and the network traffic by 
adding additional UI component Logviewer. The log viewer will display the 
system logs as simple text data . The user can map between the log viewer 
window and main packet pane by selecting a packet in the Wireshark main packet 
panel or selecting a line in the log window by which the other window 
corresponding entry will be highlighted.  Our implementation requires a few 
modification in the existing code of the Wireshark so as to fit our new 
component log viewer as a part of Wireshark. To feed the data in the logviwer 
we are adding  an additional interface in the androiddump which will be listed 
along with the other interfaces in the Wireshark interface list. The capture 
filter option  in the interface can be used to specify the logtags.  We are 
also providing the facility of storing the logdata  for the offline use.

The logviewer functionality is similar to the flow graph that assist user  in 
seeing whether there are any issues on the network such as dropped frames, 
timeouts or dropped connections. Flow graph  also provide the time mapping 
functionality similar to the logviewer window.


If the feature looks promising then we would like to open source this. Please 
let me know if the feature looks interesting. If so would send more details and 
the changes involved in architecture and also some addons which we would be 
contributing along with the main UI enhancement..



Thanks & Regards,

Vikram



Hi,

Yes it looks interesting, the best would be to upload the code changes to 
gerrit so we can have a look at it. Note that GTK is being deprecated so

The GUI part has to be ported to Qt too otherwise the functionality may be lost 
when GTK is removed. But in my opinion we could integrate the GTK version

First and worry about the GUI part later. If it’s possible to add the feature 
as a series of smaller patches that would make the review easier rather than

A humongous patch adding all at once.

Best regards

Anders
___
Sent via:Wireshark-dev mailing list 
Archives:https://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] UI Proposal for better Analysis for Android devices

[Anders Broman]

Den 30 dec 2015 17:01 skrev "Graham Bloice" :
>
>
>
> On 30 December 2015 at 10:52, VIKRAM VENKATESH HEGDE 
wrote:
>>
>> Hi,
>>
>>
>>
>> Sure, will submit the feature in patches may be will start doing so by
next week.
>>
>> Thanks for the support.
>>
>>
>>
>> Thanks & Regards,
>>
>> Vikram
>>
>>
>
> FWIW, I have a different opinion than Anders regarding the UI.   Qt "is"
the Wireshark UI toolkit, GTK is legacy, and Qt is better supported on our
target platforms, especially OSX.  I think any new UI development should be
for Qt first, then if developer cycles are available, it can be ported to
GTK.

As I understand it in this case the GTK code exist and the Qt does not. Not
accepting it would slow progress and accepting it might speed up the port
to Qt and sort out any problems or design flaws early. IMHO
Regards
Anders

>
>> --- Original Message ---
>>
>> Sender : Anders Broman
>>
>> Date : Dec 30, 2015 16:59 (GMT+09:00)
>>
>> Title : RE: [Wireshark-dev] UI Proposal for better Analysis for Android
devices
>>
>>
>>
>>
>>
>>
>>
>> From: wireshark-dev-boun...@wireshark.org [mailto:
wireshark-dev-boun...@wireshark.org] On Behalf Of VIKRAM VENKATESH HEGDE
>> Sent: den 29 december 2015 06:57
>> To: wireshark-dev@wireshark.org
>> Subject: [Wireshark-dev] UI Proposal for better Analysis for Android
devices
>>
>>
>>
>> Dear All,
>>
>>
>>
>> Its my pleasure to contribute to Wireshark Open Source community. Off
late our team is contributing to Zigbee cluster dissectors.
>>
>> We have a UI feature proposal to contribute to open source which will
result in improved and better analysis of issues with respect to android
devices also providing user with a good use experience. Below are the
details of the proposed solution, also attached are the screenshots of the
idea in which one reflects the existing flow graph available in Wireshark,
and the other screenshot represents the change we are proposing to enhance
the UI and separate packet  and system logs and show the system logs in
separate panel:
>>
>>
>>
>> Title
>>
>> UI Feature in Wireshark for better analysis
>>
>> Abstract
>>
>> The proposed solution addresses enhancement of UI for GTK, in which
unlike the existing Wireshark, the logs which are generated from the
android device connected via usb to system and the packet data are
separated out to show it in different panes. Thus providing an additional
functionality of viewing the log data and packet data separately and also
having a time synchronization functionality to map the packet data with the
log entry and vice-versa. This will be useful for user to analyze the
particular scenario in more depth as the user will be able to analyze
whether the issue lies in network based on the packets or whether the issue
lies in the device software implementation based on the system logs.
>>
>> Background (if necessary)
>>
>> The code contribution is an enhancement of existing Wireshark to provide
user with more functionality and better analysis of the issues. Also
enhancing the user experience by showing the log data and packet data
together and mapping functionality based on the time.
>>
>>
>>
>>
>>
>>
>>
>> Detailed Description
>>
>> Added the below functionalities:
>>
>> v  Modified the UI to show device system logs and packet logs separately.
>>
>> v  Time Synchronization and mapping between packet data and system logs
so that user can get the issues addressed more clearly.
>>
>> The system logs that are captured using the existing android dump are
shown in the form of packets along with the other network traffic in the
Wireshark main packet window.  This implementation adds large number of
additional packets in the Wireshark packet window as every log line is
shown as a packet. To reduce this overhead we are segregating the log
viewer and the network traffic by adding additional UI component Logviewer.
The log viewer will display the system logs as simple text data . The user
can map between the log viewer window and main packet pane by selecting a
packet in the Wireshark main packet panel or selecting a line in the log
window by which the other window corresponding entry will be highlighted.
Our implementation requires a few modification in the existing code of the
Wireshark so as to fit our new component log viewer as a part of Wireshark.
To feed the data in the logviwer we are adding  an additional interface in
the androiddump which will be listed along with the other interfaces in the
Wireshark interface list. The capture filt

Re: [Wireshark-dev] UI Proposal for better Analysis for Android devices

[Anders Broman]

Den 31 dec 2015 14:30 skrev "Graham Bloice" :
>
>
>
> On 31 December 2015 at 11:35, Bálint Réczey 
wrote:
>>
>> 2015-12-31 0:10 GMT+01:00 Anders Broman :
>> >
>> > Den 30 dec 2015 17:01 skrev "Graham Bloice" <
graham.blo...@trihedral.com>:
>> >>
>> >>
>> >>
>> >> On 30 December 2015 at 10:52, VIKRAM VENKATESH HEGDE
>> >>  wrote:
>> >>>
>> >>> Hi,
>> >>>
>> >>>
>> >>>
>> >>> Sure, will submit the feature in patches may be will start doing so
by
>> >>> next week.
>> >>>
>> >>> Thanks for the support.
>> >>>
>> >>>
>> >>>
>> >>> Thanks & Regards,
>> >>>
>> >>> Vikram
>> >>>
>> >>>
>> >>
>> >> FWIW, I have a different opinion than Anders regarding the UI.   Qt
"is"
>> >> the Wireshark UI toolkit, GTK is legacy, and Qt is better supported
on our
>> >> target platforms, especially OSX.  I think any new UI development
should be
>> >> for Qt first, then if developer cycles are available, it can be
ported to
>> >> GTK.
>> >
>> > As I understand it in this case the GTK code exist and the Qt does
not. Not
>> > accepting it would slow progress and accepting it might speed up the
port to
>> > Qt and sort out any problems or design flaws early. IMHO
>> I agree that we should not reject UI patches because they improve the
GTK+
>> implementation only.
>>
>> I would prefer having Wireshark development guided by users' needs and
>> contributions
>> rather than pushing devs' choices very hard [1].
>>
>> Cheers,
>> Balint
>>
>> [1] In Debian we have the social contract clarifying that:
>> ...
>> 4. Our priorities are our users and free software
>> We will be guided by the needs of our users and the free software
>> community. We will place their interests first in our priorities. We
>> will support the needs of our users for operation in many different
>> kinds of computing environments. ...
>> ...
>> (From: https://www.debian.org/social_contract)
>>
>
> I'm not being hard-nosed about this, just trying to be practical.  The
Flows analysis stuff (which looked really interesting to me at SharkFest)
seems to be dead because of licencing issues and nobody seems to be
stepping up to fix that,
>
> In a volunteer project, any changes rely on the goodwill of the
volunteers, both internal and external, and developing code for a UI that
we're stated an intention to drop for all (most, RH\Fedora exceptions??)
platforms in the future and have dropped already for a major platform
(OSX? AFAIK, they don't have a GTK version) is then asking someone else to
step up for the porting effort, possibly reducing their ability to effect
other improvements.
>
> I don't think it's unfriendly or impolite to ask contributors to follow
the aims of the project if possible.
>
> --
> Graham Bloice
>

I basically agree but if the code isn't made public it's not possible to
pick it up should the contributor decide porting to Qt is to hard and if
there's licencing or other problems with the code it might be better to
find that out now rather then after any effort is spent to port to Qt.

I also stated that loosing the functionality will not stop us from
deprecating gtk when the time comes which should be an incentive to do a qt
version for those that want it.

Just my 2 cents.
Anders

>
___
> Sent via:Wireshark-dev mailing list 
> Archives:https://www.wireshark.org/lists/wireshark-dev
> Unsubscribe: https://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://wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] build with vs2015

[Anders Broman]

Den 31 dec 2015 16:06 skrev "Alan Partis" :
>
> I see there were a couple discussions back in August about building
> wireshark using Visual Studio 2015.  At that time, one of the issues that
> was raised had to do with the availability of required libs from Qt (which
> still appears to only have stuff for 2013).
>
> Has there been any change in the status of building wireshark with VS
> 2015?  I get warnings (which are apparently treated as errors by the build
> scripts) when trying to build with VS 2015 on a Windows 10 system.
>
> Is this currently still not possible?
>
>

I got it building at one point without qt, but I haven't tried for a while
so it's possible some new errors have creapt in. What are the
warnings/errors and you are building from top of trunk?
Regards
Anders

___
> Alan Partis
> thundernet development group
>
___
> Sent via:Wireshark-dev mailing list 
> Archives:https://www.wireshark.org/lists/wireshark-dev
> Unsubscribe: https://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://wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] How Wireshark supports monitor mode for WLAN 802.11 adapter in Windows?

[Anders Broman]

-Original Message-
From: wireshark-dev-boun...@wireshark.org 
[mailto:wireshark-dev-boun...@wireshark.org] On Behalf Of Guy Harris
Sent: den 1 januari 2016 21:00
To: Developer support list for Wireshark
Subject: Re: [Wireshark-dev] How Wireshark supports monitor mode for WLAN 
802.11 adapter in Windows?


On Jan 1, 2016, at 8:27 AM, Yang Luo  wrote:

> On Thursday, December 31, 2015, Guy Harris  wrote:
> 
>> What you *should* do is have a pcap_can_set_rfmon_win32() function in 
>> pcap-win32.c, and, at the end of pcap_create_interface() in pcap-win32.c, do
>> 
>> p->can_set_rfmon_op = pcap_can_set_rfmon_win32;
>> 
>> right after setting p->activate_op.
> 
> Yeah, this way is more conformant with the code style.

*And* means the libpcap code in NPcap isn't changed in a way that breaks 
libpcap; the ultimate goal should be to have NPcap source code not include 
libpcap source code, and have its build process separately check out libpcap 
from its repository; I think that's what WinPcap now does.

>> Currently, dumpcap only uses the 
>> pcap_create()/pcap_activate()/pcap_can_set_rfmon() APIs if, when it was 
>> compiled, it was built against a version of libpcap/WinPcap that doesn't 
>> have pcap_open().
>> 
>> WinPcap has pcap_open(), so that means dumpcap *doesn't* use those APIs, 
>> which means that Wireshark on Windows won't use them and won't support 
>> monitor mode.
>> 
>> This means that dumpcap needs to be changed to use those APIs on local 
>> adapters if they're available, regardless of whether pcap_open() is 
>> available, and to use pcap_open() *only* for remote adapters.
> 
> Why not just use those APIs? I think they can totally substitute the 
> pcap_open function?

They can't, yet, as they don't support remote interfaces.

I'm working on new APIs to allow specification of authentication information 
etc., so that pcap_create() and pcap_activate() can work on remote devices, but 
doing it in a general fashion involves a bit more work (the intent is to 
support more than just rpcap - we could, for example, support 
ssh+tcpdump://hostname/device, with the aid of an ssh client library).

>> *If* we're willing to require that the Windows version of Wireshark use only 
>> WinPcap 4.1 and later, or NPcap, that's a straightforward source code 
>> change.  This would mean people who had some reason to, for example, use 
>> WinPcap 3.x - for example, to capture on PPP devices (dial-up, mobile phone 
>> USB adapter, VPN, etc.) on Windows 2000 or the 32-bit versions of Windows XP 
>> and Windows Server 2003 - would be unable to do so.
> 
> Wireshark has shipped the winpcap 4.1.3 version, i don't know but if there 
> are any places that 4.1.3 is inferior than an old version?

I think that 3.x might support capturing on PPP devices (dial-up, VPN, mobile 
phone adapters, etc.) on Windows 2000/XP; I'd have to go through my mail to see 
why that's not supported in 4.x.

As a test I tried to compile Wireshark with HAVE_PCAP_CREATE set using nmake

Linking dumpcap.exe
link @C:\Users\etxrab\AppData\Local\Temp\nmFF17.tmp
dumpcap.obj : error LNK2019: unresolved external symbol pcap_create referenced 
in function open_capture_device
dumpcap.obj : error LNK2019: unresolved external symbol pcap_set_snaplen 
referenced in function open_capture_device
dumpcap.obj : error LNK2019: unresolved external symbol pcap_set_promisc 
referenced in function open_capture_device
dumpcap.obj : error LNK2019: unresolved external symbol pcap_can_set_rfmon 
referenced in function get_if_capabilities
dumpcap.obj : error LNK2019: unresolved external symbol pcap_set_rfmon 
referenced in function open_capture_device
dumpcap.obj : error LNK2019: unresolved external symbol pcap_set_timeout 
referenced in function open_capture_device
dumpcap.obj : error LNK2019: unresolved external symbol pcap_set_buffer_size 
referenced in function open_capture_device
dumpcap.obj : error LNK2019: unresolved external symbol pcap_activate 
referenced in function open_capture_device
dumpcap.obj : error LNK2019: unresolved external symbol pcap_statustostr 
referenced in function open_capture_device
dumpcap.exe : fatal error LNK1120: 9 unresolved externals

Not sure why linking fails :-(

Regards
Anders
___
Sent via:Wireshark-dev mailing list 
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://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://wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] [Wireshark-bugs] [Bug 11980] The filtering speed is impacted by commit b344107d757466e0768a3ef8927852479e926cf6 (Make color filters part of dissection)

[Anders Broman]

Den 10 jan 2016 14:50 skrev :
>
> Comment # 6 on bug 11980 from Peter Wu
>
> You are right, coloring always need to happen (whenever color rules
exist).
> (What about tshark? Colors are normally not shown, but if the two
> frame.coloring_rule fields are shown in the frame tree/columns, should the
> color calculation also be done?)

Do we know if it's a tshark run? If so skip the fields?

>
> For a start, to calculate on the first pass (pinfo->fd->flags.visited ==
0).
> This did not work because the fields from the color filter are not primed
yet.
> Possible fix: always invoke dfilter_prime_proto_tree before
> epan_dissect_run{,_with_taps} (similar to epan_dissect_prime_dfilter).
>
> The next problem is that the applicable color may change during subsequent
> redissections.

Do the opposite, only run on second pass? Is it only needed for visible
frames?

> Possible fix: introduce a new fd->flags.need_colorize which must be set
before
> the initial dissection in GUI and again after changing color rules. Clear
flag
> after after recalculation.
> Alternative fix: introduce a new global flag (eww), that behaves similar
to the
> previous fix, but outside frame_data.
>
> Those fixes will then bring the coloring rules at the same level as
display
> filter rules, allowing filtering as well.
>
> 
> You are receiving this mail because:
> You are watching all bug changes.
>
>
___
> Sent via:Wireshark-bugs mailing list 
> Archives:https://www.wireshark.org/lists/wireshark-bugs
> Unsubscribe: https://wireshark.org/mailman/options/wireshark-bugs
>  mailto:wireshark-bugs-requ...@wireshark.org
?subject=unsubscribe
___
Sent via:Wireshark-dev mailing list 
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

[Wireshark-dev] Reassembly of IP fragments gets confused by multiple packets on different VLANS

[Anders Broman]

Hi,
I just came across a problem where reassembly of IP fragments failed/messed up, 
see https://code.wireshark.org/review/#/c/13452/
The problem was fixed by changing line 2409 in packet-ip.c to
   iph->ip_p ^ iph->ip_id ^ src32 ^ dst32 ^ 
pinfo->vlan_id,
e.g throw vlan_id into the mix as well.

A better fix might be to change the addresses_reassembly_table_functions 
functions ( reassembly.c line 152) to include
VLAN Id as well, Opinions?

I think similar problems may exist in the TCP dissector too e.g TCP messages on 
different VLANS seen as duplicates possibly messing up
TCP analysis and reassembly. Perhaps conversations should take VLAN into 
account too.
Best regards
Anders
___
Sent via:Wireshark-dev mailing list 
Archives:https://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] Reassembly of IP fragments gets confused by multiple packets on different VLANS

[Anders Broman]

Hi,
Trying to summarize…

captured on the "all" interface of a Linux machine acting as a router, or 
merged two captures from networks on different sides of a router.

various sorts of tunneling (or "other sorts of tunneling", if you view VLANs as 
a form of tunneling)

The right generalization might be to have some sort of "network tag" which 
incorporates a network interface ID plus all VLAN tags for the packet ("all 
VLAN tags" to handle QinQ).


So if we go for network tag, or key should that be created by
Outer VLAN tag, Hash of Source MAC, protocol-level, interface index(Pcap-ng)?

Outer VLAN tag should take care of, VLAN and QinQ, right?
Source MAC should take care of, “duplicate caused by mirroring” and alike(?)
Pinfo- curr_layer_num Should take care of tunneling(?)
Interface index should take care of ANY interface traces(?)

What size should the key be, is 32bits enough?

Starting by using outer VLAN ID in the IP dissector should take care of part of 
the problem at least.

Best regards
Anders





From: wireshark-dev-boun...@wireshark.org 
[mailto:wireshark-dev-boun...@wireshark.org] On Behalf Of Michael Mann
Sent: den 20 januari 2016 16:29
To: wireshark-dev@wireshark.org
Subject: Re: [Wireshark-dev] Reassembly of IP fragments gets confused by 
multiple packets on different VLANS

See bug 4561 (https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=4561)



-Original Message-
From: Anders Broman 
mailto:anders.bro...@ericsson.com>>
To: wireshark-dev 
mailto:wireshark-dev@wireshark.org>>
Sent: Wed, Jan 20, 2016 10:13 am
Subject: [Wireshark-dev] Reassembly of IP fragments gets confused by multiple 
packets on different VLANS
Hi,
I just came across a problem where reassembly of IP fragments failed/messed up, 
see https://code.wireshark.org/review/#/c/13452/
The problem was fixed by changing line 2409 in packet-ip.c to
   iph->ip_p ^ iph->ip_id ^ src32 ^ dst32 ^ 
pinfo->vlan_id,
e.g throw vlan_id into the mix as well.

A better fix might be to change the addresses_reassembly_table_functions 
functions ( reassembly.c line 152) to include
VLAN Id as well, Opinions?

I think similar problems may exist in the TCP dissector too e.g TCP messages on 
different VLANS seen as duplicates possibly messing up
TCP analysis and reassembly. Perhaps conversations should take VLAN into 
account too.
Best regards
Anders
___
Sent via:Wireshark-dev mailing list <wireshark-dev@wireshark.org<mailto:wireshark-dev@wireshark.org>>
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribemailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe%3c/a>
 href='mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe'>mailto:wireshark-dev@wireshark.org'>
___
Sent via:Wireshark-dev mailing list 
Archives:https://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 fails to start with wpcap.dll built by Visual Studio 2010

[Anders Broman]

Hi,
Why not build with VS 2013? It seems to be supported in master now. I presume 
we would like updates pushed there.
Regards
Anders

From: wireshark-dev-boun...@wireshark.org 
[mailto:wireshark-dev-boun...@wireshark.org] On Behalf Of Pascal Quantin
Sent: den 3 februari 2016 17:27
To: Developer support list for Wireshark
Subject: Re: [Wireshark-dev] Wireshark fails to start with wpcap.dll built by 
Visual Studio 2010



2016-02-03 16:16 GMT+01:00 Yang Luo 
mailto:hslu...@gmail.com>>:
Hi list,

After several months, I retried updating wpcap project from VS 2005 to VS 2010) 
and encountered the same issue, under Wireshark 2.0.1 x64, Win10 x64.

The Wireshark UI said "Child dumpcap process died: Access violation". I don't 
know what this means, because I have used Administrator privilege to launch 
Wireshark.

I have just attached the x64 version wpcap.dll in this mail, you can just 
substitute it with the original WinPcap/Npcap version in C:\Windows\System32. 
Then launch Wireshark and you will see the crash. Hope that any one can see 
what's wrong with it here.

Hi Yang,
I just gave a test to you dll (have replaced the existing version in 
C:\windows\System32\ and C:\windows\SysWOW64\ and did not face a crash when 
running it on Windows 7 x64:

Version 2.0.2 (v2.0.2rc0-71-g1e10145 from master-2.0)



Copyright 1998-2016 Gerald Combs 
mailto:ger...@wireshark.org>> and contributors.

License GPLv2+: GNU GPL version 2 or later 


This is free software; see the source for copying conditions. There is NO

warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.



Compiled (64-bit) with Qt 5.5.0, with WinPcap (4_1_3), with libz 1.2.8, with

GLib 2.42.0, with SMI 0.4.8, with c-ares 1.9.1, with Lua 5.2, with GnuTLS

3.2.15, with Gcrypt 1.6.2, with MIT Kerberos, with GeoIP, with QtMultimedia,

with AirPcap.



Running on 64-bit Windows 7 Service Pack 1, build 7601, with locale C, with

Npcap version 0.05, based on WinPcap version 4.1.3 (packet.dll version

4.1.0.2980), based on libpcap version 1.0 branch 1_0_rel0b (20091008), with

GnuTLS 3.2.15, with Gcrypt 1.6.2, with AirPcap 4.1.0 build 1622.

Intel(R) Core(TM) i7-4700MQ CPU @ 2.40GHz (with SSE4.2), with 7879MB of physical

memory.





Built using Microsoft Visual C++ 12.0 build 40629



Wireshark is Open Source Software released under the GNU General Public License.



Check the man page and http://www.wireshark.org for more information.

Does it require a reboot of the system?
Pascal.

Cheers,
Yang



On Wed, Aug 5, 2015 at 1:27 PM, Yang Luo 
mailto:hslu...@gmail.com>> wrote:
Hi list,

The original WinPcap DLL, wpcap.dll is built by VS 2005, I have updated it to 
VS 2010 using VS automatic conversion wizard without changing one line of code. 
But when I launched Wireshark on Win8.1 x64, I encountered an app crash error:

-
Problem signature:
  Problem Event Name: APPCRASH
  Application Name: dumpcap.exe
  Application Version: 1.99.9.58
  Application Timestamp: 55be9e4d
  Fault Module Name: wpcap.dll
  Fault Module Version: 0.3.0.727
  Fault Module Timestamp: 55c19749
  Exception Code: c005
  Exception Offset: 0001fbca
  OS Version: 6.3.9600.2.0.0.256.4
  Locale ID: 1033
  Additional Information 1: 12c1
  Additional Information 2: 12c1dabe3a9c9d7be788f03210b25196
  Additional Information 3: b207
  Additional Information 4: b207cb8de8ff9d2641379d976acebfca

Read our privacy statement online:
  http://go.microsoft.com/fwlink/?linkid=280262

If the online privacy statement is not available, please read our privacy 
statement offline:
  C:\Windows\system32\en-US\erofflps.txt
-

I have updated Packet.dll from VS 2005 to VS 2010 without problem. (If I use VS 
2005 version wpcap.dll and VS 2010 version Packet.dll, it works fine) So it 
can't be lacking C run-time issue. I don't know what's wrong with it?


Cheers,
Yang


___
Sent via:Wireshark-dev mailing list 
mailto:wireshark-dev@wireshark.org>>
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://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://wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] Reassembly of IP fragments gets confused by multiple packets on different VLANS

[Anders Broman]

-Original Message-
From: wireshark-dev-boun...@wireshark.org 
[mailto:wireshark-dev-boun...@wireshark.org] On Behalf Of Guy Harris
Sent: den 6 februari 2016 20:10
To: Developer support list for Wireshark
Subject: Re: [Wireshark-dev] Reassembly of IP fragments gets confused by 
multiple packets on different VLANS

On Jan 20, 2016, at 8:43 AM, Anders Broman  wrote:

> Trying to summarize…
>  
> captured on the "all" interface of a Linux machine acting as a router, or 
> merged two captures from networks on different sides of a router.
>  
> various sorts of tunneling

Including, for example, MPLS pseudo-wires.

> (or "other sorts of tunneling", if you view VLANs as a form of 
> tunneling)

That might be the best way to think about VLANs - treat them the same way 
various tunnels, pseudo-wires, etc. are treated.

On the other hand, as a comment:

https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=4561#c5

in the bug you're quoting says:

For VLAN I know cases where UL traffic and DL traffic belong to 
different VLAN, still to the same flow. Thus a differentiation according to 
VLAN id must be configurable.

so VLANs shouldn't always be treated as tunnels.

I don't know whether that's an issue for to any other form of pseudo-wire or 
tunnel - or even for physical networks, as identified by interface IDs; I could 
imagine a case where a machine has multiple physical interfaces on the same 
network and different fragments of an IP datagram, or different packets in a 
given TCP connection, or... might travel on different interfaces.

So is this really just a question of

1) "wires", whether physical or virtual (a VLAN being a "virtual wire") 
or pseudo-wire or...

and

2) whether the machine on which the capture is being done routes 
traffic between "wires" or not?

If the machine has multiple "wires" (or radio channels) and *is* routing 
between them, a capture that sees traffic from multiple "wires" might see 
multiple copies of network-layer packets on different "wires".

If it's not routing between them, and is, for example, using different "wires" 
for an uplink and a downlink, or has bonded multiple "wires" together and is 
sending traffic to another machine over multiple different "wires", then 
fragments from a given fragmented IP datagram, or packets on a given TCP 
connection, or... might appear on different "wires".

In the first case, you want to distinguish between "wires" when doing 
reassembly/TCP analysis and desegmentation/etc..

In the second case, you *don't* want to do that.

Would that be sufficient to handle the two cases?  Or are there cases where the 
machine might be routing between some sets of "wires" and using other sets of 
"wires" as parallel pipes to and from a given destination host, so that whether 
the "wire" should be taken into account depends on the "wire"?

> The right generalization might be to have some sort of "network tag" which 
> incorporates a network interface ID plus all VLAN tags for the packet ("all 
> VLAN tags" to handle QinQ).
>  
>  
> So if we go for network tag, or key should that be created by Outer 
> VLAN tag, Hash of Source MAC, protocol-level, interface index(Pcap-ng)?
>  
> Outer VLAN tag should take care of, VLAN and QinQ, right?
> Source MAC should take care of, “duplicate caused by mirroring” and 
> alike(?)
> Pinfo- curr_layer_num Should take care of tunneling(?) Interface index 
> should take care of ANY interface traces(?)
>  
> What size should the key be, is 32bits enough?

If we have a notion of "wire", perhaps we could assign sequential internal 
numbers to "wires" - just as we do for conversations - and use the internal 
"wire" number.

We could also use that for filtering, e.g. "show me everything on this "wire"".

(And maybe we could have a sidebar in Wireshark, showing all the "wires", 
conversations, etc. we've seen, and let you just click on one to show only the 
packets on that "wire"/in that conversation/etc..)


It seems like there might not be a "solve all" solution to the cases listed, it 
also seems to me like there is a need for several flavors of "conversation"
Such as the 5 tuple we have today for stuff like "decode as" and possibly other 
protocol data stored by the protocols running on the transport protocol and
A configurable(?) "conversation" type taking "wire" into consideration used for 
reassembly TCP analysis response times etc.
Possibly the "wire lookup" could list all "wires" belonging to the same 5 tuple 
and data could be obtained using the wire

Re: [Wireshark-dev] Reassembly of IP fragments gets confused by multiple packets on different VLANS

[Anders Broman]

Den 8 feb 2016 18:04 skrev "Guy Harris" :
>
> On Feb 8, 2016, at 8:51 AM, Anders Broman 
wrote:
>
> > It seems like there might not be a "solve all" solution to the cases
listed, it also seems to me like there is a need for several flavors of
"conversation"
> > Such as the 5 tuple we have today for stuff like "decode as" and
possibly other protocol data stored by the protocols running on the
transport protocol and
> > A configurable(?) "conversation" type taking "wire" into consideration
used for reassembly TCP analysis response times etc.
>
>
> We *do* want a "Decode As" that applies to a conversation (i.e., which
doesn't change the dissector table, it just changes the per-conversation
dissector setting), but we don't have it yet, as far as I know, so
presumably you're referring to the way that feature would work.
>
> Are you saying here that if the problem is that we're seeing both sides
of routing, so that you have two (or more) copies of the same packet in the
capture, you would still want, for example, both instances of a given TCP
connection dissected as the selected protocol, but would want TCP
reassembly taking place separately on both instances?
>
Yes, when conversation is set up from say the SDP dissector for the
upcoming rtp flow we will not know on which wire it will appear.

___
> Sent via:Wireshark-dev mailing list 
> Archives:https://www.wireshark.org/lists/wireshark-dev
> Unsubscribe: https://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://wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] Reassembly of IP fragments gets confused by multiple packets on different VLANS

[Anders Broman]

Den 8 feb 2016 18:28 skrev "Guy Harris" :
>
> On Feb 8, 2016, at 9:23 AM, Anders Broman  wrote:
>
> > Yes, when conversation is set up from say the SDP dissector for the
upcoming rtp flow we will not know on which wire it will appear.
>
> So perhaps the reassembly code should take into account the conversation
ID (with conversations not taking the wire ID into account) *and* possibly
also the wire ID, with a preference to indicate whether to include the wire
ID or not (set the preference when there's routing between wires going on,
don't set it if, say, wires are being bundled together for greater
bandwidth, or different VLANs are being used for upstream and downstream
traffic, or...).
>
Yes or possibly ignore the higher layer and just say someting like
[duplicate on transport ] as seeing multiple application messages my
confuse people. That should perhaps be a preference too.
___
> Sent via:Wireshark-dev mailing list 
> Archives:https://www.wireshark.org/lists/wireshark-dev
> Unsubscribe: https://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://wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

[Wireshark-dev] GTK GUI: filter shortcuts multiplied when changing profiles.

[Anders Broman]

Hi,
A user of our internal Wireshark version reported to me that if you have 
profiles with filter shortcuts switching between profiles
Will add all the filter shortcuts to the menu bar adding the new shortcuts to 
the end leaving you with a long list of filters that may not fit the window.
I don't have the time to look into it in the next few days so if someone else 
can that would be great.

Best regards
Anders
___
Sent via:Wireshark-dev mailing list 
Archives:https://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] Testing the new created .dll

[Anders Broman]

Hi,
So you compiled with 2.1.0(Master I presume) and tried it with 2.0.1 the 
current released version, that is not guaranteed to work as
We do not guarantee API and ABI compatibility between versions. Try to build 
with 2.0.1 and then copy the .dll
Best regards
Anders

From: wireshark-dev-boun...@wireshark.org 
[mailto:wireshark-dev-boun...@wireshark.org] On Behalf Of FIXED-TERM Scholz 
Tobias (DC-IA/EAI)
Sent: den 16 februari 2016 09:24
To: Developer support list for Wireshark
Subject: [Wireshark-dev] Testing the new created .dll

Hello,

since I have compiled my new functions successfully for 2.1.0, I wanted to test 
it. On my computer it completely works for win64 and for win32 Wireshark 2.1.0 
builds. Now I wanted to test the new Plug-In on the current available user 
version of Wireshark (2.0.1) on a different computer.

Therefore I copied the new created .dll-file into the installed user versions 
path "wireshark\plugins\...". (Do I have to copy another file into the user 
version or is it still just the new created .dll-file for Wireshark 2.x?)

It appears that I'm now getting an Error, which crashes the program, while 
starting Wireshark 2.0.1.
The Error:  "Err Field 'Value' (pn_io.profidrive.parameter.value_float) is 
a FT_ABSOLUTE_TIME but is being displayed as BASE_NONE instead of as a time"

First off all, I even didn't change anything for this variable. Second point 
is, that in my source code for 2.1.0 the type of this variable is defined as 
FT_FLOAT with BASE_NONE. So why is he telling me that I am using 
FT_ABSOLUTE_TIME? To be sure about the problem, I made a comparison between the 
original source codes of 2.0.1 and 2.1.0 and even there the type is FT_FLOAT 
with BASE_NONE. Furthermore I searched in the complete Wireshark source code 
files for this variable and the only file I found, was the file I am editing 
and where the type is correctly defined. At least I also cleaned the solution 
and built it again, but still the same problem appears. So I am a little bit 
confused, where he gets the value FT_ABSOLUTE_TIME for this variable?

Can someone help me what's going on there?

Thanks in advance!

T. Scholz

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

[Wireshark-dev] androiddump no longer built with nmake -> packaging fails

[Anders Broman]

Hi,
The files in the extcap folder are no longer built with nmake...
Regards
Anders
___
Sent via:Wireshark-dev mailing list 
Archives:https://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] androiddump no longer built with nmake -> packaging fails

[Anders Broman]

Thanks a lot Pascal.
Regards
Anders

From: wireshark-dev-boun...@wireshark.org 
[mailto:wireshark-dev-boun...@wireshark.org] On Behalf Of Pascal Quantin
Sent: den 17 februari 2016 23:21
To: Developer support list for Wireshark
Subject: Re: [Wireshark-dev] androiddump no longer built with nmake -> 
packaging fails

Hi Anders,

2016-02-17 16:32 GMT+01:00 Anders Broman 
mailto:anders.bro...@ericsson.com>>:
Hi,
The files in the extcap folder are no longer built with nmake...

Should be fixed with https://code.wireshark.org/review/#/c/13986/1
Cheers,
Pascal.
___
Sent via:Wireshark-dev mailing list 
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

[Wireshark-dev] Build failing on SLES 11.2

[Anders Broman]

Hi,
A collegue is trying to build on SLES 11.2 but the build is failing with
eth@linux-q645:~/plugin_dev/
 > make
/usr/bin/perl ./make-version.pl .
Version configuration file version.conf not found.  Using defaults.
version.h has been updated.
make  all-recursive
make[1]: Entering directory `/home/eth/plugin_dev/ '
Making all in tools
make[2]: Entering directory `/home/eth/plugin_dev/ /tools'
Making all in lemon
make[3]: Entering directory `/home/eth/plugin_dev/ tools/lemon'
  CC lemon-lemon.o
gcc: unrecognized option '-Qunused-arguments'


this is on a trunk version from sometime last week. Ideas?

Best regards
Anders
___
Sent via:Wireshark-dev mailing list 
Archives:https://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] master e282c19: autotools: Fix multiple repetitions of -L build flags

[Anders Broman]

From: wireshark-dev-boun...@wireshark.org 
[mailto:wireshark-dev-boun...@wireshark.org] On Behalf Of Jeff Morriss
Sent: den 23 februari 2016 15:07
To: Developer support list for Wireshark
Subject: Re: [Wireshark-dev] [Wireshark-commits] master e282c19: autotools: Fix 
multiple repetitions of -L build flags



On Mon, Feb 22, 2016 at 9:56 AM, Jeff Morriss 
mailto:jeff.morriss...@gmail.com>> wrote:

On Mon, Feb 22, 2016 at 9:48 AM, João Valverde 
mailto:joao.valve...@tecnico.ulisboa.pt>> 
wrote:


On 22-02-2016 14:28, Jeff Morriss wrote:

On Sun, Feb 21, 2016 at 2:45 AM, Wireshark code review
mailto:code-review-do-not-re...@wireshark.org>
>>
 wrote:

e282c19 by João Valverde 
(joao.valve...@tecnico.ulisboa.pt

>):

 autotools: Fix multiple repetitions of -L build flags

 Before:

   WS_LDFLAGS=' -Wl,--as-needed -L/usr/local/lib
-L/usr/local/lib -L/usr/local/lib -L/usr/local/lib -L/usr/local/lib'

 After:

   WS_LDFLAGS=' -Wl,--as-needed -L/usr/local/lib'

 Bumps autoconf required version to 2.64.


FWIW this means Wireshark master (to become 2.2) will no longer work on
RHEL/CentOS 6 (which has autoconf 2.63).  I don't seem to have an easy
way to check SLES.

(Just for the record) Anders' config.log shows that his SLES 11.2 system is 
also running autoconf 2.63.

I noted that too, is it possible to easily update autoconf? (RPM?) Or would 
that drag in all kinds of dependencies? Long term I’d like to push
my users to SLES 12.1 anyway.
Regards
Anders
___
Sent via:Wireshark-dev mailing list 
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

[Wireshark-dev] Problems with NSIS packaging and Copyright symbol?

[Anders Broman]

Hi,
A collegue of mine get
Processing config: C:\Program Files (x86)\NSIS\nsisconf.nsh
Processing script file: "uninstall.nsi" (ACP)
Bad text encoding: common.nsh:34
!include: error in script: "common.nsh" on line 34
Error in script "uninstall.nsi" on line 8 -- aborting creation process
NMAKE : fatal error U1077: '"C:\Program Files (x86)\NSIS\makensis.exe"' : 
return code '0x1'
Stop.
NMAKE : fatal error U1077: '"C:\Program Files (x86)\Microsoft Visual Studio 
10.0\VC\BIN\nmake.exe"' : return code '0x2'
Stop.
When trying to make a package, on the line before it says "; NSIS handles the 
copyright symbol correctly using CP-1252 but not UTF-8."
So I guess this is related? Deleting the line packaging works with a warning 
"Generating version information for language "1033-English"
Without standard key "LegalCopyright" so I assume this problem arises with 
CP-1033? Any ideas on how to fix?
Regards
Anders
___
Sent via:Wireshark-dev mailing list 
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

[Wireshark-dev] Build error with Visual studio 2015 and nmake

[Anders Broman]

Hi,
I just tried to compile with Visual studio 2015 and Qt 5.6 and got the 
following error:

wireshark_dialog.cpp
.\wireshark_application.cpp(547): error C2664: 'void *ws_load_library(gchar *)':
cannot convert argument 1 from 'const char [13]' to 'gchar *'
.\wireshark_application.cpp(547): note: Conversion from string literal loses con
st qualifier (see /Zc:strictStrings)
wlan_statistics_dialog.cpp

Regards
Anders



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

[Wireshark-dev] Warn Dissector bug, protocol RADIUS

[Anders Broman]

Hi,
After the recent radius changes I get these console printouts for radius 
packets

C:\Development\wireshark>17:30:27  Warn Dissector bug, protocol RADIUS,
in packet 65: proto.c:2494: failed assertion "(guint)hfindex < gpa_hfinfo.len" (
Unregistered hf!)
Regards
Anders
___
Sent via:Wireshark-dev mailing list 
Archives:https://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] Current master not compiling

[Anders Broman]

Hi,
I'm also facing issues on MSVC 2015 and Cmake

 C:\Development\ewireshark\trunk\epan\dfilter\dfilter.c(214): error 
C2065: 'yyscan_t': undeclared identifier 
[C:\Development\wsbuild64\epan\dfilter\dfilter.vcxproj]
 C:\Development\ewireshark\trunk\epan\dfilter\dfilter.c(214): error 
C2146: syntax error: missing ';' before identifier 'scanner' 
[C:\Development\wsbuild64\epan\dfilter\dfilter.vcxproj]
 C:\Development\ewireshark\trunk\epan\dfilter\dfilter.c(214): error 
C2065: 'scanner': undeclared identifier 
[C:\Development\wsbuild64\epan\dfilter\dfilter.vcxproj]
 C:\Development\ewireshark\trunk\epan\dfilter\dfilter.c(215): error 
C2065: 'YY_BUFFER_STATE': undeclared identifier 
[C:\Development\wsbuild64\epan\dfilter\dfilter.vcxproj]
 C:\Development\ewireshark\trunk\epan\dfilter\dfilter.c(215): error 
C2146: syntax error: missing ';' before identifier 'in_buffer' 
[C:\Development\wsbuild64\epan\dfilter\dfilter.vcxproj]
 C:\Development\ewireshark\trunk\epan\dfilter\dfilter.c(215): error 
C2065: 'in_buffer': undeclared identifier 
[C:\Development\wsbuild64\epan\dfilter\dfilter.vcxproj]
 C:\Development\ewireshark\trunk\epan\dfilter\dfilter.c(235): error 
C2065: 'scanner': undeclared identifier 
[C:\Development\wsbuild64\epan\dfilter\dfilter.vcxproj]
 C:\Development\ewireshark\trunk\epan\dfilter\dfilter.c(243): error 
C2065: 'in_buffer': undeclared identifier 
[C:\Development\wsbuild64\epan\dfilter\dfilter.vcxproj]
 C:\Development\ewireshark\trunk\epan\dfilter\dfilter.c(243): error 
C2065: 'scanner': undeclared identifier 
[C:\Development\wsbuild64\epan\dfilter\dfilter.vcxproj]
 C:\Development\ewireshark\trunk\epan\dfilter\dfilter.c(250): error 
C2065: 'scanner': undeclared identifier 
[C:\Development\wsbuild64\epan\dfilter\dfilter.vcxproj]
 C:\Development\ewireshark\trunk\epan\dfilter\dfilter.c(256): error 
C2065: 'scanner': undeclared identifier 
[C:\Development\wsbuild64\epan\dfilter\dfilter.vcxproj]
 C:\Development\ewireshark\trunk\epan\dfilter\dfilter.c(319): error 
C2065: 'in_buffer': undeclared identifier 
[C:\Development\wsbuild64\epan\dfilter\dfilter.vcxproj]
 C:\Development\ewireshark\trunk\epan\dfilter\dfilter.c(319): error 
C2065: 'scanner': undeclared identifier 
[C:\Development\wsbuild64\epan\dfilter\dfilter.vcxproj]
 C:\Development\ewireshark\trunk\epan\dfilter\dfilter.c(320): error 
C2065: 'scanner': undeclared identifier 
[C:\Development\wsbuild64\epan\dfilter\dfilter.vcxproj]


   "C:\Development\wsbuild64\Wireshark.sln" (default target) (1) ->
   "C:\Development\wsbuild64\ALL_BUILD.vcxproj.metaproj" (default target) 
(2) ->
   "C:\Development\wsbuild64\ui\ui.vcxproj.metaproj" (default target) (113) 
->
   "C:\Development\wsbuild64\ui\ui.vcxproj" (default target) (165) ->
 C:\Development\ewireshark\trunk\ui\text_import.c(909): error C2065: 
'yyscan_t': undeclared identifier [C:\Development\wsbuild64\ui\ui.vcxproj]
 C:\Development\ewireshark\trunk\ui\text_import.c(909): error C2146: 
syntax error: missing ';' before identifier 'scanner' 
[C:\Development\wsbuild64\ui\ui.vcxproj]
 C:\Development\ewireshark\trunk\ui\text_import.c(909): error C2065: 
'scanner': undeclared identifier [C:\Development\wsbuild64\ui\ui.vcxproj]
 C:\Development\ewireshark\trunk\ui\text_import.c(1021): error C2065: 
'scanner': undeclared identifier [C:\Development\wsbuild64\ui\ui.vcxproj]
 C:\Development\ewireshark\trunk\ui\text_import.c(1027): error C2065: 
'scanner': undeclared identifier [C:\Development\wsbuild64\ui\ui.vcxproj]
 C:\Development\ewireshark\trunk\ui\text_import.c(1029): error C2065: 
'scanner': undeclared identifier [C:\Development\wsbuild64\ui\ui.vcxproj]
 C:\Development\ewireshark\trunk\ui\text_import.c(1031): error C2065: 
'scanner': undeclared identifier [C:\Development\wsbuild64\ui\ui.vcxproj]

But dfilter is built with lemon isn't it? Flex is Cygwin 2.5.39-1 and there's 
not any newer version available...
Regards
Anders

-Original Message-
From: wireshark-dev-boun...@wireshark.org 
[mailto:wireshark-dev-boun...@wireshark.org] On Behalf Of Michal Labedzki
Sent: den 4 april 2016 12:37
To: Developer support list for Wireshark
Subject: Re: [Wireshark-dev] Current master not compiling

I have flex 2.5.35 and flex 2.6.0, but still not working for me.

On 4 April 2016 at 12:24, Guy Harris  wrote:
> On Apr 4, 2016, at 1:51 AM, Dario Lombardo  
> wrote:
>
>> But how did the buildbot let it pass?
>
> Because it has a newer version of Flex than you do?
>
> The current master-branch Wireshark, like the current master-branch libpcap, 
> requires at least Flex 2.5.31; Wireshark might require a newer version.  What 
> version do you have on your system?
>
> ___
> Sent via:Wireshark-dev mailing list 
> Archives:https://www.wireshark.org/lists/wir

Re: [Wireshark-dev] Current master not compiling

[Anders Broman]

Hi,
Thanks Graham that fixed it. I was running the build (separate build dir) on my 
localized repo where I had been doing nmake builds before. Cleaning that up 
(clean distclean maintainer-clean)
Fixed the problem. I’m pretty sure I did clean on it before starting though.

Actually, just tested on my Wireshark dir, clean does not remove the generated 
files distclean does…
Best regards
Anders

From: wireshark-dev-boun...@wireshark.org 
[mailto:wireshark-dev-boun...@wireshark.org] On Behalf Of Graham Bloice
Sent: den 4 april 2016 15:26
To: Developer support list for Wireshark
Subject: Re: [Wireshark-dev] Current master not compiling



On 4 April 2016 at 12:05, Anders Broman 
mailto:anders.bro...@ericsson.com>> wrote:
Hi,
I'm also facing issues on MSVC 2015 and Cmake

 C:\Development\ewireshark\trunk\epan\dfilter\dfilter.c(214): error 
C2065: 'yyscan_t': undeclared identifier 
[C:\Development\wsbuild64\epan\dfilter\dfilter.vcxproj]
 C:\Development\ewireshark\trunk\epan\dfilter\dfilter.c(214): error 
C2146: syntax error: missing ';' before identifier 'scanner' 
[C:\Development\wsbuild64\epan\dfilter\dfilter.vcxproj]
 C:\Development\ewireshark\trunk\epan\dfilter\dfilter.c(214): error 
C2065: 'scanner': undeclared identifier 
[C:\Development\wsbuild64\epan\dfilter\dfilter.vcxproj]
 C:\Development\ewireshark\trunk\epan\dfilter\dfilter.c(215): error 
C2065: 'YY_BUFFER_STATE': undeclared identifier 
[C:\Development\wsbuild64\epan\dfilter\dfilter.vcxproj]
 C:\Development\ewireshark\trunk\epan\dfilter\dfilter.c(215): error 
C2146: syntax error: missing ';' before identifier 'in_buffer' 
[C:\Development\wsbuild64\epan\dfilter\dfilter.vcxproj]
 C:\Development\ewireshark\trunk\epan\dfilter\dfilter.c(215): error 
C2065: 'in_buffer': undeclared identifier 
[C:\Development\wsbuild64\epan\dfilter\dfilter.vcxproj]
 C:\Development\ewireshark\trunk\epan\dfilter\dfilter.c(235): error 
C2065: 'scanner': undeclared identifier 
[C:\Development\wsbuild64\epan\dfilter\dfilter.vcxproj]
 C:\Development\ewireshark\trunk\epan\dfilter\dfilter.c(243): error 
C2065: 'in_buffer': undeclared identifier 
[C:\Development\wsbuild64\epan\dfilter\dfilter.vcxproj]
 C:\Development\ewireshark\trunk\epan\dfilter\dfilter.c(243): error 
C2065: 'scanner': undeclared identifier 
[C:\Development\wsbuild64\epan\dfilter\dfilter.vcxproj]
 C:\Development\ewireshark\trunk\epan\dfilter\dfilter.c(250): error 
C2065: 'scanner': undeclared identifier 
[C:\Development\wsbuild64\epan\dfilter\dfilter.vcxproj]
 C:\Development\ewireshark\trunk\epan\dfilter\dfilter.c(256): error 
C2065: 'scanner': undeclared identifier 
[C:\Development\wsbuild64\epan\dfilter\dfilter.vcxproj]
 C:\Development\ewireshark\trunk\epan\dfilter\dfilter.c(319): error 
C2065: 'in_buffer': undeclared identifier 
[C:\Development\wsbuild64\epan\dfilter\dfilter.vcxproj]
 C:\Development\ewireshark\trunk\epan\dfilter\dfilter.c(319): error 
C2065: 'scanner': undeclared identifier 
[C:\Development\wsbuild64\epan\dfilter\dfilter.vcxproj]
 C:\Development\ewireshark\trunk\epan\dfilter\dfilter.c(320): error 
C2065: 'scanner': undeclared identifier 
[C:\Development\wsbuild64\epan\dfilter\dfilter.vcxproj]


   "C:\Development\wsbuild64\Wireshark.sln" (default target) (1) ->
   "C:\Development\wsbuild64\ALL_BUILD.vcxproj.metaproj" (default target) 
(2) ->
   "C:\Development\wsbuild64\ui\ui.vcxproj.metaproj" (default target) (113) 
->
   "C:\Development\wsbuild64\ui\ui.vcxproj" (default target) (165) ->
 C:\Development\ewireshark\trunk\ui\text_import.c(909): error C2065: 
'yyscan_t': undeclared identifier [C:\Development\wsbuild64\ui\ui.vcxproj]
 C:\Development\ewireshark\trunk\ui\text_import.c(909): error C2146: 
syntax error: missing ';' before identifier 'scanner' 
[C:\Development\wsbuild64\ui\ui.vcxproj]
 C:\Development\ewireshark\trunk\ui\text_import.c(909): error C2065: 
'scanner': undeclared identifier [C:\Development\wsbuild64\ui\ui.vcxproj]
 C:\Development\ewireshark\trunk\ui\text_import.c(1021): error C2065: 
'scanner': undeclared identifier [C:\Development\wsbuild64\ui\ui.vcxproj]
 C:\Development\ewireshark\trunk\ui\text_import.c(1027): error C2065: 
'scanner': undeclared identifier [C:\Development\wsbuild64\ui\ui.vcxproj]
 C:\Development\ewireshark\trunk\ui\text_import.c(1029): error C2065: 
'scanner': undeclared identifier [C:\Development\wsbuild64\ui\ui.vcxproj]
 C:\Development\ewireshark\trunk\ui\text_import.c(1031): error C2065: 
'scanner': undeclared identifier [C:\Development\wsbuild64\ui\ui.vcxproj]

But dfi

Re: [Wireshark-dev] Fake MAC addresses in text2pcap and "Import from hex dump"

[Anders Broman]

-Original Message-
From: wireshark-dev-boun...@wireshark.org 
[mailto:wireshark-dev-boun...@wireshark.org] On Behalf Of Guy Harris
Sent: den 12 april 2016 02:04
To: Developer support list for Wireshark
Subject: [Wireshark-dev] Fake MAC addresses in text2pcap and "Import from hex 
dump"

When synthesizing an Ethernet header, text2pcap uses 0a:02:02:02:02:02 as the 
destination address and 0a:01:01:01:01:01 as the source address, while "Import 
from hex dump" uses 20:52:45:43:56:00 as the destination and 20:53:45:4E:44:00 
as the source.

Is there some reason why they're different?

If not, which of them *should* both be using?
Even if  R E C V and S E N D is clever I think I prefer the other one which 
makes it clearer that it's a fake MAC.

Regards
Anders
___
Sent via:Wireshark-dev mailing list 
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://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://wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

[Wireshark-dev] Build failing on SUSE 11.3

[Anders Broman]

Hi,
The build fails for me on SUSE 11.3

/usr/lib64/gcc/x86_64-suse-linux/4.3/../../../../x86_64-suse-linux/bin/ld: 
skipping incompatible /usr/lib/libc.a when searching for -lc
ui/gtk/libgtkui.a(gui_utils.o): In function `window_icon_realize_cb':
/home/ericsson/ewireshark/trunk/ui/gtk/gui_utils.c:121: undefined reference to 
`wsicon_16_pb_data'
/home/ericsson/ewireshark/trunk/ui/gtk/gui_utils.c:122: undefined reference to 
`wsicon_32_pb_data'
:
Etc

Related to HAVE_GDK_GRESOURCE ?

Ideas?

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

[Wireshark-dev] rpm-build on SuSE 11.3 fails with "new version string"

[Anders Broman]

tardir=wireshark-2.1.0-git && tar --format=ustar -chf - "$tardir" | bzip2 -9 -c 
>wireshark-2.1.0-git.tar.bz2
{ test ! -d wireshark-2.1.0-git || { find wireshark-2.1.0-git -type d ! -perm 
-200 -exec chmod u+w {} ';' && rm -fr wireshark-2.1.0-git; }; }
error: line 28: Illegal char '-' in version: Version:  2.1.0-git
make: *** [rpm-package] Error 1
___
Sent via:Wireshark-dev mailing list 
Archives:https://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] rpm-build on SuSE 11.3 fails with "new version string"

[Anders Broman]

-Original Message-
>From: wireshark-dev-boun...@wireshark.org 
>[mailto:wireshark-dev-boun...@wireshark.org] On Behalf Of João Valverde
>Sent: den 22 april 2016 11:05
>To: Developer support list for Wireshark
>Subject: Re: [Wireshark-dev] rpm-build on SuSE 11.3 fails with "new version 
>string"
>
>The problem is also present with old version string for automated builds.
>
>How should this string be sanitized for RPM? Is there some best practice?

Well a day or two ago I got further, then it failed with dependency problems on 
autoconf and rpmbuild even though I've installed a newer autoconf from source.

On 22-04-2016 09:33, Anders Broman wrote:
> tardir=wireshark-2.1.0-git && tar --format=ustar -chf - "$tardir" |
> bzip2 -9 -c >wireshark-2.1.0-git.tar.bz2
>
> { test ! -d wireshark-2.1.0-git || { find wireshark-2.1.0-git -type d !
> -perm -200 -exec chmod u+w {} ';' && rm -fr wireshark-2.1.0-git; }; }
>
> error: line 28: Illegal char '-' in version: Version:  2.1.0-git
>
> make: *** [rpm-package] Error 1
>
>
>
> ___
> Sent via:Wireshark-dev mailing list 
> Archives:https://www.wireshark.org/lists/wireshark-dev
> Unsubscribe: https://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://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://wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

[Wireshark-dev] How to download required libraries when using Cmake?

[Anders Broman]

Hi,
How are you to download the required support libraries with cmake?
With nmake you get a warning if they are out of date and you can run the setup 
target to have them updated. If I'm not missing something this does not work 
with
Cmake?

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

[Wireshark-dev] namake build fails fatal error U1073: don't know how to make 'ws_version_info.obj'

[Anders Broman]

cd ..
cd wsutil
"C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\BIN\amd64\nmake.
exe" /   -f Makefile.nmake

Microsoft (R) Program Maintenance Utility Version 12.00.21005.1
Copyright (C) Microsoft Corporation.  All rights reserved.

NMAKE : fatal error U1073: don't know how to make 'ws_version_info.obj'
Stop.
NMAKE : fatal error U1077: '"C:\Program Files (x86)\Microsoft Visual Studio 12.0
\VC\BIN\amd64\nmake.exe"' : return code '0x2'
Stop.
___
Sent via:Wireshark-dev mailing list 
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

[Wireshark-dev] How to trigger a rebuild of ASN1 dissectors with cmake?

[Anders Broman]

Hi,
I just did some edits in packet-h248-template.c and rerun cmake but the 
dissector did not rebuild...
Regards
Anders
___
Sent via:Wireshark-dev mailing list 
Archives:https://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] How to trigger a rebuild of ASN1 dissectors with cmake?

[Anders Broman]

Den 3 maj 2016 16:58 skrev "Pascal Quantin" :
>
> Hi Anders,
>
> 2016-05-03 16:47 GMT+02:00 Anders Broman :
>>
>> Hi,
>>
>> I just did some edits in packet-h248-template.c and rerun cmake but the
dissector did not rebuild...
>
>
> On Windows, you need to go to epan\dissectors\asn\h248 folder and run:
> msbuild /m /p:Configuration=RelWithDebInfo generate_dissector-h248.vcxproj
>
> On other systems, I expect that you have a command rather similar (but
did not try it).
>
> You can rebuild all ASN.1 dissectors at once by going to
epan\dissectors\asn1 folder and running:
> msbuild /m /p:Configuration=RelWithDebInfo asn1.vcxproj
>
>
> Regards,
> Pascal.
>
>

Something  for the development guide :-)
Regards
Anders

___
> Sent via:Wireshark-dev mailing list 
> Archives:https://www.wireshark.org/lists/wireshark-dev
> Unsubscribe: https://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://wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

[Wireshark-dev] Exported PDU timestamp problem

[Anders Broman]

Hi
In the created exported PDU file there seems to be a problem with the
timestamps. I'm not sure if it's related to the recent changes to the
pcap-ng block handling or something else. Exported PDU uses ns resolution
when writing. If someone cares to take a look I'd be grateful. I will not
have the time until next week.
Regards
Anders
___
Sent via:Wireshark-dev mailing list 
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

[Wireshark-dev] Build fails on SuSE 11.3, print_stream.c:151: error: implicit declaration of function 'g_get_codeset'

[Anders Broman]

Hi,
I got a report that the build fails on SuSE 11.3. Is someone else seeing this? 
I don't have the time to look into it just right now.

cc1: warnings being treated as errors
print_stream.c: In function 'print_line_text':
print_stream.c:151: error: implicit declaration of function 'g_get_codeset'
print_stream.c:151: error: assignment makes pointer from integer without a cast

Regards
Anders
___
Sent via:Wireshark-dev mailing list 
Archives:https://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] Build fails on SuSE 11.3, print_stream.c:151: error: implicit declaration of function 'g_get_codeset'

[Anders Broman]

-Original Message-
From: wireshark-dev-boun...@wireshark.org 
[mailto:wireshark-dev-boun...@wireshark.org] On Behalf Of Guy Harris
Sent: den 13 maj 2016 11:16
To: Developer support list for Wireshark
Subject: Re: [Wireshark-dev] Build fails on SuSE 11.3, print_stream.c:151: 
error: implicit declaration of function 'g_get_codeset'

On May 13, 2016, at 1:56 AM, Anders Broman  wrote:

>> I got a report that the build fails on SuSE 11.3. Is someone else seeing 
>> this? I don’t have the time to look into it just right now.
>>  
>> cc1: warnings being treated as errors
>> print_stream.c: In function 'print_line_text':
>> print_stream.c:151: error: implicit declaration of function 'g_get_codeset'
>> print_stream.c:151: error: assignment makes pointer from integer without a 
>> cast
>
>The GLib documentation for g_get_codeset():
>
>   
> https://developer.gnome.org/glib/stable/glib-Character-Set-Conversion.html#g-get-codeset
>
>doesn't have a "Since 2.XXX" item, but perhaps they just forgot to add one.  
>What version of GLib is in SuSE 11.3?
>
>My Mac has GLib 2.36.0 installed, and g_get_codeset() is declared in 
>glib/gcharset.h; glib.h includes , so including glib.h should 
>be sufficient to get >g_get_codeset() declared in that version of GLib.
>

The reporter says:
glib2-lang-2.22.5-0.2.23
glib2-2.22.5-0.2.23
___
Sent via:Wireshark-dev mailing list 
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://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://wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

[Wireshark-dev] Configure/autogen failing on Ubuntu 14.04

[Anders Broman]

Hi,
I get
Makefile.am:415: error: HAVE_SPEEXDSP does not appear in AM_CONDITIONAL
codecs/Makefile.am:38: error: HAVE_SPEEXDSP does not appear in AM_CONDITIONAL
ui/qt/Makefile.am:27: error: HAVE_SPEEXDSP does not appear in AM_CONDITIONAL

Anyone else seeing this?

Regards
Anders
___
Sent via:Wireshark-dev mailing list 
Archives:https://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] Configure/autogen failing on Ubuntu 14.04

[Anders Broman]

Aha a local mishap I did not get the changed configure.ac copied over to my 
private build as I had it open in the editor….
Sorry for the noise
Regards
Anders

From: wireshark-dev-boun...@wireshark.org 
[mailto:wireshark-dev-boun...@wireshark.org] On Behalf Of Jeff Morriss
Sent: den 18 maj 2016 16:38
To: Developer support list for Wireshark
Subject: Re: [Wireshark-dev] Configure/autogen failing on Ubuntu 14.04



On Wed, May 18, 2016 at 10:07 AM, Anders Broman 
mailto:anders.bro...@ericsson.com>> wrote:
Hi,
I get
Makefile.am:415: error: HAVE_SPEEXDSP does not appear in AM_CONDITIONAL
codecs/Makefile.am:38: error: HAVE_SPEEXDSP does not appear in AM_CONDITIONAL
ui/qt/Makefile.am:27: error: HAVE_SPEEXDSP does not appear in AM_CONDITIONAL

Anyone else seeing this?

I'm not. Did you re-run ./autogen.sh?  HAVE_SPEEXDSP *is* in an 
AM_CONDITIONAL...
If that doesn't work, try maintainer-clean?
___
Sent via:Wireshark-dev mailing list 
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

[Wireshark-dev] proto_tree_add_item_ret_uint() returns unmasked value - should it?

[Anders Broman]

Hi,
proto_tree_add_item_ret_uint() returns the value corresponding to the length of 
the value fetched e.g uint8, uint16 etc but does not take the mask of
the hf entry into consideration which lead to a bug in an proprietary dissector 
I have.
Should it in fact return the value displayed in the corresponding hf variable 
e.g take the mask into consideration?
Regards
Anders
___
Sent via:Wireshark-dev mailing list 
Archives:https://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] proto_tree_add_item_ret_uint() returns unmasked value - should it?

[Anders Broman]

Hi,
I’m also OK either way but as Pascal says taking the mask into account seems 
more sane.

How about changing
static void
proto_tree_set_uint(field_info *fi, guint32 value)
to return integer and use that.

Regards
Anders

From: wireshark-dev-boun...@wireshark.org 
[mailto:wireshark-dev-boun...@wireshark.org] On Behalf Of Pascal Quantin
Sent: den 18 juli 2016 15:40
To: Developer support list for Wireshark 
Subject: Re: [Wireshark-dev] proto_tree_add_item_ret_uint() returns unmasked 
value - should it?

Hi guys,
I was bugged by the same issue but contrary to Michael, I used the API and 
added the bit shift / masking manually from the output of 
proto_tree_add_item_ret_uint...
So I'm fine doing the change to take the mask into account (It would seem 
saner) but let's coordinate so that we can fix the dissectors accordingly (and 
not introduce new bugs ;) ).
Or we keep the current behavior but add a big warning in the function header to 
make the users aware of this behavior.

Pascal.

2016-07-18 15:04 GMT+02:00 Michael Mann 
mailto:mman...@netscape.net>>:
I've been wondering that myself, and I'm leaning towards "yes it should" 
because there have been many cases where I couldn't use 
proto_tree_add_item_ret_uint where I wanted to because masks were involved.


-Original Message-
From: Anders Broman 
mailto:anders.bro...@ericsson.com>>
To: wireshark-dev 
mailto:wireshark-dev@wireshark.org>>
Sent: Mon, Jul 18, 2016 8:45 am
Subject: [Wireshark-dev] proto_tree_add_item_ret_uint() returns unmasked value 
- should it?
Hi,
proto_tree_add_item_ret_uint() returns the value corresponding to the length of 
the value fetched e.g uint8, uint16 etc but does not take the mask of
the hf entry into consideration which lead to a bug in an proprietary dissector 
I have.
Should it in fact return the value displayed in the corresponding hf variable 
e.g take the mask into consideration?
Regards
Anders
___
Sent via: Wireshark-dev mailing list 
mailto:d...@wireshark.org>>
Archives: https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

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

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

[Wireshark-dev] extcap.c does not build on SUSE 11.3. g_spawn_check_exit_status requires glib 2.34

[Anders Broman]

Hi,
I get
extcap.c:842: undefined reference to `g_spawn_check_exit_status' on SUSe 11.3 
with top of trunk.

Perhaps we should not build extcap on such an old system?

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

[Wireshark-dev] make dist fails if built without Qt

[Anders Broman]

make[1]: Leaving directory wireshark/trunk/ui/gtk'
(cd ui/qt && make  top_distdir=../../wireshark-2.3.0 
distdir=../../wireshark-2.3.0/ui/qt \
 am__remove_distdir=: am__skip_length_check=: am__skip_mode_fix=: distdir)
make[1]: Entering directory `/home/ericsson/ewireshark/trunk/ui/qt'
  LRELEASE   wireshark_de.qm
/bin/sh: -silent: command not found
make[1]: *** [wireshark_de.qm] Error 127
___
Sent via:Wireshark-dev mailing list 
Archives:https://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] Adding Qt5 libs via VS Additional Dependencies

[Anders Broman]

Hi,
As Graham I’m suspicious about GUI code in plugins. Code “enhancing” the GUI 
should probably be placed in the respective GUI folder(Qt or GTK) and hook into 
the menus.
I suppose that currently require you to build a custom Wireshark version. Can’t 
your GUI code be made part of the standard version?
Regards
Anders

From: wireshark-dev-boun...@wireshark.org 
[mailto:wireshark-dev-boun...@wireshark.org] On Behalf Of Roland Knall
Sent: den 5 augusti 2016 11:25
To: Developer support list for Wireshark 
Subject: Re: [Wireshark-dev] Adding Qt5 libs via VS Additional Dependencies

Paul, could you give an example, why you chose Qt libraries over Gtk? Was it 
not possible, or is it a personal choice?

I do have plugins for WS, which use Qt, but not for dissectors, so I am just 
curious, what was missing.

regards
Roland

On Fri, Aug 5, 2016 at 11:20 AM, Graham Bloice 
mailto:graham.blo...@trihedral.com>> wrote:
On 5 August 2016 at 07:54, Paul Offord 
mailto:paul.off...@advance7.com>> wrote:
Hi,

I have written a plugin dissector that uses some Qt5 functions.  To build with 
Visual Studio 2013 I have to manually add some Qt5 libs via Project -> 
Properties -> Linker -> Input -> Additional Dependencies.  This works OK but 
whenever I run:

cmake -D ENABLE_CHM_GUIDES=on -G "Visual Studio 12 Win64" ..\

to prepare the environment the Qt5 additional Dependencies are deleted.  How 
can I add my additional libs to the Cmake process in a way that won’t interfere 
with the standard build process?  Or should I be doing this some completely 
different way?

Thanks and regards…Paul



Although I'm suspicious of why a dissector should need anything from Qt, have a 
look at the CMake wiki page for "Finding a library" at 
https://cmake.org/Wiki/CMake:How_To_Find_Libraries

Basically add the appropriate find_package(), include_directories() and 
target_link_libraries() calls to the CMakeLists.txt of your plugin for the QT 
library you want.

Note that this behaviour is by design, CMake generates the Visual Studio 
solutions and projects from the info in the CMakeLists.txt files, there is no 
way to make changes in the VS IDE and push them back into the CMakeLists.txt 
files (except if you open the file in the VS editor).

You might also have to add steps to the CMakeLists.txt to copy the required Qt 
DLL to the staging directory and the update the packaging scripts to put it 
into an installer (packaging\nsis\custom_plugins.txt).

--
Graham Bloice

___
Sent via:Wireshark-dev mailing list 
mailto:wireshark-dev@wireshark.org>>
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://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://wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] Registering protocol details

[Anders Broman]

Den 7 aug. 2016 11:25 fm skrev "Paul Offord" :
>
> Hi,
>
>
>
> I’ve written a small program that converts web logs into pcap-ng files
with a dummy Ethernet header

You could use the exported pdu format
See exported_pdu.h in epan directory. Should you need new tags for meta
information those could be added.
Regards
Anders

I’m now writing a dissector for the resulting pcap-ng file.  The problem is
that the number and meaning of the “columns” in the log is not predictable
– it depends on the web log format settings.  Therefore the first entry in
the pcap-ng file contains the name of the field, a definition of the data
type and the column position.  In the dissector, I read this first record
and then set up an hf_register_info array.  That’s the background, now my
question.
>
>
>
> Can I make calls to proto_register_xxx functions in my dissector, or must
they be made from proto_register_?
>
>
>
> Thanks and regards…Paul
>
>
> __
>
> 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://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://wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] Registering protocol details

[Anders Broman]

Den 7 aug. 2016 1:11 em skrev "Paul Offord" :
>
> Hi Anders,
>
>
>
> Thanks for the prompt reply.  I’ve read through exported_pdu.h and I
don’t understand how this helps me.  Is there somewhere I can read more
about using exported_pdu functions?
>
>
>
> Thanks and regards…Paul

Instead of writing a fake Ethernet header You could write an exported pdu
header.
I'm not sure that would help you but it gets rid of the faked layer and you
can add meta data in the exported pdu section should you want to.

>
>
>
> From: wireshark-dev-boun...@wireshark.org [mailto:
wireshark-dev-boun...@wireshark.org] On Behalf Of Anders Broman
> Sent: 07 August 2016 11:02
> To: Developer support list for Wireshark 
> Subject: Re: [Wireshark-dev] Registering protocol details
>
>
>
> Den 7 aug. 2016 11:25 fm skrev "Paul Offord" :
> >
> > Hi,
> >
> >
> >
> > I’ve written a small program that converts web logs into pcap-ng files
with a dummy Ethernet header
>
> You could use the exported pdu format
> See exported_pdu.h in epan directory. Should you need new tags for meta
information those could be added.
> Regards
> Anders
>
> I’m now writing a dissector for the resulting pcap-ng file.  The problem
is that the number and meaning of the “columns” in the log is not
predictable – it depends on the web log format settings.  Therefore the
first entry in the pcap-ng file contains the name of the field, a
definition of the data type and the column position.  In the dissector, I
read this first record and then set up an hf_register_info array.  That’s
the background, now my question.
> >
> >
> >
> > Can I make calls to proto_register_xxx functions in my dissector, or
must they be made from proto_register_?
> >
> >
> >
> > Thanks and regards…Paul
> >
> >
> > __
> >
> > 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://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
> 

Re: [Wireshark-dev] Cmake and RPM

[Anders Broman]

Hi,
Did configure find rpmbuild?

Regards
Anders
From: wireshark-dev-boun...@wireshark.org 
[mailto:wireshark-dev-boun...@wireshark.org] On Behalf Of Jonne Zutt
Sent: den 16 augusti 2016 11:23
To: wireshark-dev@wireshark.org
Subject: [Wireshark-dev] Cmake and RPM

Hi all,

Could somebody tell me what I have to do to be able to build an RPM package?

I successfully build wireshark using cmake and make.
I have a working wireshark-gtk executable in the build directory that I can run 
and works fine.

Now, if I try to run "make rpm-package", it seems it doesn't know the target. I 
wonder what I have to do to get this?

$ make rpm-package
make: *** No rule to make target `rpm-package'.  Stop.

Thanks,
Jonne.

___
Sent via:Wireshark-dev mailing list 
Archives:https://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] Exported PUD proto_name

[Anders Broman]

From: wireshark-dev-boun...@wireshark.org 
[mailto:wireshark-dev-boun...@wireshark.org] On Behalf Of Dario Lombardo
Sent: den 29 augusti 2016 17:03
To: Developer support list for Wireshark 
Subject: Re: [Wireshark-dev] Exported PUD proto_name

I tried again with udpdump using
- http (4 bytes long), aligned ==> works correctly
- dns (3 bytes), not aligned, 1 byte padding ==> works correctly
At this point I guess it's something related to the specific aruba_erm 
dissector. Alexis, did you try it? Any success?

As Pascal said, the problem is probably that packet-aruba_erm.c does not 
register the dissector by name. Packet-exported_pdu.c has

switch(next_proto_type) {
case EXPORTED_PDU_NEXT_PROTO_STR:
proto_handle = find_dissector(proto_name);
if (proto_handle) {
col_clear(pinfo->cinfo, COL_PROTOCOL);
call_dissector_with_data(proto_handle, payload_tvb, pinfo, 
tree, dissector_data);
}
break;

We should probably have an expert info if the protocol isn’t found. I have also 
found this function recently

proto_get_id_by_filter_name(const gchar* filter_name);

which could be used as a second alternative if the protocol isn’t found. That 
would make register by name superfluous in most cases I think.

Best regards
Anders


On Fri, Aug 26, 2016 at 10:44 AM, Dario Lombardo 
mailto:dario.lombardo...@gmail.com>> wrote:
Ok, we'll wait for some clarifications from Alexis.

___
Sent via:Wireshark-dev mailing list 
Archives:https://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] Makefiles for private dissectors

[Anders Broman]

Hi,
You need to edit Custom.m4 and Custom.make in the plugins folder. Fror 
packaging on windows you also have to look for custom files in /packaging/nsis
Regards
Anders

From: wireshark-dev-boun...@wireshark.org 
[mailto:wireshark-dev-boun...@wireshark.org] On Behalf Of Not Me
Sent: den 30 augusti 2016 12:10
To: wireshark-dev@wireshark.org
Subject: [Wireshark-dev] Makefiles for private dissectors

Dear Wireshark devs,

I'm trying to build my own dissectors, and followed a manual where it put all 
of these in a folder called private_plugins and uses a CMakeListsCustom.txt, 
which I put at the bottom of this mail (simply setting CUSTOM_PLUGIN_SRC_DIR to 
foo and bar).

I got everything to work, an executable built, and my private dissectors work 
fine as well. Now, I noticed I am able to package a .dmg file on osx (and an 
rpm as well) using make osx-package (or make rpm-package). However, I need to 
switch to Makefiles for that. I noticed my private plugins are no longer picked 
up, and not part of the actual package built.

I searched through many examples on the web, also the doc/ subfolder, and tried 
many things. But I'm not able to get it to work. Would be great if someone 
could tell me how to get it working.

Maybe I show tell what I currently have... (although I tried many other things).

$ cat plugins/Custom.make
#

_CUSTOM_SUBDIRS_ = \
../private_plugins/foo \
../private_plugins/bar \

_CUSTOM_EXTRA_DIST_ = \
Custom.m4 \
Custom.make

_CUSTOM_plugin_ldadd_ = \
-dlopen ../private_plugins/foo/foo.la \
-dlopen ../private_plugins/bar/bar.la

_CUSTOM_PLUGIN_SRC_ = \
../private_plugins/foo/packet-foo.c \
../private_plugins/bar/packet-bar.c

Configure:
I don't see the configure script output something like "config.status: creating 
private_plugins/foo/Makefile", which I think it should somehow?

Make:
make fails because there's no Makefile

Making all in plugins
Making all in ../private_plugins/foo
make[3]: *** No rule to make target `all'.  Stop.
make[2]: *** [all-recursive] Error 1
make[1]: *** [all-recursive] Error 1
make: *** [all] Error 2



// This used to work for cmake:

$ cat CMakeListsCustom.txt
set(CUSTOM_PLUGIN_SRC_DIR
private_plugins/foo
private_plugins/bar
)

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

[Wireshark-dev] ./configure failing on Ubuntu 14.04

[Anders Broman]

Hi,
I'm getting
checking for Qt5Core - version >= 5.0.0... yes (version 5.2.1)
checking for Qt5Gui - version >= 5.0.0... yes (version 5.2.1)
checking for Qt5Widgets - version >= 5.0.0... yes (version 5.2.1)
checking for Qt5PrintSupport - version >= 5.0.0... yes (version 5.2.1)
checking for Qt5Multimedia - version >= 5.0.0... yes (version 5.2.1)
checking for Qt5MacExtras - version >= 5.0.0... no
checking whether Qt works without -fPIC... no
checking whether Qt works with -fPIC... yes
checking for qtchooser... /usr/bin/qtchooser
checking for uic... /usr/bin/uic
checking for qtchooser... (cached) /usr/bin/qtchooser
checking for moc... /usr/bin/moc
checking for qtchooser... (cached) /usr/bin/qtchooser
checking for rcc... /usr/bin/rcc
checking for qtchooser... (cached) /usr/bin/qtchooser
checking for lrelease... /usr/bin/lrelease
checking whether lrelease -version works... no
configure: error: /usr/bin/lrelease -qt=5 -version returned non-zero exit status

Any ideas?

Regards
Anders
___
Sent via:Wireshark-dev mailing list 
Archives:https://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] ./configure failing on Ubuntu 14.04

[Anders Broman]

Hi,
I think I built on this machine a while ago, but it turns out Alexis is right:
>Anders,
>Do you have qttools5-dev-tools packages ?
I did not have that package and after adding it, configure works...
Thanks all

Regards
Anders

-Original Message-
From: wireshark-dev-boun...@wireshark.org 
[mailto:wireshark-dev-boun...@wireshark.org] On Behalf Of João Valverde
Sent: den 31 augusti 2016 15:27
To: Developer support list for Wireshark 
Subject: Re: [Wireshark-dev] ./configure failing on Ubuntu 14.04

I suggest opening a bug report so we can track the issue.

See also bug 12570[1]

[1]https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=12570

On 08/31/2016 02:05 PM, Anders Broman wrote:
> Hi,
>
> I'm getting
>
> checking for Qt5Core - version >= 5.0.0... yes (version 5.2.1)
>
> checking for Qt5Gui - version >= 5.0.0... yes (version 5.2.1)
>
> checking for Qt5Widgets - version >= 5.0.0... yes (version 5.2.1)
>
> checking for Qt5PrintSupport - version >= 5.0.0... yes (version 5.2.1)
>
> checking for Qt5Multimedia - version >= 5.0.0... yes (version 5.2.1)
>
> checking for Qt5MacExtras - version >= 5.0.0... no
>
> checking whether Qt works without -fPIC... no
>
> checking whether Qt works with -fPIC... yes
>
> checking for qtchooser... /usr/bin/qtchooser
>
> checking for uic... /usr/bin/uic
>
> checking for qtchooser... (cached) /usr/bin/qtchooser
>
> checking for moc... /usr/bin/moc
>
> checking for qtchooser... (cached) /usr/bin/qtchooser
>
> checking for rcc... /usr/bin/rcc
>
> checking for qtchooser... (cached) /usr/bin/qtchooser
>
> checking for lrelease... /usr/bin/lrelease
>
> checking whether lrelease -version works... no
>
> configure: error: /usr/bin/lrelease -qt=5 -version returned non-zero 
> exit status
>
>
>
> Any ideas?
>
>
>
> Regards
>
> Anders
>
>
>
> ___
> Sent via:Wireshark-dev mailing list 
> Archives:https://www.wireshark.org/lists/wireshark-dev
> Unsubscribe: https://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://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://wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

[Wireshark-dev] PCAP NG files not closed properly any more?

[Anders Broman]

Hi,
Looking at a pcap-ng file just produced with the File viewer [MIME file format] 
I get
[Packet size limited during capture: File-PCAPNG truncated]

I'm looking at a problem where it seems we have no NRB block in the file any 
more. I have the option "Only use the profile "hosts" file set.

Regards
Anders
___
Sent via:Wireshark-dev mailing list 
Archives:https://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] Remove of GTK interface

[Anders Broman]

Hi,
I have reports from internal users that the Qt interface does not work when 
connecting remotely by VNC or  ssh -X to the sniffer so for me that’s a 
showstopper to get rid of GTK.
Regards
Anders

From: wireshark-dev-boun...@wireshark.org 
[mailto:wireshark-dev-boun...@wireshark.org] On Behalf Of Roland Knall
Sent: den 5 september 2016 15:06
To: Developer support list for Wireshark 
Subject: [Wireshark-dev] Remove of GTK interface

Hi

As I understand correctly, the gtk interface is being phased out to a point, 
where it will not be included in 2.4 anymore. I am currently one the brink of 
adding new features to extcap, and doing so would need me to change some 
internal interfaces, some of which are used only by the gtk interface.

Should I take the time and fix those, or are the days for the gtk interface 
numbered anyway and it will be removed in the not-so-near future?

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

[Wireshark-dev] Elapsed Time for Wireshark startup

[Anders Broman]

Hi,
I did a check to see where the time is spent when starting up Wireshark and 
here's the findings:
( Win 7 and GTK )

Enter main:   Elapsed time 0us
load_wpcap:   Elapsed time 0us
Get version strings:  Elapsed time 1us
gtk_init: Elapsed time 2us
gtk_init done:Elapsed time 5us
capture_opts_init:Elapsed time 5us
splash_new: Loading Wireshark...  Elapsed time 5us
init_open_routines:   Elapsed time 14us
Plugins:  Elapsed time 14us
splash_update Initializing dissectors:Elapsed time 18us
Call epan_init:   Elapsed time 19us
splash_update Register all tap listeners: Elapsed time 411000us
register_all_plugin_tap_listeners:Elapsed time 422000us
extcap_register_preferences:  Elapsed time 422000us
register_all_tap_listeners:   Elapsed time 2526000us
hostlist_table_set_gui_info:  Elapsed time 2526000us
splash_update Register all preferences:   Elapsed time 2526000us
Load configuration files: Elapsed time 2656000us
fill_in_local_interfaces: Elapsed time 2656000us
Wireshark is up and ready to go:  Elapsed time 5952000us

extcap_register_preferences and fill_in_local_interfaces stands out as the most 
time consuming activities.

Regards
Anders
___
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] VoIP Calls dialog enhancements

[Anders Broman]

Patches are very welcome, the void call stuff might need some love :-)
Regards
Anders

Den 20 okt. 2016 8:04 em skrev "Erik de Jong" :

> After a very exciting Sharkfest Europe I've decided to participate a bit
> in the development of Wireshark!
>
> Some enhancements for the VoIP calls dialog would be:
> 1) Have the timestamps not only as a relative time from the start of
> capture but also as the time of day. I have added two columns for this, but
> I'm contemplating if it would not be better to have a checkbox that toggles
> the existing start and end time columns from relative to time of day
> timestamps. Any feedback would be appreciated as I couldn't find any UI
> design guidelines to help decide what's the better option here, as it is
> part of a Qt dialog I have used the QDateTime::fromTime_t function to
> format the timestamps. I couldn't quickly find the way this is done for the
> packet list, is there a preferred conversion for the nstime to a formatted
> timestamp?
> 2) I would also suggest a column containing the call duration.
>
> I would be more than happy to submit patches for these enhancements.
>
> Cheers,
> Erik
>
> 
> ___
> 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] Segfault when running older Wireshark with capture from CVE-2013-4075

[Anders Broman]

>-Original Message-
>From: wireshark-dev-boun...@wireshark.org 
>[mailto:wireshark-dev-boun...@wireshark.org] On Behalf Of Martin Sehnoutka
>Sent: den 11 november 2016 10:34
>To: Developer support list for Wireshark 
>Subject: [Wireshark-dev] Segfault when running older Wireshark with capture 
>from CVE-2013-4075
>
>Hi,
>
>I'm running wireshark 1.8 and it sometimes segfaults when I'm repeatedly 
>executing tshark with capture from this bug:
>https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=7664 (CVE-2013-4075).

https://wiki.wireshark.org/Development/LifeCycle 

Version  Stable Release Date  End of LifeNotes

1.8  June 21, 2012 June 21, 2014 Last release to support OS 
X on PPC

1.8 vent end-of-life June 21, 2014

>It seems that the function 'csnStreamDissector' sometimes fails and in turn 
>causes the segfault.
>I can bypass it with this patch:
>https://github.com/msehnout/wireshark/commit/103b383db500c6fb00e77b342241ff7475185676
>
>Shouldn't we check the return value of that function?
>
>The newest version is not affected, it seems to add one extra line, but the 
>return value is still not handled:
> https://github.com/msehnout/wireshark/blob/master/epan/dissectors/packet-gmr1_bcch.c#L1091
>  


Thanks for any advice.
Martin

--
Martin Sehnoutka | Associate Software Engineer
PGP: 5FD64AF5
UTC+1 (CET)
RED HAT | TRIED. TESTED. TRUSTED.


___
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

[Wireshark-dev] RPM Build fails on SUSE 11.3

[Anders Broman]

Hi,

Even though configured with:
/configure --with-lua -enable-setuid-install --without-qt --with-gtk=2 
-without-libnl --enable-warnings-as-errors=no --with-extcap=no

Rpm-build fails with:

extcap_gtk.c: In function 'extcap_gtk_get_state':
extcap_gtk.c:193: error: 'GTimeZone' undeclared (first use in this function)
extcap_gtk.c:193: error: (Each undeclared identifier is reported only once
extcap_gtk.c:193: error: for each function it appears in.)
extcap_gtk.c:193: error: 'tz' undeclared (first use in this function)
extcap_gtk.c:193: warning: implicit declaration of function 'g_time_zone_new'
extcap_gtk.c:195: error: 'GDateTime' undeclared (first use in this function)
extcap_gtk.c:195: error: 'datetime' undeclared (first use in this function)
extcap_gtk.c:195: warning: implicit declaration of function 'g_date_time_new'
extcap_gtk.c:196: warning: implicit declaration of function 
'g_date_time_to_unix'
extcap_gtk.c:198: warning: implicit declaration of function 'g_date_time_unref'
extcap_gtk.c:199: warning: implicit declaration of function 'g_time_zone_unref'

What do I need to change in
packaging/rpm/SPECS/wireshark.spec.in to make it build without extcap?

Regards
Anders
___
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] QT DLLs missing from build environment

[Anders Broman]

Hi,
At some point I think there was a fault in Qt causing it to not copy all .dll 
when running the command to do so. I'm currently building with Qt 5.6 which I 
believe is supposed
To be LTS.
Regards
Anders

From: wireshark-dev-boun...@wireshark.org 
[mailto:wireshark-dev-boun...@wireshark.org] On Behalf Of Paul Offord
Sent: den 27 december 2016 14:05
To: Developer support list for Wireshark 
Subject: [Wireshark-dev] QT DLLs missing from build environment

I'm building the latest Wireshark source on Windows 7 with QT5.5.1 and VS 2013. 
 As you may have seen from earlier posts, I scratched my old build environment 
and I'm creating a new one.  The build prep and build (Debug) complete 
successfully, but when I try to start Wireshark I get a message saying 
Qt5PrintSupportd.dll can't be found.

I remember this from when I created the environment last time around, and I 
fixed it by copying the DLLs required into the Wireshark run directory.  I 
guess this isn't the way I should be doing it.  What's the correct procedure 
here?

Thanks and regards...Paul


__

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] QT DLLs missing from build environment

[Anders Broman]

Hi,
FWIW I think what I was referring to was around this issue 
https://www.wireshark.org/lists/wireshark-dev/201406/msg00021.html and it may 
have been an nmake build...

Yes I think I saw someone claiming to build with Qt 5.7. I haven't tried...
Regards
Anders

From: wireshark-dev-boun...@wireshark.org 
[mailto:wireshark-dev-boun...@wireshark.org] On Behalf Of Paul Offord
Sent: den 27 december 2016 15:12
To: Developer support list for Wireshark 
Subject: Re: [Wireshark-dev] QT DLLs missing from build environment

Hi Anders,

I plan to upgrade Qt but I thought I'd try a build with releases I've used 
before.  I notice that the Qt site is offering 5.7 - is that a supported 
release?

Thanks...Paul


Sent from Samsung Mobile on O2

 Original message ----
From: Anders Broman
Date:27/12/2016 14:04 (GMT+00:00)
To: Developer support list for Wireshark
Subject: Re: [Wireshark-dev] QT DLLs missing from build environment

Hi,
At some point I think there was a fault in Qt causing it to not copy all .dll 
when running the command to do so. I'm currently building with Qt 5.6 which I 
believe is supposed
To be LTS.
Regards
Anders

From: 
wireshark-dev-boun...@wireshark.org<mailto:wireshark-dev-boun...@wireshark.org> 
[mailto:wireshark-dev-boun...@wireshark.org] On Behalf Of Paul Offord
Sent: den 27 december 2016 14:05
To: Developer support list for Wireshark 
mailto:wireshark-dev@wireshark.org>>
Subject: [Wireshark-dev] QT DLLs missing from build environment

I'm building the latest Wireshark source on Windows 7 with QT5.5.1 and VS 2013. 
 As you may have seen from earlier posts, I scratched my old build environment 
and I'm creating a new one.  The build prep and build (Debug) complete 
successfully, but when I try to start Wireshark I get a message saying 
Qt5PrintSupportd.dll can't be found.

I remember this from when I created the environment last time around, and I 
fixed it by copying the DLLs required into the Wireshark run directory.  I 
guess this isn't the way I should be doing it.  What's the correct procedure 
here?

Thanks and regards...Paul


__

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
__

__

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

[Wireshark-dev] make-version.pl "problems"

[Anders Broman]

Hi,
I recently ported the updated make-version.pl to my local SVN based Wireshark 
clone and have some problems on Windows:
With these settings

my $set_version = 1;
my $set_release = 1;

Cmake failed complaining on path
I changed line 546 from:
for $filedir ("epan", "wiretap") { # "wsutil"
to:
for $filedir ("$srcdir/epan", "$srcdir/wiretap") {  # "wsutil"

and 574
from
for $filedir ("epan", "wiretap") { # "wsutil"
to
for $filedir ("$srcdir/epan", "$srcdir/wiretap") {  # "wsutil"

Is this something that can go into the released version?

Additionally the changed files get "wrong line endings" as the script seems to 
add UNIX style line endings and I have them as eol-style native.

Regards
Anders


___
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] make-version.pl "problems"

[Anders Broman]

Hi,
Thanks for looking in to it but
Still not completely ok :-(

Line 551, 578
$line = sprintf("$1%d$2\n"
I removed \n

But there is still problems with
Debaian/changelog
/CMakeLists.txt
./configure.ac

Regards
Anders
-Original Message-
From: wireshark-dev-boun...@wireshark.org 
[mailto:wireshark-dev-boun...@wireshark.org] On Behalf Of Gerald Combs
Sent: den 2 januari 2017 18:32
To: Developer support list for Wireshark 
Subject: Re: [Wireshark-dev] make-version.pl "problems"

Change 19508 should fix both of these issues.

On 1/2/17 6:20 AM, Anders Broman wrote:
> Hi,
> 
> I recently ported the updated make-version.pl to my local SVN based 
> Wireshark clone and have some problems on Windows:
> 
> With these settings
> 
>  
> 
> my $set_version = 1;
> 
> my $set_release = 1;
> 
>  
> 
> Cmake failed complaining on path
> 
> I changed line 546 from:
> 
> for $filedir ("epan", "wiretap") { # "wsutil"
> 
> to:
> 
> for $filedir ("$srcdir/epan", "$srcdir/wiretap") {  # "wsutil"
> 
>  
> 
> and 574
> 
> from
> 
> for $filedir ("epan", "wiretap") { # "wsutil"
> 
> to
> 
> for $filedir ("$srcdir/epan", "$srcdir/wiretap") {  # "wsutil"
> 
>  
> 
> Is this something that can go into the released version?
> 
>  
> 
> Additionally the changed files get "wrong line endings" as the script 
> seems to add UNIX style line endings and I have them as eol-style native.
> 
>  
> 
> Regards
> 
> Anders
> 
>  
> 
>  
> 
> 
> 
> ___
> 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

[Wireshark-dev] extcap slowing down start of WS

[Anders Broman]

Hi,
It now seems like extcap_register_preferences is the thing taking the longest 
time when starting up Wireshark, at least on Window.
Any one care to take a look?

Regards
Anders
___
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] extcap slowing down start of WS

[Anders Broman]

Hi,
> all improvements are planned for 2.4

No problem for me.
Here’s some timing info if someone is interested.

15:02:49 Main Info set_console_log_handler, elapsed time 247000 us

15:02:49 Main Info Calling epan init, elapsed time 275000 us

15:02:50 Main Info epan done, elapsed time 1242000 us

15:02:50 Main Info Register all tap listeners, elapsed time 1253000 us

15:02:50 Main Info Calling extcap_register_preferences, elapsed time 1254000
us

15:02:51  Capture Dbg  Extcap pipe C:\Development\wsbuild-gpl\run\RelWithDebInfo
\extcap\androiddump.exe
15:02:52  Capture Dbg  Extcap pipe C:\Development\wsbuild-gpl\run\RelWithDebInfo
\extcap\ciscodump.exe
15:02:52  Capture DbgExtcap [(null)]
15:02:52  Capture DbgInterface [cisco] "Cisco remote capture"
15:02:52  Capture Dbg  Extcap pipe C:\Development\wsbuild-gpl\run\RelWithDebInfo
\extcap\randpktdump.exe
15:02:52  Capture DbgExtcap [(null)]
15:02:52  Capture DbgInterface [randpkt] "Random packet generator"
15:02:52  Capture Dbg  Extcap pipe C:\Development\wsbuild-gpl\run\RelWithDebInfo
\extcap\sshdump.exe
15:02:52  Capture DbgExtcap [(null)]
15:02:52  Capture DbgInterface [ssh] "SSH remote capture"
15:02:52  Capture Dbg  Extcap pipe C:\Development\wsbuild-gpl\run\RelWithDebInfo
\extcap\udpdump.exe
15:02:52  Capture DbgExtcap [(null)]
15:02:52  Capture DbgInterface [udpdump] "UDP Listener remote capture"
15:02:52  Capture Dbg  Extcap path C:\Development\wsbuild-gpl\run\RelWithDebInfo
\extcap
15:02:52  Capture Dbg  Extcap path C:\Development\wsbuild-gpl\run\RelWithDebInfo
\extcap
15:02:52  Capture Dbg  Extcap path C:\Development\wsbuild-gpl\run\RelWithDebInfo
\extcap
15:02:52  Capture Dbg  Extcap path C:\Development\wsbuild-gpl\run\RelWithDebInfo
\extcap
15:02:52 Main Info Calling module preferences, elapsed time 3004000 us

15:02:52 Main Info Calling fill_in_local_interfaces, elapsed time 320 us


15:02:52 Main Info fill_in_local_interfaces() starts
15:02:52  Capture Info sync_pipe_run_command() starts
15:02:53  Capture Info sync_pipe_run_command() ends, taking 0.229s, result=0
15:02:54  Capture Info sync_pipe_run_command() starts
15:02:54  Capture Info sync_pipe_run_command() ends, taking 0.163s, result=0
15:02:54  Capture Info sync_pipe_run_command() starts
15:02:54  Capture Info sync_pipe_run_command() ends, taking 0.173s, result=0
15:02:54  Capture Info sync_pipe_run_command() starts
15:02:54  Capture Info sync_pipe_run_command() ends, taking 0.164s, result=0
15:02:55 Main Info fill_in_local_interfaces() ends, taking 2.404s
15:02:55 Main Info Calling prefs_apply_all, elapsed time 5637000 us

15:02:55 Main Info Wireshark is up and ready to go, elapsed time 5952000us

Regards
Anders

From: wireshark-dev-boun...@wireshark.org 
[mailto:wireshark-dev-boun...@wireshark.org] On Behalf Of Roland Knall
Sent: den 4 januari 2017 09:53
To: Developer support list for Wireshark 
Subject: Re: [Wireshark-dev] extcap slowing down start of WS

@Stiq - this is the plan going forward. But first, I need to fix the initial 
call to the interfaces on Windows, because there is an issue with stdin buffers 
on Windows and a large number of interfaces.

The register preferences call is a necessity, but the one in 
fill_in_local_interfaces could be avoided, and should be actually. I'll look 
into that as well. But for now, all improvements are planned for 2.4, not 2.2

regards
Roland

On Wed, Jan 4, 2017 at 8:20 AM, Stig Bjørlykke 
mailto:s...@bjorlykke.org>> wrote:
On Tue, Jan 3, 2017 at 5:56 PM, Anders Broman
mailto:anders.bro...@ericsson.com>> wrote:
> It now seems like extcap_register_preferences is the thing taking the
> longest time when starting up Wireshark, at least on Window.

One issue is that extcap_register_preferences is called before loading
the interfaces, and therefore all extcap binaries are run twice
because of multiple calls to extcap_reload_interface_list().  One in
extcap_register_preferences() and one in fill_in_local_interfaces().
This should be improved.

Loading extcap could be done in the background after Wireshark has
started, like is done in "Refresh Interfaces".


--
Stig Bjørlykke
___
Sent via:Wireshark-dev mailing list 
mailto:wireshark-dev@wireshark.org>>
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
 
mailto:wireshark-dev-requ...@wireshark.org<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

[Wireshark-dev] Preferences needed during Wireshark startup

[Anders Broman]

Hi,
Looking into the time required to start Wireshark I came across a problem with 
the console on Windows where the preferences
prefs.console_log_level
prefs.gui_console_open
is needed for logging to work but preferences are set pretty late in the 
startup phases as dissectors etc need to have their preferences loaded first.
I'm also thinking about adding preferences for loading extcap plugins or not 
which would make it easier to "activate" them when needed and perhaps chose
Which ones one like to use. But those preferences would be needed before the 
preference file is loaded currently.
One possible solution could be to load and parse the file into a structure for 
later processing early in the startup and then "look" at the list of preferences
When needed during startup or create a new file with "basic preferences" loaded 
early or...
I'm not sure I'm up to taking on this task but at least we could discuss design 
ideas and if some one is willing to take it on I'd be grateful.

Best regards
Anders

___
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] Remote Control Plugin - Can I submit to the Wireshark project

[Anders Broman]

Does this overlap with sharkd by Jacub, currently under review in gerrit?
Regards
Anders

Den 6 jan. 2017 2:35 em skrev "Paul Offord" :

Hi,



Some time ago I wrote a Wireshark plugin (called Syncro) that enables a
program to send commands to Wireshark.  The command set is based on the
capabilities provided by the Wireshark Plugin IF API (go to frame, apply
filter, etc.).



The commands are sent to Wireshark via a TCP connection, and so there is a
small TCP service running on a separate thread in Wireshark.  The TCP
service, multi-threading and thread-to-thread communications are built on
Qt.  Note the email trail below, where Roland suggests that it might not be
necessary to use Qt.



I’d like to submit this to the Wireshark project as I think it could form
the basis for a general capability of controlling Wireshark from a loosely
coupled application.  Is this code suitable for submission to the project?



Thanks and regards…Paul



*From:* wireshark-dev-boun...@wireshark.org [mailto:wireshark-dev-bounces@
wireshark.org] *On Behalf Of *Roland Knall
*Sent:* 05 August 2016 11:57
*To:* Developer support list for Wireshark 
*Subject:* Re: [Wireshark-dev] Adding Qt5 libs via VS Additional
Dependencies



This is exactly what I do here with my plugin. Although without the TCP
part. The method to do it without using Qt in the dissector is to implement
a tap interface in the dissector, and register the plugin on that
interface. The plugin than can start the TCP server and monitors the tap
interface and reacts accordingly to the commands. Would work fine for you,
the same way you do it now, but would be far easier to maintain. The
dissector would be stable and does never need to change, and all you would
have to recompile is the plugin.



regards

Roland



On Fri, Aug 5, 2016 at 12:46 PM, Paul Offord 
wrote:

Hi Roland,

No, not really an RPC interface.  Some very simple commands and events flow
back and forth, like this:

Command|GoToFrame|55

Response|MovedToFrame|55

Event|MovedToFrame|67

We needed it to be a dissector to enable us to detect when the user moves
within a trace so that we can generate a suitable asynchronous event.  We
also needed the functionality now, and it had to work with standard WS
releases, so it had to be a plugin of some sort.  By the way, we are not
planning to submit this to be incorporated into the main stream code.

You can see Syncro in action here http://www.youtube.com/watch?
v=anEZGfF4P10&t=5m5s if you are interested.

Best regards…Paul



*From:* wireshark-dev-boun...@wireshark.org [mailto:wireshark-dev-bounces@
wireshark.org] *On Behalf Of *Roland Knall
*Sent:* 05 August 2016 11:10


*To:* Developer support list for Wireshark 
*Subject:* Re: [Wireshark-dev] Adding Qt5 libs via VS Additional
Dependencies

So, if I understand it correctly, it is a RPC interface? I still think,
implementing this as a dissector is a major overkill, and will also lead to
issues further down the line, if dissectory API changes or similar issues.
I'd implement such an interface via a simple plugin architecture, which
would have the added benefit, that you do not have the need for an active
dissection runnning, to query the instance. A dissection should be mainly
about "How to interpret packet data", which is not the case here.

regards

Roland



On Fri, Aug 5, 2016 at 11:33 AM, Paul Offord 
wrote:

Hi Roland,

The dissector is called Syncro and it allows a remote process to access the
WS plugin_if extensions through a TCP connection.  We wanted to be able to
achieve this without building a custom version of WS and so built it as a
dissector.  We don’t use any of the GUI stuff from Qt, just the TCP server
functionality, multi-threading functions and Signals & Slots to communicate
between threads.

Best regards…Paul



__

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
_

[Wireshark-dev] Sharkd warnings when built with VisualStudio 2015 64bit

[Anders Broman]

Hi,
In case some is interested :)

   "C:\Development\wsbuild-gpl\Wireshark.sln" (default target) (1) ->
   "C:\Development\wsbuild-gpl\sharkd.vcxproj.metaproj" (default target) 
(49) ->
   "C:\Development\wsbuild-gpl\sharkd.vcxproj" (default target) (153) ->
 C:\Development\wireshark\sharkd_daemon.c(167): warning C4244: 
'return': conversion from 'SOCKET' to 'int', possible loss of data 
[C:\Development\wsbuild-gpl\sharkd.vcxproj]
 C:\Development\wireshark\sharkd_daemon.c(245): warning C4244: '=': 
conversion from 'SOCKET' to 'int', possible loss of data 
[C:\Development\wsbuild-gpl\sharkd.vcxproj]
 C:\Development\wireshark\sharkd_daemon.c(276): warning C4312: 'type 
cast': conversion from 'int' to 'HANDLE' of greater size 
[C:\Development\wsbuild-gpl\sharkd.vcxproj]
 C:\Development\wireshark\sharkd_daemon.c(277): warning C4312: 'type 
cast': conversion from 'int' to 'HANDLE' of greater size 
[C:\Development\wsbuild-gpl\sharkd.vcxproj]
 C:\Development\wireshark\sharkd_daemon.c(282): warning C4090: 
'function': different 'const' qualifiers 
[C:\Development\wsbuild-gpl\sharkd.vcxproj]


Regards
Anders
___
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] Tshark: proto_tree not created on first pass with tap defined

[Anders Broman]

Hi,
I guess the idea in tshark for the 2 pass analysis is not to create a tree on 
the first pass to increase performance and you probably just want the result of 
the
Final pass over the file where hopefully all needed information is available. I 
suppose we require all code to handle a NULL tree.

Regards
Anders


From: wireshark-dev-boun...@wireshark.org 
[mailto:wireshark-dev-boun...@wireshark.org] On Behalf Of Paul Offord
Sent: den 10 februari 2017 09:16
To: Developer support list for Wireshark 
Subject: [Wireshark-dev] Tshark: proto_tree not created on first pass with tap 
defined

Hi,

I've been investigating a problem with transum, a post-dissector.  If you run 
tshark with transum it throws Access Violations.  I'm starting tshark with 
these arguments:

-2 -q -ta -o transum.tsumenabled:TRUE -T fields -E separator=, -E quote=d -E 
header=y -e frame.number -e _ws.col.Time -e ip.src -e ip.dst -e tcp.srcport -e 
tcp.dstport -e _ws.col.Info -r 
"C:\traces\Contoso_01\web01\web01_1_20161012151754.pcap"

NB: The -2 flag indicates that tshark should make two passes.

The reason transum throws Access Violations is because the dissect_transum 
dissector is called on the first pass with a NULL proto_tree pointer.  I'll add 
defensive code to transum to avoid the Access Violation but there is an 
underlying problem.

It's normal for a dissector to be called with a NULL proto_tree pointer on the 
first pass *unless* a tap has been registered.  Transum registers a tap, and so 
when using Wireshark, each first-pass call to dissect_transum includes a 
pointer to a proto_tree.  With tshark, even though the tap is registered the 
proto_tree pointer is still NULL.

When running Wirehsark, the decision to create a proto_tree is made in cf_read 
of file.c with this code:

  /* Get the union of the flags for all tap listeners. */
  tap_flags = union_of_tap_listener_flags();
  create_proto_tree =
(dfcode != NULL || have_filtering_tap_listeners() || (tap_flags & 
TL_REQUIRES_PROTO_TREE));

  [lines removed from listing]

  epan_dissect_init(&edt, cf->epan, create_proto_tree, FALSE);


When running tshark with the parameters above the decision to create a 
proto_tree is made in load_cap_file(...) function of tshark.c with this code:

  /* Do we have any tap listeners with filters? */
  filtering_tap_listeners = have_filtering_tap_listeners();

  /* Get the union of the flags for all tap listeners. */
  tap_flags = union_of_tap_listener_flags();

  if (perform_two_pass_analysis) {
frame_data *fdata;

   [lines removed from listing]

if (do_dissection) {
   gboolean create_proto_tree = FALSE;

  /* If we're going to be applying a filter, we'll need to
 create a protocol tree against which to apply the filter. */
  if (cf->rfcode || cf->dfcode)
create_proto_tree = TRUE;

  tshark_debug("tshark: create_proto_tree = %s", create_proto_tree ? "TRUE" 
: "FALSE");

  /* We're not going to display the protocol tree on this pass,
 so it's not going to be "visible". */
  edt = epan_dissect_new(cf->epan, create_proto_tree, FALSE);
}


Neither, cf->rfcode or cf->dfcode are true and so the tree isn't created.  I 
think the code should be:

  if (cf->rfcode || cf->dfcode || filtering_tap_listeners)
create_proto_tree = TRUE;


Am I right?  Have I misunderstood something about tshark?

Thanks and regards...Paul

__

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

[Wireshark-dev] Wireshark no longer builds on SuSE 11.3

[Anders Broman]

Hi,
Wireshark no longer builds on SuSE 11.3

home/ericsson/ewireshark/trunk/filter_files.c:104: undefined reference to 
`g_list_free_full'
/home/ericsson/ewireshark/trunk/filter_files.c:105: undefined reference to 
`g_list_free_full'
/home/ericsson/ewireshark/trunk/filter_files.c:106: undefined reference to 
`g_list_free_full'
/home/ericsson/ewireshark/trunk/filter_files.c:107: undefined reference to 
`g_list_free_full'
ui/gtk/libgtkui.a(dfilter_expr_dlg.o): In function `value_list_sel_cb':
/home/ericsson/ewireshark/trunk/ui/gtk/dfilter_expr_dlg.c:625: undefined 
reference to `g_list_free_full'


Regards
Anders
___
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] Wireshark no longer builds on SuSE 11.3

[Anders Broman]

Hi,
The code is simple enough (from glib-2.42.2 ).
**
* g_list_free_full:
* @list: a pointer to a #GList
* @free_func: the function to be called to free each element's data
*
* Convenience method, which frees all the memory used by a #GList,
* and calls @free_func on every element's data.
*
* Since: 2.28
*/
void
g_list_free_full (GList  *list,
  GDestroyNotify  free_func)
{
  g_list_foreach (list, (GFunc) free_func, NULL);
  g_list_free (list);
}

To provide the function for systems not having it, Evan didn’t like the 
function cast though even though it’s used by glib.

As for dropping SuSE 11.3 it’s perhaps time…

Regards
Anders

From: wireshark-dev-boun...@wireshark.org 
[mailto:wireshark-dev-boun...@wireshark.org] On Behalf Of Roland Knall
Sent: den 14 februari 2017 13:47
To: Developer support list for Wireshark 
Subject: Re: [Wireshark-dev] Wireshark no longer builds on SuSE 11.3

I was hoping to say, let's drop SuSE 11.3, as SuSE 11.4 has glib version 2.28, 
which includes the function. Also ReadHat 5 drops support by the end of next 
month. But SLES still supports it until 2019.

As for the convenience method, I would not provide a compatibility header, as 
this would require additional checks and defines. Just hardcode the 
functionality in this case, although it seems to be a burden. An utility 
function which masks the compatibility could also be a possible solution. In 
extcap I came across this issue quite some time, and most of the time I ended 
up hardcoding the functionality.

regards
Roland

On Tue, Feb 14, 2017 at 1:28 PM, Peter Wu 
mailto:pe...@lekensteyn.nl>> wrote:
On Tue, Feb 14, 2017 at 12:14:24PM +, Anders Broman wrote:
> Hi,
> Wireshark no longer builds on SuSE 11.3
>
> home/ericsson/ewireshark/trunk/filter_files.c:104: undefined reference to 
> `g_list_free_full'
> /home/ericsson/ewireshark/trunk/filter_files.c:105: undefined reference to 
> `g_list_free_full'
> /home/ericsson/ewireshark/trunk/filter_files.c:106: undefined reference to 
> `g_list_free_full'
> /home/ericsson/ewireshark/trunk/filter_files.c:107: undefined reference to 
> `g_list_free_full'
> ui/gtk/libgtkui.a(dfilter_expr_dlg.o): In function `value_list_sel_cb':
> /home/ericsson/ewireshark/trunk/ui/gtk/dfilter_expr_dlg.c:625: undefined 
> reference to `g_list_free_full'

This function is very useful and open-coded many times, should we
provide a compatibility header for older GLib?
--
Kind regards,
Peter Wu
https://lekensteyn.nl
___
Sent via:Wireshark-dev mailing list 
mailto:wireshark-dev@wireshark.org>>
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
 
mailto:wireshark-dev-requ...@wireshark.org<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] Loading value_string from file?

[Anders Broman]

The diameter dissector builds value strings from file. The sminpec value
string is built from a script.
Regards
Anders

Den 15 feb. 2017 2:47 em skrev "Peter Wu" :

> Hi,
>
> While many protocols have fixed value_string mappings, some of them are
> quite dynamic (USB Vendor/Product IDs, "enterprise-numbers" (sminmpec),
> services, etc.).
>
> Has there ever been an attempt to load these from file? This has the
> benefit that these files can be updated without having to
> rebuild/install a new version of Wireshark. (Additional benefits: the
> data can be compressed and ignored from Lintian spell-checking.)
> --
> Kind regards,
> Peter Wu
> https://lekensteyn.nl
> 
> ___
> 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] Loading value_string from file?

[Anders Broman]

The diameter value strings are built runtime as is the radius ones I think.

Den 15 feb. 2017 3:35 em skrev "Peter Wu" :

> On Wed, Feb 15, 2017 at 03:07:37PM +0100, Anders Broman wrote:
> > The diameter dissector builds value strings from file. The sminpec value
> > string is built from a script.
> > Regards
> > Anders
>
> But that is at compile-time, I was thinking of a runtime option.
>
> Kind regards,
> Peter
>
> > Den 15 feb. 2017 2:47 em skrev "Peter Wu" :
> >
> > > Hi,
> > >
> > > While many protocols have fixed value_string mappings, some of them are
> > > quite dynamic (USB Vendor/Product IDs, "enterprise-numbers" (sminmpec),
> > > services, etc.).
> > >
> > > Has there ever been an attempt to load these from file? This has the
> > > benefit that these files can be updated without having to
> > > rebuild/install a new version of Wireshark. (Additional benefits: the
> > > data can be compressed and ignored from Lintian spell-checking.)
> > > --
> > > Kind regards,
> > > Peter Wu
> > > https://lekensteyn.nl
> 
> ___
> 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

[Wireshark-dev] Buildiing with Qt 5.8 fails on Windows

[Anders Broman]

Hi,
Trying to build with Qt 5.8 and Visual Studio 2015 I get:
 C:\Development\wsbuild-gpl\ui\qt\moc_capture_file_dialog.cpp(113): 
error C2039: 'preview': is not a member of 'CaptureFileDialog' 
[C:\Development\wsbuild-gpl\ui\qt\qtui.vcxproj]
 C:\Development\wsbuild-gpl\ui\qt\moc_capture_file_dialog.cpp(114): 
error C2039: 'on_buttonBox_helpRequested': is not a member of 
'CaptureFileDialog' [C:\Development\wsbuild-gpl\ui\qt\qtui.vcxproj]
 C:\Development\wsbuild-gpl\ui\qt\moc_export_dissection_dialog.cpp(85): 
error C2039: 'exportTypeChanged': is not a member of 'ExportDissectionDialog' 
[C:\Development\wsbuild-gpl\ui\qt\qtui.vcxproj]
 C:\Development\wsbuild-gpl\ui\qt\moc_export_dissection_dialog.cpp(86): 
error C2039: 'checkValidity': is not a member of 'ExportDissectionDialog' 
[C:\Development\wsbuild-gpl\ui\qt\qtui.vcxproj]
 C:\Development\wsbuild-gpl\ui\qt\moc_export_dissection_dialog.cpp(87): 
error C2039: 'on_buttonBox_helpRequested': is not a member of 
'ExportDissectionDialog' [C:\Develo


Any ideas?

Regards
Anders
___
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] Buildiing with Qt 5.8 fails on Windows

[Anders Broman]

> You can also just nuke the build dir and run the CMake gen and a normal build 
> command.
This is what I did prior to building…

In the moc file you can see that it is built with Qt 5.8
#include "../../../wireshark/ui/qt/capture_file_dialog.h"
#include 
#include 
#if !defined(Q_MOC_OUTPUT_REVISION)
#error "The header file 'capture_file_dialog.h' doesn't include ."
#elif Q_MOC_OUTPUT_REVISION != 67
#error "This file was generated using the moc from 5.8.0. It"
#error "cannot be used with the include files from this version of Qt."
#error "(The moc has changed too much.)"
#endif

But it looks like it’s not obeying

From the .h file
private slots:
#if !defined(Q_OS_WIN)
void preview(const QString & path);
void on_buttonBox_helpRequested();
#endif // Q_OS_WIN


Regards
Anders

From: wireshark-dev-boun...@wireshark.org 
[mailto:wireshark-dev-boun...@wireshark.org] On Behalf Of Graham Bloice
Sent: den 9 mars 2017 12:48
To: Developer support list for Wireshark 
Subject: Re: [Wireshark-dev] Buildiing with Qt 5.8 fails on Windows

General answer, not specific to the QT and VS versions, Have you previously 
built in this directory?  If so delete CMakeCache.txt, run the CMake generation 
step and then add "/t:Rebuild" to the msbuild command line to force a total 
rebuild.  You can also just nuke the build dir and run the CMake gen and a 
normal build command.

On 9 March 2017 at 11:43, Anders Broman 
mailto:anders.bro...@ericsson.com>> wrote:
Hi,
Trying to build with Qt 5.8 and Visual Studio 2015 I get:
 C:\Development\wsbuild-gpl\ui\qt\moc_capture_file_dialog.cpp(113): 
error C2039: 'preview': is not a member of 'CaptureFileDialog' 
[C:\Development\wsbuild-gpl\ui\qt\qtui.vcxproj]
 C:\Development\wsbuild-gpl\ui\qt\moc_capture_file_dialog.cpp(114): 
error C2039: 'on_buttonBox_helpRequested': is not a member of 
'CaptureFileDialog' [C:\Development\wsbuild-gpl\ui\qt\qtui.vcxproj]
 C:\Development\wsbuild-gpl\ui\qt\moc_export_dissection_dialog.cpp(85): 
error C2039: 'exportTypeChanged': is not a member of 'ExportDissectionDialog' 
[C:\Development\wsbuild-gpl\ui\qt\qtui.vcxproj]
 C:\Development\wsbuild-gpl\ui\qt\moc_export_dissection_dialog.cpp(86): 
error C2039: 'checkValidity': is not a member of 'ExportDissectionDialog' 
[C:\Development\wsbuild-gpl\ui\qt\qtui.vcxproj]
 C:\Development\wsbuild-gpl\ui\qt\moc_export_dissection_dialog.cpp(87): 
error C2039: 'on_buttonBox_helpRequested': is not a member of 
'ExportDissectionDialog' [C:\Develo


Any ideas?

Regards
Anders

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



--
Graham Bloice
Software Developer
Trihedral UK Limited
___
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] Buildiing with Qt 5.8 fails on Windows

[Anders Broman]

Hi,
It looks like it’s this problem
https://bugreports.qt.io/browse/QTBUG-58345?jql=text%20~%20%22Qt5CoreMacros%22

Change Qt5CoreMacros.cmake
Line 93 – 95 to:

if (MSVC)
set(${_moc_flags} ${${_moc_flags}} --compiler-flavor=msvc)
endif()

Makes the build work.

Regards
Anders

From: wireshark-dev-boun...@wireshark.org 
[mailto:wireshark-dev-boun...@wireshark.org] On Behalf Of Anders Broman
Sent: den 9 mars 2017 14:23
To: Developer support list for Wireshark 
Subject: Re: [Wireshark-dev] Buildiing with Qt 5.8 fails on Windows

> You can also just nuke the build dir and run the CMake gen and a normal build 
> command.
This is what I did prior to building…

In the moc file you can see that it is built with Qt 5.8
#include "../../../wireshark/ui/qt/capture_file_dialog.h"
#include 
#include 
#if !defined(Q_MOC_OUTPUT_REVISION)
#error "The header file 'capture_file_dialog.h' doesn't include ."
#elif Q_MOC_OUTPUT_REVISION != 67
#error "This file was generated using the moc from 5.8.0. It"
#error "cannot be used with the include files from this version of Qt."
#error "(The moc has changed too much.)"
#endif

But it looks like it’s not obeying

From the .h file
private slots:
#if !defined(Q_OS_WIN)
void preview(const QString & path);
void on_buttonBox_helpRequested();
#endif // Q_OS_WIN


Regards
Anders

From: 
wireshark-dev-boun...@wireshark.org<mailto:wireshark-dev-boun...@wireshark.org> 
[mailto:wireshark-dev-boun...@wireshark.org] On Behalf Of Graham Bloice
Sent: den 9 mars 2017 12:48
To: Developer support list for Wireshark 
mailto:wireshark-dev@wireshark.org>>
Subject: Re: [Wireshark-dev] Buildiing with Qt 5.8 fails on Windows

General answer, not specific to the QT and VS versions, Have you previously 
built in this directory?  If so delete CMakeCache.txt, run the CMake generation 
step and then add "/t:Rebuild" to the msbuild command line to force a total 
rebuild.  You can also just nuke the build dir and run the CMake gen and a 
normal build command.

On 9 March 2017 at 11:43, Anders Broman 
mailto:anders.bro...@ericsson.com>> wrote:
Hi,
Trying to build with Qt 5.8 and Visual Studio 2015 I get:
 C:\Development\wsbuild-gpl\ui\qt\moc_capture_file_dialog.cpp(113): 
error C2039: 'preview': is not a member of 'CaptureFileDialog' 
[C:\Development\wsbuild-gpl\ui\qt\qtui.vcxproj]
 C:\Development\wsbuild-gpl\ui\qt\moc_capture_file_dialog.cpp(114): 
error C2039: 'on_buttonBox_helpRequested': is not a member of 
'CaptureFileDialog' [C:\Development\wsbuild-gpl\ui\qt\qtui.vcxproj]
 C:\Development\wsbuild-gpl\ui\qt\moc_export_dissection_dialog.cpp(85): 
error C2039: 'exportTypeChanged': is not a member of 'ExportDissectionDialog' 
[C:\Development\wsbuild-gpl\ui\qt\qtui.vcxproj]
 C:\Development\wsbuild-gpl\ui\qt\moc_export_dissection_dialog.cpp(86): 
error C2039: 'checkValidity': is not a member of 'ExportDissectionDialog' 
[C:\Development\wsbuild-gpl\ui\qt\qtui.vcxproj]
 C:\Development\wsbuild-gpl\ui\qt\moc_export_dissection_dialog.cpp(87): 
error C2039: 'on_buttonBox_helpRequested': is not a member of 
'ExportDissectionDialog' [C:\Develo


Any ideas?

Regards
Anders

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



--
Graham Bloice
Software Developer
Trihedral UK Limited
___
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] RTP player - a suggestion

[Anders Broman]

-Original Message-
From: wireshark-dev-boun...@wireshark.org 
[mailto:wireshark-dev-boun...@wireshark.org] On Behalf Of Jirka Novak
Sent: den 26 mars 2017 21:41
To: Developer support list for Wireshark 
Subject: Re: [Wireshark-dev] RTP player - a suggestion

Hello Erik,

>> My proposal:
>> Add 'mixer' layer which will provide the following features to improve
>> usability:
>
>  I started work on "proof of concept" for very similar idea. I didn't 
> finished it yet. But I have a few points which I would like to mention and 
> discuss it there:

>1) There are at least four points where is RTP processed to audio - once for 
>"audio player" and once for "audio save". GTK and Qt UI branch has own code 
>for it => four places.
>I analysed it and found that even Qt code is derived from GTK, it is slightly 
>different. On the other hand, the main difference is between code in audio 
>player and audio save in each branch.
>Therefore my idea is to extract RTP audio processing code to some kind of 
>library.
>I made part of work on it and found that there is one big issue - GTK code 
>"idea" is very different to Qt code. Up to now I found no way how to prepare 
>API for such library which can be used from GTK and Qt code in parallel.
>The question is whether it makes sense to update GTK code when there is long 
>term idea to leave it? If so, there is much more work than just for Qt.

I would vote for not updating the GTK for  the reasons you mention. Worst case 
I'd say remove the GTK RTP player. 

>2) Audio player has multiple ways how to decode RTP - with dejitter buffer, 
>based on timestamp, uninterrupted mode. But save audio has no such option and 
>it is very complicated to change it. If it will be changed, there will be 
>>again two places with same options and code.
>My idea is to move "save audio" to "audio play" dialog - it will share common 
>options and control.
>BTW it makes to me more sense to control all RTP audio related tasks from one 
>place.

Sounds reasonable.

>3) When I analysed GTK and Qt code, I found that there is main difference 
>between it. GTK stores all RTP data in memory, Qt extract it to file. Playing 
>is based on extracted data then.
>As consequence of it, there are many C structures in GTK/Qt code which are 
>same named, but slightly different. And there are elements in structures which 
>are shared but used by GTK or Qt code only.
>I think that there must be consensus about storing RTP data during media 
>processing before any library/mixer should be made. Based on this, code should 
>be cleared.
>
>   Sincerely yours,
>
>   Jirka Novak

___
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] Ubuntu PPAs

[Anders Broman]

-Original Message-
From: wireshark-dev-boun...@wireshark.org 
[mailto:wireshark-dev-boun...@wireshark.org] On Behalf Of Peter Wu
Sent: den 14 mars 2017 17:33
To: Bálint Réczey 
Cc: Developer support list for Wireshark 
Subject: Re: [Wireshark-dev] Ubuntu PPAs

On Tue, Mar 14, 2017 at 05:23:02PM +0100, Bálint Réczey wrote:
>> 2017-03-14 14:28 GMT+01:00 Peter Wu :
>> > On Tue, Mar 14, 2017 at 12:29:24AM +0100, Bálint Réczey wrote:
>> >> Hi,
>> >>
>> >> I have created a separate PPA for backported dependencies of Wireshark:
>> >> https://launchpad.net/~wireshark-dev/+archive/ubuntu/wireshark-deps
>> >>
>> >> This would help people running internal builds of Wireshark. (Hi 
>> >> Anders, sorry for the delay ;-))
>> >>
>> >> I plan removing the dependencies from the wireshark-dev/stable PPA 
>> >> to remove redundancy:
>> >> https://launchpad.net/~wireshark-dev/+archive/ubuntu/stable
>> >
>> > Is it possible to express dependencies between PPAs? Otherwise you 
>> > would run into missing dependency issues I think?
>> 
>> Yes, I have already set the dependency relation for the PPAs, but I 
>> would like to give them a try before I remove the redundant packages 
>> from wireshark-dev/stable.
>
>You can add build dependencies to other PPAs, but will these propagate when 
>users add a single archive (e.g. with add-apt-repository 
>ppa:wireshark-dev/stable)?
>
>The Launchpad help pages and the +edit-dependencies page are not very clear on 
>this:
>https://help.launchpad.net/Packaging/PPA/BuildingASourcePackage#Dependencies


Would it make sense to add the latest libpcap stable too?
Regards
Anders
___
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] RTP player - a suggestion

[Anders Broman]

-Original Message-
From: wireshark-dev-boun...@wireshark.org 
[mailto:wireshark-dev-boun...@wireshark.org] On Behalf Of Peter Budny
Sent: den 27 mars 2017 16:48
To: 'Developer support list for Wireshark' 
Subject: Re: [Wireshark-dev] RTP player - a suggestion

Hi Anders,

> -Original Message-
> From: wireshark-dev-boun...@wireshark.org
[mailto:wireshark-dev-boun...@wireshark.org] On Behalf Of Anders Broman
> Sent: Monday, March 27, 2017 4:12 AM
> To: Developer support list for Wireshark
> Subject: Re: [Wireshark-dev] RTP player - a suggestion
> 
>>> My proposal:
>>> Add 'mixer' layer which will provide the following features to 
>>> improve
>>> usability:
>>
>>  I started work on "proof of concept" for very similar idea. I  
>> didn't finished it yet. But I have a few points which I would like  
>> to mention and discuss it there:
>
>>1) There are at least four points where is RTP processed to audio - 
>>once for "audio player" and once for "audio save". GTK and Qt UI 
>>branch has own code for it => four places.
>>
>>I analysed it and found that even Qt code is derived from GTK, it is 
>>slightly different. On the other hand, the main difference is between 
>>code in audio player and audio save in each branch.
>>
>>Therefore my idea is to extract RTP audio processing code to some kind 
>>of library.
>>
>>I made part of work on it and found that there is one big issue - GTK 
>>code "idea" is very different to Qt code. Up to now I found no way how 
>>to prepare API for such library which can be used from GTK and Qt code 
>>in parallel.
>>
>>The question is whether it makes sense to update GTK code when there 
>>is long term idea to leave it? If so, there is much more work than 
>>just for Qt.
>
>I would vote for not updating the GTK for the reasons you mention. 
>Worst case I'd say remove the GTK RTP player.

>I disagree.  Right now, the GTK RTP player is the only one that I consider 
>usable.  By comparison, the Qt RTP player only barely works, and is unusable 
>if you're dealing with more than one stream.  If these changes can improve the 
>Qt >version to be about as good as the GTK version was/is, then perhaps 
>breaking the GTK version is okay.  But don't break/remove the GTK version 
>*and* leave the Qt version less than fully functional.
>--
>Peter Budny

My thinking is that if fixing the Qt version without too much work means 
ditching the GTK version that is OK in the development track as the GTK version 
is still available in older
Versions. Hopefully a usable Qt version would be available before the next 
release.
 
The alternative may be that no one wants to work on any of the versions...

Regards
Anders

___
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] Why does the extcap stuff take so long to start up?

[Anders Broman]

-Original Message-
From: wireshark-dev-boun...@wireshark.org 
[mailto:wireshark-dev-boun...@wireshark.org] On Behalf Of Guy Harris
Sent: den 27 mars 2017 22:33
To: Developer support list for Wireshark 
Subject: Re: [Wireshark-dev] Why does the extcap stuff take so long to start up?

On Mar 27, 2017, at 1:14 PM, Guy Harris  wrote:

>> Currently, with that fix, I get results like
>> 
>> $ time ./tshark -r /tmp/nothing.pcap 
>> 
>> real0m1.407s
>> user0m0.312s
>> sys 0m0.676s
>> 
>> with the extcap directory in place and results like
>> 
>> $ time ./tshark -r /tmp/nothing.pcap 
>> 
>> real0m0.334s
>> user0m0.182s
>> sys 0m0.146s

>> with the extcap directory moved out of the way, so the extcap executables 
>> are taking some time to run, but it's better than wasting time trying to run 
>> androiddump.c or Makefile.am.

>And, if I move various extcap executables out of the way:
>
>$ time ./tshark -r /tmp/nothing.pcap   # all executables
>
>real0m1.484s
>user0m0.313s
>sys 0m0.720s
>
>$ time ./tshark -r /tmp/nothing.pcap   # after removing androiddump
>
>real0m1.179s
>user0m0.287s
>sys 0m0.588s
>
>$ time ./tshark -r /tmp/nothing.pcap   # after removing ciscodump
>
>real0m0.950s
>user0m0.254s
>sys 0m0.491s
>
>$ time ./tshark -r /tmp/nothing.pcap   # after removing randpktcdump
>
>real0m0.688s
>user0m0.228s
>sys 0m0.334s
>
>$ time ./tshark -r /tmp/nothing.pcap   # after removing sshdump
>
>real0m0.493s
>user0m0.198s
>sys 0m0.235s
>
>$ time ./tshark -r /tmp/nothing.pcap   # after removing udpdump
>
>real0m0.335s
>user0m0.183s
>sys 0m0.145s
>
>So that's about .3 seconds for androiddump, about .23 seconds for ciscodump, 
>about .26 seconds for randpktcdump, about .19 seconds for sshdump, and about 
>.16 seconds for usbdump.
>
>So none of them are individually out of the ordinary, but about 1.5 to 2.5 
>seconds per program, with 5 programs, adds up.
>

Would it be possible to run them in parallel?

Regards
Anders

___
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] Adding libxml2 as optional Wireshark dependency

[Anders Broman]

Hi,
Would https://github.com/leethomason/tinyxml2 be an option?
Regards
Anders

From: wireshark-dev-boun...@wireshark.org 
[mailto:wireshark-dev-boun...@wireshark.org] On Behalf Of Alexis La Goutte
Sent: den 5 april 2017 16:14
To: Developer support list for Wireshark 
Subject: Re: [Wireshark-dev] Adding libxml2 as optional Wireshark dependency

Hi,
There is some dissector using XML ? (diameter...)
May be see to convert (or using actual XML code)

Cheers

On Wed, Apr 5, 2017 at 3:48 PM, Pascal Quantin 
mailto:pascal.quan...@gmail.com>> wrote:
Hi Ahmad and Graham,

2017-04-05 15:38 GMT+02:00 Graham Bloice 
mailto:graham.blo...@trihedral.com>>:


On 5 April 2017 at 14:11, Ahmad Fatoum mailto:ah...@a3f.at>> 
wrote:

Hello everyone,

I was advised on Gerrit to post this issue here as to garner wider input.

This concerns proposed Change-Id I13c0a2f408fb5c21bad7ab3d7971e0fa8ed7d783 [1] 
intending to add libxml2 as optional dependency to Wireshark.

I am currently preparing to submit upstream, changes I did to the EPL v2 
dissector (packet-epl.c).

A significant change is the ability to optionally read in user-supplied XML 
device descriptions and to extract type/description/mapping information for 
aiding the dissection. See this previous submission of mine to the mailing 
list: https://www.wireshark.org/lists/wireshark-dev/201701/msg00154.html



Seeing as there also has been interest for libxml2 support in dissectors in the 
past:

https://www.wireshark.org/lists/wireshark-dev/201005/msg00108.html

https://ask.wireshark.org/questions/36063/using-libxml2-in-my-own-dissector



I think, it would be a good idea to have this as optional dependency as Glib's 
GMarkup may be inadequate or inconvenient for parsing actual XML.



Looking forward to your feedback.

Best regards,
Ahmad Fatoum

[1] https://code.wireshark.org/review/#/c/20912/
Thanks for the post,

1.  Where will the Windows binaries come from and are these supported long 
term?  The  libXml2 downloads page indicates another site provides Windows 
binaries [1].  The binaries at that site in the 64 bit directory seem to be the 
most recent and are labelled as libXml2-2.9.3 [2].  The current release of 
libXml2 is 2.9.4 which has a number of security fixes among other bug fixes and 
enhancements [3] so it would appear that the Windows binaries are not being 
maintained.

I suggest to use the binaries provided by openSUSE: they provide win32 and 
win64 variants for libxml2 2.9.0 and we are already using their packages for 
several third party libraries. If it is really required to take the latest 
version, I can probbly give it a try (I already did this in the past to package 
a newer version than the one from openSUSE).

2.  According to the diagram at [1], libXml2 depends on iconv and zlib.  We 
currently build our own zlib, will that be suitable for the libXml2 dependency? 
 What will be the source of the iconv binary (iconv-1.14 is available in the 
same download area as libXml2 [2])?

Same thing: we can use the ones provided by openSUSE (we already have those 
dependencies for other packages).


3. The readme.txt in the download area ([2]) has some "interesting" text:

These are experimental 64bit binaries. For completeness, 32bit binaries

built using the same method are also included.



The libraries in these packages are made using GCC (MinGW) toolchain. It is

presently not possible to use these libraries with any recent version of the

Microsoft Visual C compiler because of conflicting C-runtimes. To help you

resist the temptation, the import libraries (.LIB) are not provided at all.

If you need these libraries in an environment which mandates the use of the

Microsoft toolchain, you will have to build them from source yourself.
and inspection of the download shows this is true, so it appears that we'll 
need to rebuild to obtain the import .lib file.

As part of the process of integrating openSUSE libraries, we are generating the 
.lib file and adding it in the package we upload on our server, so it should be 
OK.

4. Microsoft have a Visual Studio porting effort underway called vcpkg [4], 
that does include libXml2, but unfortunately is only for VS2015 or later.  If 
we move to VS2015 for main releases (post 2.4 release) then this may be a 
viable source for libXml2 and other packages we use.  It might be possible to 
use this to build VS2013 libXml2.

5.  Are there any manufacturers or tools that produce XML device description 
files for the EPL dissector such that choosing XML as the input format is the 
most sensible choice, or would another format be just as applicable?

I agree XML can be painful, so this is a good question ;)



[1]: https://www.zlatkovic.com/libxml.en.html
[2]: ftp://ftp.zlatkovic.com/libxml/64bit/
[3]: http://xmlsoft.org/news.html
[4]: https://github.com/Microsoft/vcpkg

--
Graham Bloice


___
Sent via:Wireshark-dev mailing list 
mailto:wiresha

Re: [Wireshark-dev] Debugging an assertion failure

[Anders Broman]

Hi
I think you are using an illegal character in the  preference name or
module name.
Regards
Anders

Den 14 apr. 2017 12:42 em skrev "Paul Offord" :

> Hi,
>
>
>
> I need some advice.  I’m debugging a problem with a dissector I’ve
> written.  Tshark fails with:
>
> … \epan\prefs.c:414:prefs_register_module_or_subtree: assertion failed:
> (g_ascii_islower(c) || g_ascii_isdigit(c) || c == '_' || c == '-' || c ==
> '.')
>
> This application has requested the Runtime to terminate it in an unusual
> way.
> Please contact the application's support team for more information.
>
> If I remove the dissector the problem goes away and so I’m sure it’s the
> cause.
>
>
>
> Even though I can recreate the problem in a debug build under VS 2013 it
> doesn’t catch the exception.  I just see the above text flash by in the
> output command box.  How can I cause execution to break when it throws the
> exception?
>
>
>
> Thanks and regards…Paul
>
> __
>
> 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
>
___
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