Re: [Wireshark-dev] Wireshark-dev: make it possible to use VS2008/VS2008EE to compile 1.0x?

[Pascal Quantin]

Hi,
As the question has come up a number of times and 1.0.x should live for
another 6 month or so, do we wish to port over the changes necessary to
compile 1.0.x with VS 2008? Perhaps not for the official build but still
possible.
Regards
Anders

Hi,
I'm the one who provided the original patch to add the MSVC2008
compatibility in trunk.
I have locally a patched trunk-1.0 directory including those backports
from trunk:
- the MSVC2008 compatibility
- the fix to package rebuilt adns library for msvcrt compatibility for
NSIS installer
- the fix for the incorrect manifest embedded when compiling Wireshark
with MSVC2008 SP1
If needed I can provide the corresponding patch.

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

Re: [Wireshark-dev] Package issue under Windows XP

[Pascal Quantin]

Hi,

I submitted a patch to Gerald allowing to build 1.0.X branch with
VS2008 and VS2008EE. Wait for its delivery or switch to trunk in the
meantime.

Regards,
Pascal.

2009/1/7 Sean yun...@yahoo.com:
 After modifying from VS2008 PE to EE, the installer still doesn't work.
 Can anyone help me on this issue?
 Thanks a lot.


 --- On Tue, 1/6/09, Anders Broman a.bro...@telia.com wrote:

 From: Anders Broman a.bro...@telia.com
 Subject: SV: [Wireshark-dev] Package issue under Windows XP
 To: yun...@yahoo.com, 'Developer support list for Wireshark' 
 wireshark-dev@wireshark.org
 Date: Tuesday, January 6, 2009, 8:34 PM
 Hi,
 I think changes were made to make WS compile with
 VS2008/VS2008EE after
 branching of the 1.0.x branch. You are better of using
 trunk with VS2008.

 Regards
 Anders

 -Ursprungligt meddelande-
 Från: wireshark-dev-boun...@wireshark.org
 [mailto:wireshark-dev-boun...@wireshark.org] För Sean
 Skickat: den 5 januari 2009 05:36
 Till: Developer support list for Wireshark; Gerald Combs
 Ämne: Re: [Wireshark-dev] Package issue under Windows XP




 --- On Mon, 1/5/09, Gerald Combs
 ger...@wireshark.org wrote:

  From: Gerald Combs ger...@wireshark.org
  Subject: Re: [Wireshark-dev] Package issue under
 Windows XP
  To: yun...@yahoo.com, Developer support list for
 Wireshark
 wireshark-dev@wireshark.org
  Date: Monday, January 5, 2009, 10:54 AM
  Sean wrote:
   Greetings,
  
   I'm using source code of 1.0.4 to build
 package
  under windows XP,
   the compiler is Microsoft Visual Studio 2008
  Professional Edition,
   the config.nmake is configured to
  MSVC_VARIANT=MSVC2008EE,
   after compilation, the package is created
  successfully,
   but after installing on windows XP,
   the wireshark can't run successfully,
   following is the message:
  
   The application failed to initialize
  properly(0xc142). Click on OK to terminate the
  application.
 
  If you have Visual Studio 2008 Profesional Edition,
 you
  should set
  MSVC_VARIANT to MSVC2008 instead of MSVC2008EE (which
 is
  for the Express
  Edition). One of the key differences between the
 Express
  Editions of
  Visual Studio (and the reason we have different
 variant
  definitions) is
  that they don't come with package-able versions of
 the
  C and C++
  runtimes, while the full frontal editions
 do.
 
  Setting the variant to MSVC2008EE (or MSVC2005EE)
 means
  that the
  installer you create won't come with the C
 runtime, and
  assumes that
  you'll have Microsoft Visual C++ 2008 SP1
  Redistributable Package
  installed on the target machine.

 But it seems that the version 1.0.4 can't recognize
 MSVC2008 in
 config.nmake,
 how can I modify the config.nmake?
 should I modify other files for using MSVC 2008
 professional instead of MSVC
 2008 EE?
 Thank you very much.



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

Re: [Wireshark-dev] Package issue under Windows XP

[Pascal Quantin]

Hi Gerald,

it seems you forgot to deliver the added trunk-1.0/adns_dll.dep and
trunk-1.0/adns_dll.rc files that were part of my patch. Without them
the adns recompilation for VS2008 fails.
Those modified files could be added to the adns-1.0-win32-05ws package
and the trunk-1.0/Makefile.nmake file could be adapted accordingly but
I backported what was done in trunk (and 1.1.X source code contains
those 2 files).

Regards,
Pascal.

2009/1/8 Gerald Combs ger...@wireshark.org:
 Checked in in r27186. Sean, you'll have to get the sources from SVN or 
 download
 wireshark-1.0.6pre1-27186.tar.gz or later when it shows up at
 http://www.wireshark.org/download/prerelease/ in the next hour or so.

 Pascal Quantin wrote:
 Hi,

 I submitted a patch to Gerald allowing to build 1.0.X branch with
 VS2008 and VS2008EE. Wait for its delivery or switch to trunk in the
 meantime.

 Regards,
 Pascal.

 2009/1/7 Sean yun...@yahoo.com:
 After modifying from VS2008 PE to EE, the installer still doesn't work.
 Can anyone help me on this issue?
 Thanks a lot.


 --- On Tue, 1/6/09, Anders Broman a.bro...@telia.com wrote:

 From: Anders Broman a.bro...@telia.com
 Subject: SV: [Wireshark-dev] Package issue under Windows XP
 To: yun...@yahoo.com, 'Developer support list for Wireshark' 
 wireshark-dev@wireshark.org
 Date: Tuesday, January 6, 2009, 8:34 PM
 Hi,
 I think changes were made to make WS compile with
 VS2008/VS2008EE after
 branching of the 1.0.x branch. You are better of using
 trunk with VS2008.

 Regards
 Anders

 -Ursprungligt meddelande-
 Från: wireshark-dev-boun...@wireshark.org
 [mailto:wireshark-dev-boun...@wireshark.org] För Sean
 Skickat: den 5 januari 2009 05:36
 Till: Developer support list for Wireshark; Gerald Combs
 Ämne: Re: [Wireshark-dev] Package issue under Windows XP




 --- On Mon, 1/5/09, Gerald Combs
 ger...@wireshark.org wrote:

 From: Gerald Combs ger...@wireshark.org
 Subject: Re: [Wireshark-dev] Package issue under
 Windows XP
 To: yun...@yahoo.com, Developer support list for
 Wireshark
 wireshark-dev@wireshark.org
 Date: Monday, January 5, 2009, 10:54 AM
 Sean wrote:
 Greetings,

 I'm using source code of 1.0.4 to build
 package
 under windows XP,
 the compiler is Microsoft Visual Studio 2008
 Professional Edition,
 the config.nmake is configured to
 MSVC_VARIANT=MSVC2008EE,
 after compilation, the package is created
 successfully,
 but after installing on windows XP,
 the wireshark can't run successfully,
 following is the message:

 The application failed to initialize
 properly(0xc142). Click on OK to terminate the
 application.

 If you have Visual Studio 2008 Profesional Edition,
 you
 should set
 MSVC_VARIANT to MSVC2008 instead of MSVC2008EE (which
 is
 for the Express
 Edition). One of the key differences between the
 Express
 Editions of
 Visual Studio (and the reason we have different
 variant
 definitions) is
 that they don't come with package-able versions of
 the
 C and C++
 runtimes, while the full frontal editions
 do.
 Setting the variant to MSVC2008EE (or MSVC2005EE)
 means
 that the
 installer you create won't come with the C
 runtime, and
 assumes that
 you'll have Microsoft Visual C++ 2008 SP1
 Redistributable Package
 installed on the target machine.
 But it seems that the version 1.0.4 can't recognize
 MSVC2008 in
 config.nmake,
 how can I modify the config.nmake?
 should I modify other files for using MSVC 2008
 professional instead of MSVC
 2008 EE?
 Thank you very much.



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


 --
 Join us for Sharkfest'09  |  Stanford University, June 15 – 18
 http://www.cacetech.com/sharkfest.09/

 EARLY REGISTRATION DISCOUNTS through JANUARY 31, 2009
 ___
 Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org
 Archives:http://www.wireshark.org/lists/wireshark-dev
 Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ

Re: [Wireshark-dev] E212 Mobile network code is not caculated correctly?

[Pascal Quantin]

Hi,

you are right and this was fixed in trunk by revision 24759 (
http://anonsvn.wireshark.org/viewvc?view=revrevision=24759 ).

Regards,
Pascal.

2009/1/9 Zhang, Long (Roger) zha...@alcatel-lucent.com:
 Hi,



 I am developing based on Wireshark 1.0.0.  I found the mnc in E212 may not
 be caculated correctly.  The mnc for 3 digits is calculated as mnc += 10 *
 mnc + mnc3;. I think it should be mnc = 10 * mnc + mnc3;.  From E212
 spec, I did not find algorithm to calculate mnc, but I think += is not
 correct. Is it a bug?



 epan/dissectors/packet-e212.c



 int

 dissect_e212_mcc_mnc(tvbuff_t *tvb, proto_tree *tree, int offset){



 ……



 mcc = 100 * mcc1 + 10 * mcc2 + mcc3;

 mnc = 10 * mnc1 + mnc2;

 if (mnc3 != 0xf) {

 mnc += 10 * mnc + mnc3;

 }

 ……

 return offset;

 }



 Thanks,

 Roger

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

Re: [Wireshark-dev] MSVC variant problem in v1.0.5

[Pascal Quantin]

2009/1/30  gogr...@wi.rr.com:
 I'm trying to build wireshark v1.0.5. But i'm getting this error

 C:\wiresharknmake -f makefile.nmake setup

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

 config.nmake(439) : fatal error U1050: MSVC_VARIANT unknown
 Stop.

 in config.nmake i have the msvc set to MSVC_VARIANT=MSVC2008

Hi,
wireshark up to version 1.0.5 is built with MSVC6. MSVC 2008 is not supported.


 How do i get it to build / what's my problem?

Get the trunk-1.0 svn repository. A patch to allow MSVC2008 building
was delivered after 1.0.5 branching.

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

Re: [Wireshark-dev] MSVC variant problem in v1.0.5

[Pascal Quantin]

2009/1/30  gogr...@wi.rr.com:
 If I download the changed files would it be the same?
Yes, you can try this. The corresponding revisions are 27186
(http://anonsvn.wireshark.org/viewvc?view=revrevision=27186) and
27200 (http://anonsvn.wireshark.org/viewvc?view=revrevision=27200)

 Also, if I compile a custom dissector plugin, will it work with the official 
 1.0.5 version?
No, you will face the usual manifest/CRT version issues. It is better
to avoid mixing MSVC versions...



 -Original Message-
 From: wireshark-dev-boun...@wireshark.org 
 [mailto:wireshark-dev-boun...@wireshark.org] On Behalf Of Pascal Quantin
 Sent: Friday, January 30, 2009 10:09 AM
 To: Developer support list for Wireshark
 Subject: Re: [Wireshark-dev] MSVC variant problem in v1.0.5

 2009/1/30  gogr...@wi.rr.com:
 I'm trying to build wireshark v1.0.5. But i'm getting this error

 C:\wiresharknmake -f makefile.nmake setup

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

 config.nmake(439) : fatal error U1050: MSVC_VARIANT unknown
 Stop.

 in config.nmake i have the msvc set to MSVC_VARIANT=MSVC2008

 Hi,
 wireshark up to version 1.0.5 is built with MSVC6. MSVC 2008 is not supported.


 How do i get it to build / what's my problem?

 Get the trunk-1.0 svn repository. A patch to allow MSVC2008 building
 was delivered after 1.0.5 branching.

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

Re: [Wireshark-dev] MSVC variant problem in v1.0.5

[Pascal Quantin]

So far, 1.0.X versions are built with MSVC6 and 1.1.X are built with
MSVC2008. You have 2 solutions:
- build 2 versions of your plugin
- try to build your custom plugin with MSVC2008 and ensure you embed
the manifest and distribute the CRT dlls with it. It should work
(there is already an ongoing discussion on this topic on the mailing
list: http://www.wireshark.org/lists/wireshark-dev/200901/msg00155.html)

Pascal.

2009/1/30  gogr...@wi.rr.com:

 Damn. Well I'm creating a custom dissector plugin for my company, which they 
 will want to use in versions of wireshark to come. What would be the best 
 thing to do so that my plugin will be compatible across many of the release 
 versions?

 Greg

 -Original Message-
 From: wireshark-dev-boun...@wireshark.org 
 [mailto:wireshark-dev-boun...@wireshark.org] On Behalf Of Pascal Quantin
 Sent: Friday, January 30, 2009 10:18 AM
 To: Developer support list for Wireshark
 Subject: Re: [Wireshark-dev] MSVC variant problem in v1.0.5

 2009/1/30  gogr...@wi.rr.com:
 If I download the changed files would it be the same?
 Yes, you can try this. The corresponding revisions are 27186
 (http://anonsvn.wireshark.org/viewvc?view=revrevision=27186) and
 27200 (http://anonsvn.wireshark.org/viewvc?view=revrevision=27200)

 Also, if I compile a custom dissector plugin, will it work with the official 
 1.0.5 version?
 No, you will face the usual manifest/CRT version issues. It is better
 to avoid mixing MSVC versions...



 -Original Message-
 From: wireshark-dev-boun...@wireshark.org 
 [mailto:wireshark-dev-boun...@wireshark.org] On Behalf Of Pascal Quantin
 Sent: Friday, January 30, 2009 10:09 AM
 To: Developer support list for Wireshark
 Subject: Re: [Wireshark-dev] MSVC variant problem in v1.0.5

 2009/1/30  gogr...@wi.rr.com:
 I'm trying to build wireshark v1.0.5. But i'm getting this error

 C:\wiresharknmake -f makefile.nmake setup

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

 config.nmake(439) : fatal error U1050: MSVC_VARIANT unknown
 Stop.

 in config.nmake i have the msvc set to MSVC_VARIANT=MSVC2008

 Hi,
 wireshark up to version 1.0.5 is built with MSVC6. MSVC 2008 is not 
 supported.


 How do i get it to build / what's my problem?

 Get the trunk-1.0 svn repository. A patch to allow MSVC2008 building
 was delivered after 1.0.5 branching.

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

Re: [Wireshark-dev] MSVC variant problem in v1.0.5

[Pascal Quantin]

CRT files are the MS C runtimes libraries and are installed with MSVC.
You should ensure that your customer has those dlls installed so that
he can uses your plugin. That's why Microsoft provides free MSVC
runtimes installers. mt.exe is part of your MSVC installation and
allows to embed a manifest file in your dll (see Makefile.nmake files
for examples).

AFAIK next major Wireshark release (based on the 1.1.X source code) is
expected around June and should be built with MSVC2008 SP1. While
waiting for it, you can build your own installer. Once it is released,
you should be able to copy the dll in the official plugins directory.

Pascal.

2009/1/30  gogr...@wi.rr.com:
 Ahh alright. Well if wireshark is going towards MSVC2008, then I might as 
 well use that. I don't understand what these CRT dlls are and where I put 
 them though. Also, whats the mt.exe? Do i need to send out these CRT dll's if 
 everyone at the company has 2008? Also, do you think my best bet for 
 compatibility is to use the 1.1.* source and MSVC2008 to build my plugin, 
 then create an installer of my wireshark build to use until the stable 
 releases are in the  1.1.* where my plugin .dll and manifest files should 
 just be able to be copy pasted into the stable version?

 Thanks for all your help,

 Greg

 -Original Message-
 From: wireshark-dev-boun...@wireshark.org 
 [mailto:wireshark-dev-boun...@wireshark.org] On Behalf Of Pascal Quantin
 Sent: Friday, January 30, 2009 10:35 AM
 To: Developer support list for Wireshark
 Subject: Re: [Wireshark-dev] MSVC variant problem in v1.0.5

 So far, 1.0.X versions are built with MSVC6 and 1.1.X are built with 
 MSVC2008. You have 2 solutions:
 - build 2 versions of your plugin
 - try to build your custom plugin with MSVC2008 and ensure you embed the 
 manifest and distribute the CRT dlls with it. It should work (there is 
 already an ongoing discussion on this topic on the mailing
 list: http://www.wireshark.org/lists/wireshark-dev/200901/msg00155.html)

 Pascal.

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

Re: [Wireshark-dev] Win64 build support

[Pascal Quantin]

Hi Brian,

As stated here 
(http://www.wireshark.org/docs/wsdg_html_chunked/ChSetupWin32.html),
you need to install cygwin and python to be able to compile Wireshark
on your box. If you follow the guide, it will work flawlessly :)

Regards,
Pascal.

2009/3/17 Brian Daniel daniel_br...@colstate.edu:
 Thanks Gerald  Guy,

 Since http://buildbot.wireshark.org/trunk/waterfall shows green  yellow
 on wireshark win32 I've been downloading the latest svn compiled wireshark
 win32 once or twice a day for a few days now and they all seem really stable
 so far and even seems to be stable on my Windows Vista 64-bit. My attempts
 to compile win32 and win64 myself crashed and burned again.

 C:\wiresharkset WIRESHARK_TARGET_PLATFORM=win64
 C:\wiresharkset PLATFORM=win64
 C:\wiresharknmake -f Makefile.nmake distclean
 Microsoft (R) Program Maintenance Utility Version 9.00.30729.01
 Copyright (C) Microsoft Corporation.  All rights reserved.
     rm -rf wireshark-gtk2
 'rm' is not recognized as an internal or external command,
 operable program or batch file.
 NMAKE : fatal error U1077: 'rm' : return code '0x1'
 Stop.
 C:\wireshark

 I must be doing something really OS level dumb because, rm -rf (directory)
 is a linux command but I'm using XP Pro 32-bit to try and compile wireshark
 as win32 and win64.

 Thanks,
 Brian

 On Wed, Mar 11, 2009 at 5:40 PM, Brian Daniel daniel_br...@colstate.edu
 wrote:

 Cool thanks folks! Since
 http://buildbot.wireshark.org/trunk/waterfall shows failed on both wireshark
 win32 and win64, I'll hold off on my svn update until later tonight when
 both are green.
 On Wed, Mar 11, 2009 at 12:18 PM, Gerald Combs ger...@wireshark.org
 wrote:

 You should now, along with updating SVN. I just checked in a change to
 use
 WIRESHARK_TARGET_PLATFORM (note the fixed spelling) instead of PLATFORM.

 Config.nmake sets CPU according to WIRESHARK_TARGET_PLATFORM. You
 shouldn't have
 to set it yourself.

 Brian Daniel wrote:
  Yep, turns out I need to keep my setting: Platform=BPC
  Should I use WIRESHRK_TARGET_PLATFORM=win64 ??
  For now, I'll try to temporarily change to Platform=win32 or win64 each
  time I launch the cmd.exe
 
  Also, what CPU= should I put for my Intel Core2 Quad Q6600?
  x86 is a solution for a very old Intel CPU.
  Many Thanks,
  Brian
  On Tue, Mar 10, 2009 at 8:26 PM, Guy Harris g...@alum.mit.edu
  mailto:g...@alum.mit.edu wrote:
 
 
      On Mar 10, 2009, at 5:08 PM, Gerald Combs wrote:
 
       Should we use something more Wireshark-specific, e.g.
       WIRESHRK_TARGET_PLATFORM
       instead?
 
      That might work better.  When Googling for information about this I
      found at least a couple of instances of some annoying bit of
  software
      insisting on setting the PLATFORM environment variable to some
  silly
      string such as BPC or HPC and breaking MSVC++ builds, so if we can
      avoid depending on PLATFORM at all, that might at least keep us
  from
      getting hosed by those programs.
 
  ___
      Sent via:    Wireshark-dev mailing list
  wireshark-dev@wireshark.org
      mailto:wireshark-dev@wireshark.org
      Archives:    http://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 wireshark-dev@wireshark.org
  Archives:    http://www.wireshark.org/lists/wireshark-dev
  Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
 
   mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe


 --
 Join us for Sharkfest’09  |  Stanford University, June 15 – 18
 http://www.cacetech.com/sharkfest.09/

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

Re: [Wireshark-dev] Visual C++ 2008 EE

[Pascal Quantin]

Really ?

You will find all the relevant information here:
http://www.wireshark.org/docs/wsdg_html_chunked/ChSetupWin32.html#ChSetupMSVC
If you follow each step carefully, you will be able to compile the source
code.
Then to debug, you can follow those tips:
http://wiki.wireshark.org/Development/Tips

Regards,
Pascal.

2009/8/18 Ask Me sh4r...@gmail.com

 Hi,

 I read it already and the section where it describes how to set up the
 environment isn't written, that is why i asked the question here.

 On Mon, Aug 17, 2009 at 11:34 AM, Jaap Keuter jaap.keu...@xs4all.nlwrote:

 Hi,

 RTF Developer G. You can find it on the Wireshark website under Develop.

 Thanx,
 Jaap

 Sent from my iPhone

 On 17 aug 2009, at 10:22, Ask Me sh4r...@gmail.com wrote:

  Hi!
 
  I'm a newbie to wireshark and programming in general, so please have
  patience with me. I was wondering if any of you could explain how to
  set up a C++ enviroment(Micrsosoft Visual C++ 2008EE) so that i can
  use the internal debugger. I would appreciate step by step
  instrucions.
  Thank You
  Sigma
 
 ___


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

Re: [Wireshark-dev] Request

[Pascal Quantin]

Hi,

GAN (Generic Access Network) is the integration of UMA (Unlicensed Mobile
Access) in 3GPP specifications with only a few changes . UMA is already
supported in wireshark and you can easily add support for GAN messages by
modifying packet-uma.c file (even better, add a preference to switch between
GAN and UMA protocols).

Regards,
Pascal.

2009/10/6 Kovarththanan Rajaratnam kovarththanan.rajarat...@gmail.com

 Hey,

 BANDARU, Govindarao (Govindarao) wrote:
  Hi,
 
 I would like to know whether GAN (Generic Access Network) protocol is
  supported in Wireshark or not. Please let me know.

 Here's a list of supported protocols in Wireshark:

 http://www.wireshark.org/docs/dfref

 I don't see GAN anywhere.

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

[Wireshark-dev] win-setup.sh text mode

[Pascal Quantin]

Hi all,

since I updated my trunk tree to revision 31528, I cannot compile 
Wireshark on my Windows box (WinXP, MSVC2008SP1, cygwin 1.7.1). I get 
the following error:
C:\wireshark\trunknmake -f Makefile.nmake all

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

/cygdrive/c/wireshark/trunk2/tools/win-setup.sh: line 4: $'\r': command 
not found
/cygdrive/c/wireshark/trunk2/tools/win-setup.sh: line 12: $'\r': command 
not found
/cygdrive/c/wireshark/trunk2/tools/win-setup.sh: line 27: syntax error 
near unexpected token `$'{\r''
'cygdrive/c/wireshark/trunk2/tools/win-setup.sh: line 27: `err_exit () {
? Wireshark Libraries not up-to-date ?
? Do you need to run nmake -f Makefile.nmake setup ?

NMAKE : fatal error U1077: 'exit' : code retour '0x1'
Stop.

I get the same thing with a clean checkout.
I had to manually convert win-setup.sh file from dos encoding to unix 
encoding to get things working again. Is anyone else experiencing the 
same issue ?

Regards,
Pascal.

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

Re: [Wireshark-dev] win-setup.sh text mode

[Pascal Quantin]

Hi Gerald,

Le 15/01/2010 21:12, Gerald Combs a écrit :
 Pascal Quantin wrote:

 Hi all,

 since I updated my trunk tree to revision 31528, I cannot compile
 Wireshark on my Windows box (WinXP, MSVC2008SP1, cygwin 1.7.1). I get
 the following error:
 C:\wireshark\trunknmake -f Makefile.nmake all

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

 /cygdrive/c/wireshark/trunk2/tools/win-setup.sh: line 4: $'\r': command
 not found
 /cygdrive/c/wireshark/trunk2/tools/win-setup.sh: line 12: $'\r': command
 not found
 /cygdrive/c/wireshark/trunk2/tools/win-setup.sh: line 27: syntax error
 near unexpected token `$'{\r''
 'cygdrive/c/wireshark/trunk2/tools/win-setup.sh: line 27: `err_exit () {
 ? Wireshark Libraries not up-to-date ?
 ? Do you need to run nmake -f Makefile.nmake setup ?

 NMAKE : fatal error U1077: 'exit' : code retour '0x1'
 Stop.

 I get the same thing with a clean checkout.
 I had to manually convert win-setup.sh file from dos encoding to unix
 encoding to get things working again. Is anyone else experiencing the
 same issue ?
  
 That's my fault. I added the svn:executable and svn:eol-style properties
 to match win{32|64}-setup.sh. In theory they should all have identical
 line ending styles. If you remove tools/win*-setup.sh and update, what
 line ending style does each file have?

All of them have dos line ending. But only win-setup.sh raises an error 
when compiling.

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

Re: [Wireshark-dev] Small issue with Wireshark exe on windows

[Pascal Quantin]

Hi,

the file open window code got patched so as to be functional when compiled
with MSVC2005 or 2008. So you should backport this to you 1.0.10 tree.
BTW, you might face other issues (mostly related to DLLs dependencies and so
on). For example, the adns dll needed a patch to compile properly with
MSVC2005 or 2008.

As stated previously, the easiest way would be to a switch to a Wireshark
version that officially supports those microsoft compilers (like the 1.2
branch).

Regards,
Pascal.

2010/1/22 Varun Gupta varun.gu...@aricent.com

  Hi All,



 I have created a windows build of wireshark 1.0.10 on my windows XP using
 “VC++2005 EE”. I find 2 wireshark binaries under “wireshark-gtk1” and
 “wireshark-gtk2” folders.

 In the wireshark under the “wireshark-gtk2” folder, I cannot open the
 “file-open“ dialog box. On the other hand it opens with the “exe” present
 under “wireshark-gtk1”.

 Has anybody seen this problem, I need help on this.



 Thanks,

 Varun



 --
 DISCLAIMER: This message is proprietary to Aricent and is intended solely
 for the use of the individual to whom it is addressed. It may contain
 privileged or confidential information and should not be circulated or used
 for any purpose other than for what it is intended. If you have received
 this message in error, please notify the originator immediately. If you are
 not the intended recipient, you are notified that you are strictly
 prohibited from using, copying, altering, or disclosing the contents of this
 message. Aricent accepts no responsibility for loss or damage arising from
 the use of the information transmitted by this email including damage from
 virus.

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

Re: [Wireshark-dev] Small issue with Wireshark exe on windows

[Pascal Quantin]

Hi,

2010/1/28 Varun Gupta varun.gu...@aricent.com

  Hi All,



 Pascal, thanks for your info.



 As I told earlier on building wireshark on windows I get 2 wireshark exe’s,
 one on gtk1 and other on gtk2. My “file-open” works well with gtk1, so is
 there any way while doing packaging for wireshark setup I could use binary
 of gtk1 in my setup and avoid issue of file-open in gtk2 binary.



If this is the way to want to go, you should change the GTK_DIR variable in
config.nmake and then adapt the wireshark.nsi script located in
packaging/nsis directory till you get something working.
But as stated in config.nmake comments: Please note: Since Wireshark
release 1.0.0, we no longer support GTK1.x.
So it really looks like a dead end to me (hint: upgrade asap your source
code tree or install MSVC 6.0)

Pascal.

 Please help on this.



 Thanks,

 Varun
  --

 *From:* wireshark-dev-boun...@wireshark.org [mailto:
 wireshark-dev-boun...@wireshark.org] *On Behalf Of *Pascal Quantin
 *Sent:* Friday, January 22, 2010 4:31 PM
 *To:* Developer support list for Wireshark
 *Cc:* Sanjay Dhand
 *Subject:* Re: [Wireshark-dev] Small issue with Wireshark exe on windows



 Hi,

 the file open window code got patched so as to be functional when compiled
 with MSVC2005 or 2008. So you should backport this to you 1.0.10 tree.
 BTW, you might face other issues (mostly related to DLLs dependencies and
 so on). For example, the adns dll needed a patch to compile properly with
 MSVC2005 or 2008.

 As stated previously, the easiest way would be to a switch to a Wireshark
 version that officially supports those microsoft compilers (like the 1.2
 branch).

 Regards,
 Pascal.

 2010/1/22 Varun Gupta varun.gu...@aricent.com

 Hi All,



 I have created a windows build of wireshark 1.0.10 on my windows XP using
 “VC++2005 EE”. I find 2 wireshark binaries under “wireshark-gtk1” and
 “wireshark-gtk2” folders.

 In the wireshark under the “wireshark-gtk2” folder, I cannot open the
 “file-open“ dialog box. On the other hand it opens with the “exe” present
 under “wireshark-gtk1”.

 Has anybody seen this problem, I need help on this.



 Thanks,

 Varun




  --

 DISCLAIMER: This message is proprietary to Aricent and is intended solely
 for the use of the individual to whom it is addressed. It may contain
 privileged or confidential information and should not be circulated or used
 for any purpose other than for what it is intended. If you have received
 this message in error, please notify the originator immediately. If you are
 not the intended recipient, you are notified that you are strictly
 prohibited from using, copying, altering, or disclosing the contents of this
 message. Aricent accepts no responsibility for loss or damage arising from
 the use of the information transmitted by this email including damage from
 virus.


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



 --
 DISCLAIMER: This message is proprietary to Aricent and is intended solely
 for the use of the individual to whom it is addressed. It may contain
 privileged or confidential information and should not be circulated or used
 for any purpose other than for what it is intended. If you have received
 this message in error, please notify the originator immediately. If you are
 not the intended recipient, you are notified that you are strictly
 prohibited from using, copying, altering, or disclosing the contents of this
 message. Aricent accepts no responsibility for loss or damage arising from
 the use of the information transmitted by this email including damage from
 virus.

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

Re: [Wireshark-dev] [Wireshark-commits] rev 32006: /trunk/ /trunk/epan/: oids.c: Messages each time Wireshark/tshark started

[Pascal Quantin]

Hi

2010/2/26 Balint Reczey balint.rec...@ericsson.com

 Balint Reczey wrote:
  Balint Reczey wrote:
  Bill Meier wrote:
  Log:
   Prevent potential crash in libsmi.
   From: Vincent Bernat ber...@debian.org
  Since SVN #32006 was committed, the following messages appear when
  tshark and Wireshark are started.
 
  For Wireshark the messages appear as popup Windows which must be
  dismissed !!
 
  --
 
  tshark: Stopped processing module SNMP-COMMUNITY-MIB due to error(s) to
prevent potential crash in libsmi.
  Module's conformance level: 0.
  See details at:
 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=560325
 
  tshark: Stopped processing module SNMP-MPD-MIB due to error(s) to
  prevent potential crash in libsmi.
  Module's conformance level: 0.
  See details at:
 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=560325
 
  tshark: Stopped processing module SNMP-PROXY-MIB due to error(s) to
  prevent potential crash in libsmi.
  Module's conformance level: 0.
  See details at:
 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=560325
 
  --
 
 
  Needing to dismiss popup windows each time Wireshark is started is
  obviously a non-starter.   :)
 
  So; What should be done ??  (I know zilch about SNMP MIBS).
 
  Bill
  I wanted to commit the attached patch, but I realized, that preferences
  are read _after_ loading the SMI modules. :-(
 
  Could we read prefs earlier, maybe twice?
 
  Cheers,
  Balint
 
 
  I also asked Vincent about a potentially better workaround [1].
  We can remove the buggy(?) MIBs from the default list of MIBs to be
  loaded, but it would not help users with older preferences file. :-(
 
  I can turn the popup to a debug message, but silently skipping the
  modules does not seem to be a good idea.
 
  Cheers,
  Balint
 
  [1]http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=560325
 
 
 
 I've committed a refinement to the workaround based on Vincent's email
 [1] in 32017.


It seems to be working fine on Linux but on Windows I still get a popup when
launching wireshark or the following text when launching tshark (SVN
revision 32067):

tshark: Stopped processing module SNMPv2-SMI due to error(s) to prevent
potential crash in libsmi.
Module's conformance level: 1.
See details at: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=560325

Is it a known issue ? Can something be done for us poor Windows user ? ;)

Regards,
Pascal.


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

Re: [Wireshark-dev] [Wireshark-commits] rev 32006: /trunk/ /trunk/epan/: oids.c: Messages each time Wireshark/tshark started

[Pascal Quantin]

Hi,

2010/3/2 Balint Reczey balint.rec...@ericsson.com

 Hi Pascal,

 It seems that libsmi 0.4.8 is more picky than 0.4.7 I tested my patch
 with. :-(
 I plan to remove the workaround from Wireshark as it makes more problems
 than it solves.
 It means that https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=4174
 will remain open.

 Any objections?

 Cheers,
 Balint


As far as I'm concerned, I see no objections (but as I'm not using SNMP at
all...).

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

Re: [Wireshark-dev] trunk-1.0 fails to compile on Windows with VS2008EE

[Pascal Quantin]

Hi

2010/5/19 Maynard, Chris christopher.mayn...@gtech.com

  As the subject line indicates, trunk-1.0 fails to compile on Windows with
 VS2008EE.

 The error log is attached.

 VS2008EE compilation was added in wireshark 1.2. That's why. If really
needed, you can try to backport the patchs attached (or check the comments
for the corresponding svn revisions) to bugs 2719, 2075, 2940. But you will
probably face other issues.

Regards,
Pascal.



 - Chris



 CONFIDENTIALITY NOTICE: The contents of this email are confidential
 and for the exclusive use of the intended recipient. If you receive this
 email in error, please delete it from your system immediately and
 notify us either by email, telephone or fax. You should not copy,
 forward, or otherwise disclose the content of the email.


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

Re: [Wireshark-dev] Dissection of LTE-RRC

[Pascal Quantin]

Hi,

Le 31 août 2010 à 09:38, Vishal Kumar Singh vishal.is...@gmail.com a écrit :

 Hi All,
 
 I have been trying to make RRC Dissector using the source code available at 
 http://anonsvn.wireshark.org/viewvc/trunk-1.4/epan/dissectors/. 
 
 Simply, I am trying to build a library in any directory. After that, I copy 
 the library to the plugin directory of wireshark. When I run wireshark and 
 send some packets,  I get DL CCCH message only, proto_register_protocol 
 invokes only dissect_lte_rrc_DL_CCCH_Message Function. I made a simple 
 change to meet my motive. Instead, I invoked   dissect_lte_rrc_Message, 
 which further calls dissector function for DL CCCH, UL CCCH, UL DCCH etc.  
 But, now i have to make a decision based on which only one of all is called. 
 Presently, when all the three dissector function is invoked.

Why creating a plugin based on the existing dissector instead of using the 
dissector itself ?

 
 Please, suggest me a suitable method to this. Can i select based on message 
 type to differentiate UL CCCH, UL DCCH, DL CCCH messages? Or, is there any 
 other method to differentiate the messages?

No you can't differenciate the different logical channels (UL/DL CCCH/DCCH, 
PCCH, ...) automatically. You need to know what kind of packets you are trying 
to dissect and call the corresponding dissector accordingly.

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

[Wireshark-dev] SVN revision 36640 and heuristic dissectors

[Pascal Quantin]

Hi,

since revision 34640, none of UDP heuristic dissectors I use (LTE-MAC,
LTE-RLC or LTE-PDCP) work: all the frames are decoded as ADwin configuration
protocol.

When looking at the code in function dissect_adwin_config() (file
packet-adwin-config.c), the heuristic seems a bit weak:
[...]
length = tvb_reported_length(tvb);

if (pinfo-ipproto == IP_PROTO_UDP 
! (length == UDPStatusLENGTH
   || length == UDPExtStatusLENGTH
   || length == UDPMessageLENGTH
   || length == UDPMessageLENGTH_wrong
   || length == UDPInitAckLENGTH
   || length == UDPIXP425FlashUpdateLENGTH
   || length == UDPOutLENGTH))
return (0);
[...]

Could it be possible to do something more robust ?

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

Re: [Wireshark-dev] SVN revision 34640 and heuristic dissectors

[Pascal Quantin]

Hi,

2010/10/25 Jeff Morriss jeff.morriss...@gmail.com

 Pascal Quantin wrote:
  Hi,
 
  since revision 34640, none of UDP heuristic dissectors I use (LTE-MAC,
  LTE-RLC or LTE-PDCP) work: all the frames are decoded as ADwin
  configuration protocol.
 
  When looking at the code in function dissect_adwin_config() (file
  packet-adwin-config.c), the heuristic seems a bit weak:
  [...]
  length = tvb_reported_length(tvb);
 
  if (pinfo-ipproto == IP_PROTO_UDP 
  ! (length == UDPStatusLENGTH
 || length == UDPExtStatusLENGTH
 || length == UDPMessageLENGTH
 || length == UDPMessageLENGTH_wrong
 || length == UDPInitAckLENGTH
 || length == UDPIXP425FlashUpdateLENGTH
 || length == UDPOutLENGTH))
  return (0);
  [...]
 
  Could it be possible to do something more robust ?

 Oops, sorry.  We're discussing some stronger heuristics in bug 5324.


While you iterate on it, would it be possible to add a preference (off by
default) stating whether the ADwin heuristic dissectors are activated or not
(like what is done in packet-mac-lte.c for example) ?

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

Re: [Wireshark-dev] SVN revision 34640 and heuristic dissectors

[Pascal Quantin]

Hi

2010/10/25 Pascal Quantin pascal.quan...@gmail.com

 Hi,

 2010/10/25 Jeff Morriss jeff.morriss...@gmail.com

 Pascal Quantin wrote:
  Hi,
 
  since revision 34640, none of UDP heuristic dissectors I use (LTE-MAC,
  LTE-RLC or LTE-PDCP) work: all the frames are decoded as ADwin
  configuration protocol.
 
  When looking at the code in function dissect_adwin_config() (file
  packet-adwin-config.c), the heuristic seems a bit weak:
  [...]
  length = tvb_reported_length(tvb);
 
  if (pinfo-ipproto == IP_PROTO_UDP 
  ! (length == UDPStatusLENGTH
 || length == UDPExtStatusLENGTH
 || length == UDPMessageLENGTH
 || length == UDPMessageLENGTH_wrong
 || length == UDPInitAckLENGTH
 || length == UDPIXP425FlashUpdateLENGTH
 || length == UDPOutLENGTH))
  return (0);
  [...]
 
  Could it be possible to do something more robust ?

 Oops, sorry.  We're discussing some stronger heuristics in bug 5324.


 While you iterate on it, would it be possible to add a preference (off by
 default) stating whether the ADwin heuristic dissectors are activated or not
 (like what is done in packet-mac-lte.c for example) ?


Having a second look at the code, it's even worse than what I first thought.
Any pinfo-ipproto different from IP_PROTO_UDP or IP_PROTO_TCP will be
intercepted by the ADwin dissector.

Adding something like:

if (pinfo-ipproto != IP_PROTO_UDP  pinfo-ipproto != IP_PROTO_TCP)
return (0);

Solved the issue on my side.

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

Re: [Wireshark-dev] [Wireshark-commits] rev 34860: /trunk/gtk/ /trunk/gtk/: text_import.c

[Pascal Quantin]

Hi

2010/11/13 Jaap Keuter jaap.keu...@xs4all.nl

 Hi,

 That seems to be the result of the flex version being used. What platform
 are
 you using? We'll probably need to take a step back and rework using older
 mechanisms.


I'm facing the same issue with my Debian Lenny. Updating my flex version to
2.5.35 did not solve the issue.

Regards,
Pascal.



 Thanks,
 Jaap

 On 11/13/2010 05:06 PM, Martin Mathieson wrote:
  This still doesn't fix the build for me.
  There is an undefined reference to text_importset_in() in
  gtk/file_import_dlg.c:504
 
  Martin
 
  On Sat, Nov 13, 2010 at 4:04 PM, mart...@wireshark.org
  mailto:mart...@wireshark.org wrote:
 
 
 http://anonsvn.wireshark.org/viewvc/viewvc.cgi?view=revrevision=34860
  
 http://anonsvn.wireshark.org/viewvc/viewvc.cgi?view=revrevision=34860
 
  User: martinm
  Date: 2010/11/13 08:04 AM
 
  Log:
Add newline at end of file.
 
  Directory: /trunk/gtk/
ChangesPath Action
+1 -1  text_import.cModified
 
 
 ___
  Sent via:Wireshark-commits mailing list

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

Re: [Wireshark-dev] [Wireshark-commits] rev 34860: /trunk/gtk/ /trunk/gtk/: text_import.c

[Pascal Quantin]

Hi

2010/11/15 Jaap Keuter jaap.keu...@xs4all.nl

 Hi,

 I hear you. I'm already taking that step back, first of all splitting
 text_import.h and working without this access function so gracefully
 provided by newer flex versions.

 On that matter, AFAIK your version should provide this function. Can you
 have a look at text2pcap.c for instance? That should have the function
 yyset_in().

It looks like I forgot to clean my objects after upgrading flex... Sorry for
the false alarm.Now I have the following error when compiling svn revision
34872:

gcc -DHAVE_CONFIG_H -I. -I..  -I.. -I../wiretap-I/usr/local/include -I
/home/pascal/soft/include
'-DPLUGIN_DIR=/usr/local/lib/wireshark/plugins/1.5.0' -Werror -DINET6
-D_U_=__attribute__((unused)) -g -O2 -Wall -W -Wextra
-Wdeclaration-after-statement -Wendif-labels -Wpointer-arith
-Wno-pointer-sign -Warray-bounds -Wcast-align -Wformat-security
-I/usr/local/include -D_REENTRANT -pthread -I/usr/include/gtk-2.0
-I/usr/lib/gtk-2.0/include -I/usr/include/atk-1.0 -I/usr/include/cairo
-I/usr/include/pango-1.0 -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include
-I/usr/include/freetype2 -I/usr/include/directfb -I/usr/include/libpng12
-I/usr/include/pixman-1   -I /home/pascal/soft/include  -MT
text_import_scanner.o -MD -MP -MF .deps/text_import_scanner.Tpo -c -o
text_import_scanner.o text_import_scanner.c
cc1: warnings being treated as errors
text_import_scanner.c: In function 'yy_get_next_buffer':
text_import_scanner.c:1121: error: comparison between signed and unsigned
make[2]: *** [text_import_scanner.o] Error 1

My test2pcap.c file does not contain any yyset_in() function.

BTW, I have no issue when using a Unbuntu 10.10 or Windows. Only with my
Debian...

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

[Wireshark-dev] SVN revision 35005 and heuristic dissectors

[Pascal Quantin]

Hi,

since revision 35005 and the commit of the ReLOAD framing dissector the UDP
heuristic dissector I use (LTE-RLC) no longer works. My RLC PDU is seen as a
ReLOAD packet.

When looking at the code, the function dissect_reload_framing_heur() calls
dissect_reload_framing_message() that does almost no checks:

  /* First, make sure we have enough data to do the check. */
  if (effective_length  MIN_HDR_LENGTH)
return 0;

  /* Get the type */
  type = tvb_get_guint8(tvb, 0);

  if (type == DATA) {
/* in the data type, check the reload token to be sure this
   is a reLoad packet */
message_length = (tvb_get_ntohs(tvb, 1 + 4)8)+ tvb_get_guint8(tvb, 1 +
4 + 2);
if (message_length  MIN_RELOADDATA_HDR_LENGTH) {
  return 0;
}
relo_token = tvb_get_ntohl(tvb,1 + 4 + 3);
if (relo_token != RELOAD_TOKEN) {
  return 0;
}
  }

The LTE-RLC heuristic dissector adds the rlc-lte string at the beginning
of the UDP packet and unfortunately it is caught by the code above.

I'm not familiar with this protocol but I guess there is probably a way to
avoid breaking other dissectors. Adding the following patch helps on my side
but I'm not sure it is fully valid and it still seems weak to me:

Index: epan/dissectors/packet-reload-framing.c
===
--- epan/dissectors/packet-reload-framing.c(revision 35018)
+++ epan/dissectors/packet-reload-framing.c(working copy)
@@ -143,9 +143,10 @@
 if (relo_token != RELOAD_TOKEN) {
   return 0;
 }
+  } else if (type != ACK) {
+return 0;
   }

-
   /* The message seems to be a valid reLOAD framing message! */

   col_set_str(pinfo-cinfo, COL_PROTOCOL, RELOAD Frame);



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

Re: [Wireshark-dev] SVN revision 35005 and heuristic dissectors

[Pascal Quantin]

Hi Anders,

Le 24/11/2010 17:39, Anders Broman a écrit :
 Hi,
 Does it work better with revision 35020 or later?
It's working fine now.

Thanks,
Pascal.

 Regards
 Anders

 
 *From:* wireshark-dev-boun...@wireshark.org
 [mailto:wireshark-dev-boun...@wireshark.org] *On Behalf Of *Pascal Quantin
 *Sent:* den 24 november 2010 09:04
 *To:* Developer support list for Wireshark
 *Subject:* [Wireshark-dev] SVN revision 35005 and heuristic dissectors

 Hi,

 since revision 35005 and the commit of the ReLOAD framing dissector
 the UDP heuristic dissector I use (LTE-RLC) no longer works. My RLC
 PDU is seen as a ReLOAD packet.

 When looking at the code, the function dissect_reload_framing_heur()
 calls dissect_reload_framing_message() that does almost no checks:

   /* First, make sure we have enough data to do the check. */
   if (effective_length  MIN_HDR_LENGTH)
 return 0;

   /* Get the type */
   type = tvb_get_guint8(tvb, 0);

   if (type == DATA) {
 /* in the data type, check the reload token to be sure this
is a reLoad packet */
 message_length = (tvb_get_ntohs(tvb, 1 + 4)8)+
 tvb_get_guint8(tvb, 1 + 4 + 2);
 if (message_length  MIN_RELOADDATA_HDR_LENGTH) {
   return 0;
 }
 relo_token = tvb_get_ntohl(tvb,1 + 4 + 3);
 if (relo_token != RELOAD_TOKEN) {
   return 0;
 }
   }

 The LTE-RLC heuristic dissector adds the rlc-lte string at the
 beginning of the UDP packet and unfortunately it is caught by the code
 above.

 I'm not familiar with this protocol but I guess there is probably a
 way to avoid breaking other dissectors. Adding the following patch
 helps on my side but I'm not sure it is fully valid and it still seems
 weak to me:

 Index: epan/dissectors/packet-reload-framing.c
 ===
 --- epan/dissectors/packet-reload-framing.c(revision 35018)
 +++ epan/dissectors/packet-reload-framing.c(working copy)
 @@ -143,9 +143,10 @@
  if (relo_token != RELOAD_TOKEN) {
return 0;
  }
 +  } else if (type != ACK) {
 +return 0;
}
  
 -
/* The message seems to be a valid reLOAD framing message! */
  
col_set_str(pinfo-cinfo, COL_PROTOCOL, RELOAD Frame);



 Thanks,
 Pascal.


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

Re: [Wireshark-dev] Staus of ASN.1 dissectors - RRC and NAS-EPS (for LTE)

[Pascal Quantin]

Hi,

2011/2/18 Karl-Heinz ECKSTEIN karl-heinz.eckst...@stericsson.com

 Hello Vincent,

 Hello Anders,



 It looks like we all have a common mother!  J Interesting!

 Many thanks for your hints!

 Right now have the problem, that we receive a crash on wireshark, when we
 open the pcap file including one NAS-EPS(LTE) message.

 The error message tells us:  “Runtime Error! – Program: C:\Program
 Files\Wireshark\wireshark.exe – This application has requested the Runtime
 to terminate it in an unusual way. Please contact the application support
 team for more information.”



 What we have done before?

 We “captured” a NAS (LTE) message outside of wireshark. This message was
 just extracted from a trace line, we receive from LTE platform (UE). This
 NAS message is expected to be correct.

 Then we translated this text line (adding  a ‘00’ in front of the NAS
 message) to pcap format. We use the command:

 c:\Program Files\Wireshark\text2pcap.exe -l 147 NAS_message_test_6.txt
 NAS_message_test_6.pcap

 We use a preference setup for the User 0 (DLT-147) and reference to
 protocol NAS-EPS in wireshark. (User 0 (DLT=147), NAS-EPS,0,””’,0,””

When we start wireshark, we crash.



 Do we something wrong, or could it be an error?


You must use nas-eps and not NAS-EPS. That's why Wireshark crashes.
Moreover the pcap you generated is not correct:
  07 41 71 08 29 26 08 30  00 00 00 04 05 80 c0 00
0010  00 00 00 04 02 01 d0
It lacks the last byte (11), leading to a decoding error.

Regards,
Pascal.




 Many thanks!





 Best regards
 *Karl Heinz Eckstein*









 *From:* wireshark-dev-boun...@wireshark.org [mailto:
 wireshark-dev-boun...@wireshark.org] *On Behalf Of *Anders Broman
 *Sent:* Donnerstag, 17. Februar 2011 18:45
 *To:* Developer support list for Wireshark
 *Subject:* Re: [Wireshark-dev] Staus of ASN.1 dissectors - RRC and NAS-EPS
 (for LTE)



 Hi,

 Both the NAS-EPS dissector and the LTE-RRC dissector are fairly well
 updated however you need to call them by using a User DLT

 or something like that.

 Regards

 Anders


 --

 *From:* wireshark-dev-boun...@wireshark.org [mailto:
 wireshark-dev-boun...@wireshark.org] *On Behalf Of *Karl-Heinz ECKSTEIN
 *Sent:* den 17 februari 2011 18:00
 *To:* wireshark-dev@wireshark.org
 *Subject:* [Wireshark-dev] Staus of ASN.1 dissectors - RRC and NAS-EPS
 (for LTE)

 Hello,

 May I ask, which status is applicable on ASN.1, especially dissector of RRC
 and NAS-EPS.

 I’m asking, because I’m trying to dissector a pcap file, which I had
 generated via text2pcap from a LTE NAS message.

 The NAS message is not “decoded”/dissectored by wireshark in my example.
 But NAS-EPS is available in Filters but not in preferences.

 I’m using latest 1.5.1 build.



 Many thanks for any help about this.

 Best regards

 *Karl Heinz Eckstein*



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

Re: [Wireshark-dev] Staus of ASN.1 dissectors - RRC and NAS-EPS (for LTE)

[Pascal Quantin]

Hi,

2011/2/18 Anders Broman anders.bro...@ericsson.com

  Hi,
 WS does not crash for me Version 1.5.1 (SVN Rev 35978 from /trunk) it's
 malformed. I can see that the packet is ony byte short
 compared with the text version. Probably a fault in text2pcap. You can try
 the new feature to import text imput from the GUI
 File-import.
 text2pacap might work better if you have the trailing ... there , like
    07 41 71 08 29 26 08 30 00 00 00 04 05 80 c0 00  .Aq.).0
 0010   00 00 00 04 02 01
 d0   ...


The crash is due to the capital letters (NAS-EPS instead of nas-eps) in the
DLT_USER configuration (at least it is how it behaves on my linux machine).

Regards,
Pascal.


 Or add an extra 00
 I've included the fixed .pcap
 Regards
 Anders

  --
 *From:* Karl-Heinz ECKSTEIN [mailto:karl-heinz.eckst...@stericsson.com]
 *Sent:* den 18 februari 2011 11:17

 *To:* Developer support list for Wireshark
 *Cc:* Vincent HELFRE ; Anders Broman; Fatih ARDIC ; Karl-Heinz ECKSTEIN
 *Subject:* RE: [Wireshark-dev] Staus of ASN.1 dissectors - RRC and NAS-EPS
 (for LTE)

  Hello Vincent,

 Hello Anders,



 It looks like we all have a common mother!  J Interesting!

 Many thanks for your hints!

 Right now have the problem, that we receive a crash on wireshark, when we
 open the pcap file including one NAS-EPS(LTE) message.

 The error message tells us:  “Runtime Error! – Program: C:\Program
 Files\Wireshark\wireshark.exe – This application has requested the Runtime
 to terminate it in an unusual way. Please contact the application support
 team for more information.”



 What we have done before?

 We “captured” a NAS (LTE) message outside of wireshark. This message was
 just extracted from a trace line, we receive from LTE platform (UE). This
 NAS message is expected to be correct.

 Then we translated this text line (adding  a ‘00’ in front of the NAS
 message) to pcap format. We use the command:

 c:\Program Files\Wireshark\text2pcap.exe -l 147 NAS_message_test_6.txt
 NAS_message_test_6.pcap

 We use a preference setup for the User 0 (DLT-147) and reference to
 protocol NAS-EPS in wireshark. (User 0 (DLT=147), NAS-EPS,0,””’,0,””

 When we start wireshark, we crash.



 Do we something wrong, or could it be an error?



 Many thanks!





 Best regards
 *Karl Heinz Eckstein*









 *From:* wireshark-dev-boun...@wireshark.org [mailto:
 wireshark-dev-boun...@wireshark.org] *On Behalf Of *Anders Broman
 *Sent:* Donnerstag, 17. Februar 2011 18:45
 *To:* Developer support list for Wireshark
 *Subject:* Re: [Wireshark-dev] Staus of ASN.1 dissectors - RRC and NAS-EPS
 (for LTE)



 Hi,

 Both the NAS-EPS dissector and the LTE-RRC dissector are fairly well
 updated however you need to call them by using a User DLT

 or something like that.

 Regards

 Anders


  --

 *From:* wireshark-dev-boun...@wireshark.org [mailto:
 wireshark-dev-boun...@wireshark.org] *On Behalf Of *Karl-Heinz ECKSTEIN
 *Sent:* den 17 februari 2011 18:00
 *To:* wireshark-dev@wireshark.org
 *Subject:* [Wireshark-dev] Staus of ASN.1 dissectors - RRC and NAS-EPS
 (for LTE)

 Hello,

 May I ask, which status is applicable on ASN.1, especially dissector of RRC
 and NAS-EPS.

 I’m asking, because I’m trying to dissector a pcap file, which I had
 generated via text2pcap from a LTE NAS message.

 The NAS message is not “decoded”/dissectored by wireshark in my example.
 But NAS-EPS is available in Filters but not in preferences.

 I’m using latest 1.5.1 build.



 Many thanks for any help about this.

 Best regards

 *Karl Heinz Eckstein*



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

Re: [Wireshark-dev] SVN revision 36552 on Debian Lenny and gzopen64 function

[Pascal Quantin]

Hi Guy,

2011/4/11 Guy Harris g...@alum.mit.edu


 On Apr 11, 2011, at 9:12 AM, Guy Harris wrote:

  I'll look at getting rid of the use of the zlib gz* routines for output
 (just as we've done for input), so that we're not hosed by whatever
 bogosities particular versions of zlib have in their large file support.

 Done, as of revision 36563.  See whether that builds (it builds on OS X,
 but big deal - OS X is a 4.4-Lite-derived OS, so it's had a 64-bit off_t,
 regardless of the size of long, since Day One, and I'm building it on Snow
 Leopard on a Core 2 machine so it's building 64-bit by default anyway).


It works fine now.

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

[Wireshark-dev] SVN revision 36849 crashing in packet_range_init function

[Pascal Quantin]

Hi,

with revision 36849, when I call tshark to decode in verbose mode a pcap
file containing a single packet I get the following backtrace:

tshark -r temp.pcap -V

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0xb571c8e0 (LWP 11951)]
packet_range_init (range=0xbfd9f550) at packet-range.c:88
88  if (packet-flags.passed_dfilter) {
(gdb) bt
#0  packet_range_init (range=0xbfd9f550) at packet-range.c:88
#1  0x0806bac6 in print_packet (cf=0x80a5d40, edt=0xbfd9f5f8) at
tshark.c:3239
#2  0x0806c395 in process_packet (cf=0x80a5d40, offset=value optimized
out, whdr=0x9125f40, pseudo_header=0x9125f54, pd=0x912b730
h\022\230\b��\001\203��s?E��+\230!Ll�,
filtering_tap_listeners=0, tap_flags=value optimized out) at
tshark.c:2905
#3  0x0806f4ea in main (argc=4, argv=0xbfd9fc84) at tshark.c:2705

When launching tshark without the verbose flag, the crash is not seen.

When looking at the revision log, I can see that the code was changed from:

for(packet = cfile.plist_start; packet != NULL; packet = packet-next) {

to

for(framenum = 1; framenum = cfile.count; framenum++) {
   packet = cap_file_find_fdata(cfile, framenum);

In my use case, packet is set to NULL, leading to the segmentation fault.

When looking at tshark.c source code, I can see that process_packet() does
not call cap_file_add_fdata() while process_packet_first_pass() does. As a
consequence the cf-ptree_root pointer is not allocated and the call to
cap_file_find_fdata() will provide an uninitialized address.

The following patch solves my crash:

Index: tshark.c
===
--- tshark.c(revision 36849)
+++ tshark.c(working copy)
@@ -2830,9 +2830,6 @@
   epan_dissect_t edt;
   gboolean passed;

-  /* Count this packet. */
-  cf-count++;
-
   /* If we're not running a display filter and we're not printing any
  packet information, we don't need to do a dissection. This means
  that all packets can be marked as 'passed'. */
@@ -2896,6 +2893,7 @@

   if (passed) {
 frame_data_set_after_dissect(fdata, cum_bytes, prev_dis_ts);
+cap_file_add_fdata(cf, fdata);

 /* Process this packet. */
 if (print_packet_info) {

But I'm not sure this is the right way to fix this. Can someone comment ?

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

[Wireshark-dev] text2pcap regression starting from revision 38679

[Pascal Quantin]

Hi all,

since the commit for bug 1723 (done in revision 38679), I'm facing issues
with text2pcap for really small packet dumps.

Let's take this simple file example:
 30 00 20

By executing the following command line:
text2pcap.exe -q -l 162 temp.txt temp.pcap

I get the following binary pcap file:
: D4 C3 B2 A1 02 00 04 00 00 00 00 00 00 00 00 00
0010: 00 90 01 00 A2 00 00 00

As you can see, the packet is not included in the pcap file and if I open it
in Wireshark no packet is displayed.

Adding explicit ASCII string (so as to follow more closely the usual
text2pcap input format) after the bytes does not help either:
 30 00 20  ...

When I use Wireshark version 38678, I get the following binary pcap:
: D4 C3 B2 A1 02 00 04 00 00 00 00 00 00 00 00 00
0010: 00 90 01 00 A2 00 00 00 7F 67 56 4E 00 00 00 00
0020: 03 00 00 00 03 00 00 00 30 00 20
and everything works fine.

I guess this is unexpected behavior and should be considered as a bug. Do
you agree ?

Unfortunately I do not have the time to look at the text2pcap.c changes
right now, so any help is welcome.

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

Re: [Wireshark-dev] text2pcap regression starting from revision 38679

[Pascal Quantin]

Hi

2011/8/25 Pascal Quantin pascal.quan...@gmail.com

 Hi all,

 since the commit for bug 1723 (done in revision 38679), I'm facing issues
 with text2pcap for really small packet dumps.

 Let's take this simple file example:
  30 00 20

 By executing the following command line:
 text2pcap.exe -q -l 162 temp.txt temp.pcap

 I get the following binary pcap file:
 : D4 C3 B2 A1 02 00 04 00 00 00 00 00 00 00 00 00
 0010: 00 90 01 00 A2 00 00 00

 As you can see, the packet is not included in the pcap file and if I open
 it in Wireshark no packet is displayed.

 Adding explicit ASCII string (so as to follow more closely the usual
 text2pcap input format) after the bytes does not help either:
  30 00 20  ...

 When I use Wireshark version 38678, I get the following binary pcap:
 : D4 C3 B2 A1 02 00 04 00 00 00 00 00 00 00 00 00
 0010: 00 90 01 00 A2 00 00 00 7F 67 56 4E 00 00 00 00
 0020: 03 00 00 00 03 00 00 00 30 00 20
 and everything works fine.

 I guess this is unexpected behavior and should be considered as a bug. Do
 you agree ?

 Unfortunately I do not have the time to look at the text2pcap.c changes
 right now, so any help is welcome.

 Regards
 Pascal.


I started looking at the code change done by Chris Maynard and it fails with
my sample because it tries to compare the not present ASCII string with the
HEX string (so as to avoid taking a beginning of the ASCII string as part of
the HEX string, as explained in bug 1723).
Is the ASCII dump mandatory in the text2pcap input file format ? The
text2pcap help file is not very clear concerning this point and I assumed
that appending ASCII output was optional (as it was working previously). So
should I explicitly add it ?

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

Re: [Wireshark-dev] text2pcap regression starting from revision 38679

[Pascal Quantin]

Hi,

2011/8/26 Chris Maynard chris.mayn...@gtech.com

 Pascal Quantin pascal.quantin@... writes:

  Hi all,since the commit for bug 1723 (done in revision 38679), I'm facing
 issues with text2pcap for really small packet dumps.
 
  I guess this is unexpected behavior and should be considered as a bug. Do
 you
 agree ?

 I do and have reopened bug 1723 as a result.  Hopefully, the author of the
 text2pcap patch submitted in that bug report is able to fix it.


In the meantime I submitted a patch in bug 1723 activating the ASCII text
dump identification if a new -a option is given to the command line (as the
new code always assume that the ASCII text dump is present).
It would be nice if one of you could have a look (as text2pcap current
behavior is considered as buggy).

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

Re: [Wireshark-dev] Win32 build from 1.6.3 source tarball: svnversion.h missing and not generated?

[Pascal Quantin]

2011/11/17 Gerald Combs ger...@wireshark.org

 On 11/3/11 2:52 PM, Jeff Morriss wrote:
  Guy Harris wrote:
  On Nov 2, 2011, at 11:19 AM, Guy Harris wrote:
 
  On Nov 2, 2011, at 10:26 AM, Guy Harris wrote:
 
  On Nov 2, 2011, at 10:16 AM, Jeff Morriss wrote:
 
  Oh, shoot.  Looks like svnversion.h is removed by clean and/or
  dist-clean.
  So it should be generated only if you're building from SVN, and
  should be included in source tarballs, and should be removed only by
  maintainer-clean.
  I've checked in a change to do that, and will schedule it for the
  next 1.4.x and 1.6.x release, unless somebody can come up with a good
  reason to remove svnversion.h with clean or dist-clean.  Speak up
  soon
 
  Well, the build is failing because make distclean isn't getting rid
  of it.
 
  To quote the automake manual:
 
  * Distributed files should never depend upon non-distributed built
  files.
  * Distributed files should be distributed with all their
  dependencies.
  * If a file is intended to be rebuilt by users, then there is no
  point in distributing it.
 
  svnversion.h is made by make-version.pl, and to get the SVN version
  you presumably have to be in an SVN tree, so svnversion.h's
  dependency is on, in a sense, .svn and its contents, so, from what
  the automake manual says, if we ship svnversion.h, we have to ship the
  .svn tree as well.
 
  I don't think we want to do that.
 
  So, either
 
  1) we need to arrange to define HAVE_SVNVERSION_H if building from
  SVN, *not* define it if building from a release tarball, protect the
  includes of svnversion.h with #ifdef HAVE_SVNVERSION_H/#endif;
 
  2) we need to have make-version.pl work when run from a source
  tarball, for some reasonable definition of work;
 
  and, in either case, not distribute svnversion.h with the tarball and
  remove svnversion.h with make distclean.
 
  So here are (I think) the scenarios we're trying to cover:
 
  a) Builds from SVN (typically on trunk/ but also the release trunks):
  the exact SVN version is useful to know and the file can easily be made.
   Easy.
 
  b) Release source tarballs: the exact SVN version is not very important
  (the version is the version is the version) and the file can't be
  generated (by the user).  And automake won't let us deliver it because
  the file is generated.
 
  c) Daily build source tarballs: the exact SVN version *is* interesting
  (it's nice to know that, for example, the thousands of SVN versions
  between when 1.6.0 was released and when 1.7.0 will be released are not
  all, in fact, 1.7.0--remember the sunfreeware.com incident[1]?) but we
  have the same problems as (b).
 
  [1] https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=1413#c8
 
  Unfortunately both options above mean we lose the SVN version in cases
  (b) and (c).
 
 
  Should svnversion.h instead be checked in to source control and
  automatically updated at each checkin (by a trigger)?
 
  Or should 1.7.[even number] mean an SVN build between versions and
  1.7.[odd number] mean a development release, thus partially removing
  the interest in having an SVN number in (c)?
 
  Or...?

 I updated make-version.pl to clarify the different things that it does.
 It can now store the SVN revision in config.nmake, which can then be
 used to rebuild svnversion.h. Updating config.nmake was a lot easier
 than a post-commit hook since we were storing other version information
 there.


Hi Gerald,

since your commit I'm facing a small issue when compiling trunk for
Windows. The following command (in top Makefile.nmake):
cd plugins
$(MAKE) /$(MAKEFLAGS) -f Makefile.nmake install-plugins
tries to install the plugins in a folder named plugins\1.7.1-SVN- while
Wireshark expects them to have them in a folder named plugins\1.7.1 (they
fail to load unless i copy them to the plugins\1.7.1 folder).
It appears due to the change done in config.nmake so as to set
VERSION_BUILD to $(SVN_REVISION).

Not sure what is preferable. I guess it would be better to avoid generating
a new plugin folder each time the revision number increases.

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

Re: [Wireshark-dev] Win32 build from 1.6.3 source tarball: svnversion.h missing and not generated?

[Pascal Quantin]

Hi Chris,

2011/11/18 Chris Maynard chris.mayn...@gtech.com

 Gerald Combs gerald@... writes:

  I updated make-version.pl to clarify the different things that it does.
  It can now store the SVN revision in config.nmake, which can then be
  used to rebuild svnversion.h. Updating config.nmake was a lot easier
  than a post-commit hook since we were storing other version information
  there.

 I compiled r39937 on Windows XP SP3 (32-bit), but the plugins directory
 created
 was wireshark-gtk2\plugins\1.7.1-SVN-39921.  Is this to be expected?  If
 so,
 when exactly would the directory name change to reflect the actual
 revision?

 Also, unless a distclean is done, when it does change, will you be left
 with
 outdated SVN-x directories?  If so, should a modification be made to
 wipe
 out any stale directories that might be present?


Since Gerald's commit in revision 39924 everything is back to normal
(plugin folder is named 1.7.1) :)

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

Re: [Wireshark-dev] [Wireshark-commits] rev 40549: /trunk/ /trunk/epan/dissectors/: packet-lpp.c packet-lte-rrc.c /trunk/epan/: CMakeLists.txt /trunk/asn1/lpp/: lpp.cnf /trunk/asn1/lte-rrc/: EUTRA-Int

[Pascal Quantin]

Hi,

Le 16/01/2012 22:36, Joerg Mayer a écrit :
 On Mon, Jan 16, 2012 at 09:25:22PM +, etx...@wireshark.org wrote:
 http://anonsvn.wireshark.org/viewvc/viewvc.cgi?view=revrevision=40549

 User: etxrab
 Date: 2012/01/16 01:25 PM

 Log:
  From Pascal Quantin:
  Upgrade LTE RRC dissector to v10.4.0
  
  https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=6742

 Directory: /trunk/epan/dissectors/
   ChangesPathAction
   +48 -9 packet-lpp.cModified
   +9016 -1461 packet-lte-rrc.cModified

 Directory: /trunk/epan/
   ChangesPath  Action
   +1 -1  CMakeLists.txtModified

 Directory: /trunk/asn1/lpp/
   ChangesPath  Action
   +10 -0 lpp.cnf   Modified

 Directory: /trunk/asn1/lte-rrc/
   ChangesPath  Action
   +22 -4 EUTRA-InterNodeDefinitions.asnModified
   +947 -73   EUTRA-RRC-Definitions.asn Modified
   +38 -3 EUTRA-UE-Variables.asnModified
   +147 -3lte-rrc.cnf   Modified
   +298 -6packet-lte-rrc-template.c Modified
 Here is what I get on my OSX testsystem:

 libtool: compile:  gcc -DHAVE_CONFIG_H -I. -I../.. -I../../../epan/dissectors 
 -I../../../epan/dissectors/../.. -I../../../epan/dissectors/.. 
 -I/usr/local/include -I/usr/local/include -I/usr/local/include 
 -DPLUGIN_DIR=\/usr/local/lib/wireshark/plugins/1.7.1\ -DINET6 
 -DG_DISABLE_DEPRECATED -DG_DISABLE_SINGLE_INCLUDES 
 -DGTK_DISABLE_SINGLE_INCLUDES -no-cpp-precomp -D_FORTIFY_SOURCE=2 
 -D_U_=__attribute__((unused)) -g -O2 -Wall -W -Wextra 
 -Wdeclaration-after-statement -Wendif-labels -Wpointer-arith 
 -Wno-pointer-sign -Wcast-align -Wformat-security -Wold-style-definition 
 -I/usr/local/include -DGSEAL_ENABLE -D_REENTRANT -I/usr/local/include/gtk-3.0 
 -I/usr/local/include/atk-1.0 -I/usr/local/include/cairo 
 -I/usr/local/include/gdk-pixbuf-2.0 -I/usr/local/include/pango-1.0 
 -I/usr/local/include/glib-2.0 -I/usr/local/lib/glib-2.0/include 
 -I/usr/local/include/pixman-1 -I/usr/local/include/libpng15 
 -I/usr/X11/include -I/usr/X11/include/freetype2 -MT packet-lpp.lo -MD -MP -MF 
 .deps/packet-lpp.Tpo -c ../../../epan/dissectors/packet-lpp.c  -fno-common 
 -DPIC -o .libs/packet-lpp.o
 ../../asn1/lte-rrc/packet-lte-rrc-template.c:42:24: error: packet-lpp.h: No 
 such file or directory
 ../../asn1/lte-rrc/packet-lte-rrc-fn.c: In function 
 'dissect_lte_rrc_T_ellipsoid_Point_r10':
 ../../asn1/lte-rrc/packet-lte-rrc-fn.c:17022: warning: implicit declaration 
 of function 'dissect_lpp_Ellipsoid_Point_PDU'
 ../../asn1/lte-rrc/packet-lte-rrc-fn.c: In function 
 'dissect_lte_rrc_T_ellipsoidPointWithAltitude_r10':
 ../../asn1/lte-rrc/packet-lte-rrc-fn.c:17038: warning: implicit declaration 
 of function 'dissect_lpp_EllipsoidPointWithAltitude_PDU'
 ../../asn1/lte-rrc/packet-lte-rrc-fn.c: In function 
 'dissect_lte_rrc_T_horizontalVelocity_r10':
 ../../asn1/lte-rrc/packet-lte-rrc-fn.c:17076: warning: implicit declaration 
 of function 'dissect_lpp_HorizontalVelocity_PDU'
 make[5]: *** [packet-lte-rrc.lo] Error 1

 Ciao
 Jörg
as I indicated in bug 6742, Anders forgot to commit the newly added
asn1/lpp/packet-lpp-template.h and epan/dissectors/packet-lpp.h files
that are part of the patch.

Regards,
Pascal.

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

Re: [Wireshark-dev] gsm system information parsing

[Pascal Quantin]

2012/3/14 Tom Mayer ran-...@gmx.de

 Hi everyone,

 I have been working on a mobile project for university and have used
 wireshark together with the osmocombb framework analyze gsm traffic.

 In my project I get the raw System Information 2/2ter/2bis messages and I
 need to extract the neighbouring cell information from it. The format is
 supposed to be specified in GSM 04.08 but it is only a partly description
 and it seems I cannot find a full desscription.

 I have seen wireshark has a parser for this, at least it dispolays the
 neighbouring cells extracted from a System Information message. Can anybody
 give me a hint to where to find the respective parsing code in the
 wireshark code (pretty unfamiliar with the wireshark codebase) or where to
 find the full specifications.

 Thanks in advance
 Cheers
 Tom


Hi Tom,

The code in Wireshark can be found in epan/dissectors/packet-gsm_a_rr.c
The corresponding 3GPP specification is 44.018:
http://www.3gpp.org/ftp/Specs/html-info/44018.htm

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

Re: [Wireshark-dev] Artnet/RDM/DMX dissector updates

[Pascal Quantin]

2012/4/13 Erwin Rol mailingli...@erwinrol.com

 Hey all,

 I am currently working on some updates of my Artnet, RDM and DMX
 dissectors, and since it is a long time ago I contributed to wireshark I
 was just wondering if I still can post patches here ?


Hi Erwin,

the recommended process is to fill an enhancement bug (
https://bugs.wireshark.org/bugzilla/) and post your patch with the
review_for_checkin? flag set so that it does not get lost.

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

[Wireshark-dev] Crash with the new win32 GTK+ bundle when opening an analysis window

[Pascal Quantin]

Hi all,

with the current trunk top of tree, when I open a TCP capture and select
Statistics--IO Graph (for example, happens with other windows) I get a
systematic crash.
Here is my build info:

Version 1.7.2 (SVN Rev 42152 from /trunk)

Copyright 1998-2012 Gerald Combs ger...@wireshark.org and contributors.
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 (32-bit) with GTK+ 2.24.10, with Cairo 1.12.0, with Pango 1.29.4,
with
GLib 2.32.1, with WinPcap (4_1_2), with libz 1.2.5, without POSIX
capabilities,
with SMI 0.4.8, with c-ares 1.7.1, with Lua 5.1, without Python, with GnuTLS
2.12.18, with Gcrypt 1.4.6, with MIT Kerberos, with GeoIP, with PortAudio
V19-devel (built Apr 20 2012), with AirPcap.

Running on 64-bit Windows 7 Service Pack 1, build 7601, with WinPcap version
4.1.2 (packet.dll version 4.1.0.2001), based on libpcap version 1.0 branch
1_0_rel0b (20091008), GnuTLS 2.12.18, Gcrypt 1.4.6, without AirPcap.

Built using Microsoft Visual C++ 9.0 build 30729


Is anyone having the same issue?

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

Re: [Wireshark-dev] Crash with the new win32 GTK+ bundle when opening an analysis window

[Pascal Quantin]

Hi Evan,

2012/4/20 Evan Huus eapa...@gmail.com

 There have recently been changes in the way that conversations are
 re-analyzed (to make them faster) that might have accidentally caused this.
 If the same crash happens with Flow Graph and Conversations then please
 file a bug with a reproducible capture - the changes worked on everything I
 tried, but I guess I missed a corner case somewhere.


Thanks for the suggestion. Reverting revision 42150 (your change to
conversation.c) did not help.  Instead reverting revision 42143 (Gerald's
change so as to use the new GTK+ package) solves the crash for me.

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

Re: [Wireshark-dev] Crash with the new win32 GTK+ bundle when opening an analysis window

[Pascal Quantin]

Hi Anders,

2012/4/20 Anders Broman anders.bro...@ericsson.com

 **
 Hi,
 Did you try a clean build of top-of-tree?
 Regards
 Anders

 Compiling a r41159 out of a clean checkout of the tree still crashes for
me. Plugging the debugger does not help much as it seems to crash in the
gtk+ librairies.

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

Re: [Wireshark-dev] How do I build wireshark so I can run gdb on the result?

[Pascal Quantin]

Hi Richard,

2012/5/13 Richard Sharpe realrichardsha...@gmail.com:
 Hi folks,

 libtool is getting in the way and the result is that shared objects
 are not found or I have to set up a long LD_LIBRARY_PATH

 Is there a simpler way?

You need to run Wireshark with the following command line:
libtool --mode=execute gdb wireshark
See http://wiki.wireshark.org/Development/Tips for details.

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

Re: [Wireshark-dev] wrongly decoded mt-forwardSM

[Pascal Quantin]

2012/5/21 Balazs Nagy nagybalazs@gmail.com:
 Hello everybody!

 I've faced a problem during decoding an SMS sending process.

 The situation is the following:

 I sent 2 SMs to a mobile which was turn to offline. So in first round these
 SMs were stored in the SMSC. When the mobile was turn ON again the SMSC got
 an alert and try to sent the two SMs.
 The delivery was completely successful but in the wireshark capture I saw
 that the second mt-forwardSM is missing. I found only an invoke forwardSM
 (message type: SMS-DELIVER REPORT) after the first mt-forwardSM. This invoke
 forwardSM was weird for me so I copied the GSM SMS TPDU (SMS-DELIVER REPORT)
 part into another decoder tool and I found that this forwardSM is my last
 mt-forwardSM what I was looking for.
 Then I start to search for some known bugs about this issue on the wireshark
 website and I found the following old mail:

 http://www.wireshark.org/lists/wireshark-users/200612/msg00124.html

 Based on this mail I checked the 3GPP TS 03.40 SMS standard. Here I found
 that TP-MTI contains the type of the message and SMS-DELIVER and SMS-DELIVER
 REPORT has the same value:
 bit no. 0: 0
 bit no. 1: 0

 I think the problem is that in this case wireshark decode this message
 wrongly because it also checks the TP-MMS part(bit no. 3) too to decide the
 TP-MTI correctly.

 On MAP level this message was identified as an SMS-DELIVER REPORT message
 instead of SMS-DELIVER.

 Could you check me whether it is really a decoding problem in the wireshark?

 Br,
 Balazs Nagy

Hi Balazs,

could you try with the latest trunk version (can be found here:
http://www.wireshark.org/download/automated/ )? Some changes were done
in revision 42064 that might help you.
If you can still trigger the issue, could you fill a bug
(https://bugs.wireshark.org/bugzilla/) and attach the pcap file?

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

Re: [Wireshark-dev] New developer - how to start?

[Pascal Quantin]

2012/5/25 Dipanjan Das its.dipanjan@gmail.com:

 Hi Developers,

 I want to get myself involved in the development of Wireshark. Can anybody
 please let me know about the following:

 Is there anywhere I need to get myself registered as a developer?
 How are the tasks splitted across?
 How is the synchronization among developers done?

Hi,

there is no registration needed. All you need is to follow the advices
found here:
http://www.wireshark.org/develop.html
This page contains links to useful docs like the developer's user guide:
http://www.wireshark.org/docs/wsdg_html_chunked
Then once you want to start coding, the doc folder (located at the
root of the source code tree) contains a lot of useful stuff also.

Usually people working on a feature / bug fix submit a bug report to
https://bugs.wireshark.org/ and attach their patch for review. If your
patch is considered as good enough, it will be committed to the
subversion repository by one of the core developers.
If you do not have any specific idea on what to work on, they are
plenty of bugs waiting for a contributor :)

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

Re: [Wireshark-dev] SVN HEAD not building

[Pascal Quantin]

Le 27 mai 2012 à 01:12, Akos Vandra axo...@gmail.com a écrit :

 Sorry, I forgot to mention: I am running ubuntu 10.10, x64 version.
 
 On 27 May 2012 01:05, Akos Vandra axo...@gmail.com wrote:
 Hi!
 
 I'm developing a few dissectors for socketcan. They were working fine,
 until I decided to update to SVN head.
 Now during the build I get:
 
 Making all in dissectors
 make[3]: Entering directory
 `/home/akos/projects/c/wireshark/wireshark/epan/dissectors'
 make[3]: *** No rule to make target `Custom.nmake', needed by
 `Makefile.in'.  Stop.
 make[3]: Leaving directory
 `/home/akos/projects/c/wireshark/wireshark/epan/dissectors'
 make[2]: *** [all-recursive] Error 1
 make[2]: Leaving directory `/home/akos/projects/c/wireshark/wireshark/epan'
 make[1]: *** [all-recursive] Error 1
 make[1]: Leaving directory `/home/akos/projects/c/wireshark/wireshark'
 make: *** [all] Error 2
 
 Do I need a new tool installed?

Hi,

A make distclean should get you out of trouble.

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

Re: [Wireshark-dev] PCH in packet-nbap-template.c

[Pascal Quantin]

Hi Gisle,

2012/5/30 Gisle Vanem gva...@broadpark.no:
 asn1/nbap/packet-nbap-template.c now introduces an enum value
 'PCH' that clashes with 'PCH' in WinNT.h.

 According to:
  http://anonsvn.wireshark.org/viewvc/trunk/asn1/nbap/packet-nbap-template.c?r1=42779r2=42783

 The change happened at May 22 15:39:12. Could that be renamed to '_PCH'?

I prefixed the enum entries with NBAP_ in revision 42922.

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

Re: [Wireshark-dev] Patches to properly handle extended responses for NTCreateX

[Pascal Quantin]

2012/5/31 Richard Sharpe realrichardsha...@gmail.com:
 On Wed, May 30, 2012 at 10:30 PM, ronnie sahlberg
 ronniesahlb...@gmail.com wrote:
 hf_smb_volume_guid   shouldnt this be a FT_GUID ?

 Can you try making it FT_GUID and see if it works?

 Quite likely, but then so should hf_smb_server_guild in that case ...

Done in revision 42944.

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

Re: [Wireshark-dev] Patches to properly handle extended responses for NTCreateX

[Pascal Quantin]

Hi,

2012/5/31 Richard Sharpe realrichardsha...@gmail.com:
 On Thu, May 31, 2012 at 12:19 AM, Alexis La Goutte
 alexis.lagou...@gmail.com wrote:
 Hi,

 it is better to create a bug with your patch in BugTracker (
 https://bugs.wireshark.org )

 Heh, I don't even get to fix my own bugs without filing a bug report?

Well, that's easier to review a patch this way and iterate on it (if needed).
For example you sent two different mails with the same patch attached.
If they were different, we could easily have been confused and the
wrong version might have been committed.
Also this way it does not get lost into the mailing list.
As you can see, there are only benefits :)

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

Re: [Wireshark-dev] Note about proto_tree_add_unicode_string (r43379)

[Pascal Quantin]

Le 19/06/2012 21:01, Jakub Zawadzki a écrit :
 Hi,

 String from tvb_get_ephemeral_string() still needs escaping with 
 format_text(),
 cause it doesn't check encoding.

 When you use:
   tvb_get_ephemeral_string_enc(tvb, offset, length, ENC_UTF_8 | ENC_NA);

 It guarantees result encoded in UTF-8:
  * string as converted from the appropriate encoding to UTF-8 ...

 (Code to do it is still in XXX's but this is bug in libwireshark and no one 
 can blame you that you used wrong function :))
Hi,

thanks for the hint (and for adding proto_tree_add_unicode_string :) ).
Still I probably miss something but when looking at the code for
tvb_get_ephemeral_string_enc, I see:
case ENC_ASCII:
default:
/*
 * For now, we treat bogus values as meaning
 * ASCII rather than reporting an error,
 * for the benefit of old dissectors written
 * when the last argument to proto_tree_add_item()
 * was a gboolean for the byte order, not an
 * encoding value, and passed non-zero values
 * other than TRUE to mean little-endian.
 *
 * XXX - should map all octets with the 8th bit
 * not set to a substitute UTF-8 character.
 */
strbuf = tvb_get_ephemeral_string(tvb, offset, length);
break;

case ENC_UTF_8:
/*
 * XXX - should map all invalid UTF-8 sequences
 * to a substitute UTF-8 character.
 */
strbuf = tvb_get_ephemeral_string(tvb, offset, length);
break;

Do you mean we should already start using tvb_get_ephemeral_string_enc
to continue working once the check for the ASCII 8th bit will be in place?

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

Re: [Wireshark-dev] Note about proto_tree_add_unicode_string (r43379)

[Pascal Quantin]

Le 19/06/2012 21:14, Pascal Quantin a écrit :
 Le 19/06/2012 21:01, Jakub Zawadzki a écrit :
 Hi,

 String from tvb_get_ephemeral_string() still needs escaping with 
 format_text(),
 cause it doesn't check encoding.

 When you use:
   tvb_get_ephemeral_string_enc(tvb, offset, length, ENC_UTF_8 | ENC_NA);

 It guarantees result encoded in UTF-8:
  * string as converted from the appropriate encoding to UTF-8 ...

 (Code to do it is still in XXX's but this is bug in libwireshark and no one 
 can blame you that you used wrong function :))
 Hi,

 thanks for the hint (and for adding proto_tree_add_unicode_string :) ).
 Still I probably miss something but when looking at the code for
 tvb_get_ephemeral_string_enc, I see:
 case ENC_ASCII:
 default:
 /*
  * For now, we treat bogus values as meaning
  * ASCII rather than reporting an error,
  * for the benefit of old dissectors written
  * when the last argument to proto_tree_add_item()
  * was a gboolean for the byte order, not an
  * encoding value, and passed non-zero values
  * other than TRUE to mean little-endian.
  *
  * XXX - should map all octets with the 8th bit
  * not set to a substitute UTF-8 character.
  */
 strbuf = tvb_get_ephemeral_string(tvb, offset, length);
 break;

 case ENC_UTF_8:
 /*
  * XXX - should map all invalid UTF-8 sequences
  * to a substitute UTF-8 character.
  */
 strbuf = tvb_get_ephemeral_string(tvb, offset, length);
 break;

 Do you mean we should already start using tvb_get_ephemeral_string_enc
 to continue working once the check for the ASCII 8th bit will be in place?

 Regards,
 Pascal.
Forget about it, I just saw your sentence in parenthesis :)

Regards,
Pascal.

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

Re: [Wireshark-dev] [Wireshark-commits] rev 43497: /trunk/epan/ /trunk/epan/: expert.c

[Pascal Quantin]

Hi,

Le 27/06/2012 00:12, Bill Meier a écrit :
 On 6/26/2012 3:36 PM, pas...@wireshark.org wrote:
 http://anonsvn.wireshark.org/viewvc/viewvc.cgi?view=revrevision=43497

 User: pascal
 Date: 2012/06/26 12:36 PM

 Log:
   Display expert codes in hexadecimal (less painful for my eyes :))


 The real question:

 Why are the essentially meaningless numeric values for the expert
 codes now being shown in the expert messages ?

 Wireshark 1.6 doesn't show the numeric values (which is the way I
 think it should be).

 What changed ?
This is due to the now forbidden usage of BASE_NONE with FT_(U)INT* done
in r43412.
I first used a BASE_CUSTOM to get completely rid of the numeric display
but then nice filters like expert.severity == Note were not working
anymore :( Thus the tradeoff with the hexadecimal display.
But I agree with you: it would be better to get rid of them.

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

Re: [Wireshark-dev] Corrupted c-areas 1.71 zip archive

[Pascal Quantin]

Le 04/07/2012 19:25, Tobias Weiss a écrit :
 Hi everyone,

 I've developed a plugin on Linux which works just fine. Now I wanted to
 create a Windows installer which includes the new plugin. Unfortunately
 when executing

 nmake -f Makefile.nmake setup

 I always get the following error:

 [/cygdrive/c/wireshark-win32-libs-1.8/c-ares-1.7.1-win32ws.zip]
 End-of-central-directory signature not found.  Either this file is not
 a zipfile, or it constitutes one disk of a multi-part archive.  In the
 latter case the central directory and zipfile comment will be found on
 the last disk(s) of this archive.

 The file seems to be corrupted as other programs (like 7zip and the Windows
 zip application) fail to extract it as well. I'm using Win7 64, Visual
 Studio 2010 Pro and the most recent cygwin version.

 Any suggestions?
Hi Tobias,

it is working perfectly fine here. I guess you have a partially
downloaded file, thus the corrupted warning. Just erase your
/cygdrive/c/wireshark-win32-libs-1.8/c-ares-1.7.1-win32ws.zip file and
relaunch nmake -f Makefile.nmake setup.

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

Re: [Wireshark-dev] Corrupted c-areas 1.71 zip archive

[Pascal Quantin]

2012/7/4 Tobias Weiss twe...@ra.rockwell.com

 Pascal Quantin wrote on 07/04/2012 02:23:59 PM:
  it is working perfectly fine here. I guess you have a partially
  downloaded file, thus the corrupted warning. Just erase your
  /cygdrive/c/wireshark-win32-libs-1.8/c-ares-1.7.1-win32ws.zip file and
  relaunch nmake -f Makefile.nmake setup.

 Hi Pascal,

 Thanks for your quick response. But unfortunately I have tried it multiple
 times (within the last days) and I always get the same result. My file has
 5532 bytes and the md5 sum is db660e44172d892fe8a82c96e7eead81. Could
 someone confirm this?


The file should have 125210 bytes (md5: e20bed515f11e4f24275208d1d718fc9).
You can manually download from
http://anonsvn.wireshark.org/wireshark-win32-libs/tags/2012-05-30/packages/c-ares-1.7.1-win32ws.zip

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

Re: [Wireshark-dev] r43579 Generic preference implementation broken compile

[Pascal Quantin]

2012/7/6 Stephen Fisher st...@stephen-fisher.com

 SVN revision 43579 broke compilation:

 prefs_nameres.c: In function 'nameres_prefs_show':
 prefs_nameres.c:109: error: 'e_prefs' has no member named 'name_resolve'
 prefs_nameres.c:126: error: 'e_prefs' has no member named 'name_resolve'

 This is one case of trying to use the variable that no longer exists:

 prefs.name_resolve = gbl_resolv_flags;

 I haven't been following these changes recently - is this line still
 needed or is this a work in progress yet to be completed?


Hi Stephen,

give a try to current top of tree: it should compile.

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

Re: [Wireshark-dev] ASN.1 integers and types

[Pascal Quantin]

2012/7/10 Anders Broman a.bro...@bredband.net

 Guy Harris skrev 2012-07-10 01:34:

  On Jul 9, 2012, at 2:41 PM, 
 buildbot-no-reply@wireshark.**orgbuildbot-no-re...@wireshark.orgwrote:

  The Buildbot has detected a new failure on builder OSX-10.5-x86 while
 building Wireshark (development).
 Full details are available at:
 http://buildbot.wireshark.org/**trunk/builders/OSX-10.5-x86/**
 builds/1821http://buildbot.wireshark.org/trunk/builders/OSX-10.5-x86/builds/1821

 Buildbot URL: 
 http://buildbot.wireshark.org/**trunk/http://buildbot.wireshark.org/trunk/

 Buildslave for this Build: osx-10.5-x86

 Build Reason: scheduler
 Build Source Stamp: 43629
 Blamelist: pascal

 BUILD FAILED: failed compile

 /bin/sh ../../libtool --tag=CC   --mode=compile ccache gcc
 -DHAVE_CONFIG_H -I. -I../.. -I./../.. -I./.. -I/usr/local/include
 -I/usr/local/include  -DINET6 -DG_DISABLE_DEPRECATED
 -DG_DISABLE_SINGLE_INCLUDES -DGTK_DISABLE_DEPRECATED -DGTK_DISAB
 LE_SINGLE_INCLUDES -D_U_=__attribute__((unused))**
  -D_FORTIFY_SOURCE=2 -I/usr/local/include  '-DPLUGIN_DIR=/usr/local/lib/
 **wireshark/plugins/1.9.0-SVN-**43629' -Werror -no-cpp-precomp -g -O2
 -Wall -W -Wextra -Wdeclaration-after-statement -Wendif-labels
 -Wpointer-arith -Wno-pointer-sign -Wcast-align -Wformat-security
 -Wold-style-definition -I/usr/X11/include/freetype2 -I/usr/X11/include
 -I/usr/X11/include/libpng12 -I/usr/X11/include/pixman-1
 -I/usr/local/include/gtk-2.0 -I/usr/local/lib/gtk-2.0/**include
 -I/usr/local/include/atk-1.0 -I/usr/local/include/cairo
 -I/usr/local/include/pango-1.0 -I/usr/local/include/glib-2.0
 -I/usr/local/lib/glib-2.0/**include   -MT 
 libdissectors_la-packet-mpeg-**audio.lo
 -MD -MP -MF .deps/libdissectors_la-packet-**mpeg-audio.Tpo -c -o
 libdissectors_la-packet-mpeg-**audio.lo `test -f 'packet-mpeg-audio.c'
 || echo './'`packet-mpeg-audio.c
 cc1: warnings being treated as errors
 ../../asn1/lpp/lpp.cnf: In function 'dissect_lpp_INTEGER_**M2147483648_
 2147483647':
 ../../asn1/lpp/lpp.cnf:1328: warning: this decimal constant is unsigned
 only in ISO C90

 The offending code is

 static int
 dissect_lpp_INTEGER_**M2147483648_2147483647(tvbuff_t *tvb _U_, int
 offset _U_, asn1_ctx_t *actx _U_, proto_tree *tree _U_, int hf_index _U_) {
offset = dissect_per_constrained_**integer(tvb, offset, actx, tree,
 hf_index,
  -2147483648,
 2147483647U, NULL, FALSE);

return offset;
 }

 The two integral constants in that call correspond to guint32 arguments;
 the first of those is, obviously, negative.

 ITU-T Recommendation X.680 says

 3.8.40  integer type: A simple type with distinguished values
 which are the positive and negative whole numbers, including zero (as a
 single value).

 NOTE – Particular encoding rules limit the range of an
 integer, but such limitations are chosen so as not to affect any user of
 ASN.1.

 and I don't see anything about a type that includes only the positive
 whole numbers, including zero - i.e., no unsigned type - so perhaps, if
 we're to strictly interpret ASN.1, either all integral types should be
 signed, and any integral type with values  2147483647 should be 64-bit
 (or we should introduce bignums so that we don't have to bail out on *any*
 ASN.1 number) or, at least, all *unconstrained* integral types should be
 signed and 64-bit (or, if we introduce bignums, bignum), with only integral
 types constrained to a minimum value= 0 unsigned, and with the width of
 the type chosen based on the constraints.

 The right short-term fix might be to make the arguments to
 dissect_per_constrained_**integer() be gint64 rather than guint32 - and
 perhaps have the pointer for the returned value be a gint64 * rather than a
 guint32 *.

 Yes I vote for that.


Hi Guy and Anders,

sorry for the breakage, it was compiling fine with both my Ubuntu and
Windows boxes :/

By modifying a bit asn2wrs.py so as to add G_GINT64_CONSTANT for -2^31 also
fixes the compilation but I'm not sure this is the best idea...
Index: tools/asn2wrs.py
===
--- tools/asn2wrs.py(revision 43636)
+++ tools/asn2wrs.py(working copy)
@@ -3225,7 +3225,7 @@
 if str(minv).isdigit():
   minv += 'U'
 elif (str(minv)[0] == -) and str(minv)[1:].isdigit():
-  if (long(minv)  -(2**31)):
+  if (long(minv) = -(2**31)):
 minv = G_GINT64_CONSTANT(%s) % (str(minv))
 if str(maxv).isdigit():
   if (long(maxv) = 2**32):

By the way there is a dissect_per_constrained_integer_64b function that can
be called instead of dissect_per_constrained_integer when you put
FN_VARIANT=_64b in te conformance file, but it will still not compile due
to the missing G_GINT64_CONSTANT.

As I'm running out of time, I have moved LPP and LPPe dissectors into the
ASN.1 dirty lib in revision 43637. It should at least allow people hitting
the error to compile fine.

Regards,
Pascal.

Re: [Wireshark-dev] ASN.1 integers and types

[Pascal Quantin]

2012/7/10 Pascal Quantin pascal.quan...@gmail.com



 2012/7/10 Anders Broman a.bro...@bredband.net

 Guy Harris skrev 2012-07-10 01:34:

  On Jul 9, 2012, at 2:41 PM, 
 buildbot-no-reply@wireshark.**orgbuildbot-no-re...@wireshark.orgwrote:

  The Buildbot has detected a new failure on builder OSX-10.5-x86 while
 building Wireshark (development).
 Full details are available at:
 http://buildbot.wireshark.org/**trunk/builders/OSX-10.5-x86/**
 builds/1821http://buildbot.wireshark.org/trunk/builders/OSX-10.5-x86/builds/1821

 Buildbot URL: 
 http://buildbot.wireshark.org/**trunk/http://buildbot.wireshark.org/trunk/

 Buildslave for this Build: osx-10.5-x86

 Build Reason: scheduler
 Build Source Stamp: 43629
 Blamelist: pascal

 BUILD FAILED: failed compile

 /bin/sh ../../libtool --tag=CC   --mode=compile ccache gcc
 -DHAVE_CONFIG_H -I. -I../.. -I./../.. -I./.. -I/usr/local/include
 -I/usr/local/include  -DINET6 -DG_DISABLE_DEPRECATED
 -DG_DISABLE_SINGLE_INCLUDES -DGTK_DISABLE_DEPRECATED -DGTK_DISAB
 LE_SINGLE_INCLUDES -D_U_=__attribute__((unused))**
  -D_FORTIFY_SOURCE=2 -I/usr/local/include  '-DPLUGIN_DIR=/usr/local/lib/
 **wireshark/plugins/1.9.0-SVN-**43629' -Werror -no-cpp-precomp -g -O2
 -Wall -W -Wextra -Wdeclaration-after-statement -Wendif-labels
 -Wpointer-arith -Wno-pointer-sign -Wcast-align -Wformat-security
 -Wold-style-definition -I/usr/X11/include/freetype2 -I/usr/X11/include
 -I/usr/X11/include/libpng12 -I/usr/X11/include/pixman-1
 -I/usr/local/include/gtk-2.0 -I/usr/local/lib/gtk-2.0/**include
 -I/usr/local/include/atk-1.0 -I/usr/local/include/cairo
 -I/usr/local/include/pango-1.0 -I/usr/local/include/glib-2.0
 -I/usr/local/lib/glib-2.0/**include   -MT libdissectors_la-packet-mpeg-*
 *audio.lo -MD -MP -MF .deps/libdissectors_la-packet-**mpeg-audio.Tpo -c
 -o libdissectors_la-packet-mpeg-**audio.lo `test -f
 'packet-mpeg-audio.c' || echo './'`packet-mpeg-audio.c
 cc1: warnings being treated as errors
 ../../asn1/lpp/lpp.cnf: In function 'dissect_lpp_INTEGER_**M2147483648_
 2147483647':
 ../../asn1/lpp/lpp.cnf:1328: warning: this decimal constant is unsigned
 only in ISO C90

 The offending code is

 static int
 dissect_lpp_INTEGER_**M2147483648_2147483647(tvbuff_t *tvb _U_, int
 offset _U_, asn1_ctx_t *actx _U_, proto_tree *tree _U_, int hf_index _U_) {
offset = dissect_per_constrained_**integer(tvb, offset, actx, tree,
 hf_index,
  -2147483648,
 2147483647U, NULL, FALSE);

return offset;
 }

 The two integral constants in that call correspond to guint32 arguments;
 the first of those is, obviously, negative.

 ITU-T Recommendation X.680 says

 3.8.40  integer type: A simple type with distinguished values
 which are the positive and negative whole numbers, including zero (as a
 single value).

 NOTE – Particular encoding rules limit the range of an
 integer, but such limitations are chosen so as not to affect any user of
 ASN.1.

 and I don't see anything about a type that includes only the positive
 whole numbers, including zero - i.e., no unsigned type - so perhaps, if
 we're to strictly interpret ASN.1, either all integral types should be
 signed, and any integral type with values  2147483647 should be 64-bit
 (or we should introduce bignums so that we don't have to bail out on *any*
 ASN.1 number) or, at least, all *unconstrained* integral types should be
 signed and 64-bit (or, if we introduce bignums, bignum), with only integral
 types constrained to a minimum value= 0 unsigned, and with the width of
 the type chosen based on the constraints.

 The right short-term fix might be to make the arguments to
 dissect_per_constrained_**integer() be gint64 rather than guint32 - and
 perhaps have the pointer for the returned value be a gint64 * rather than a
 guint32 *.

 Yes I vote for that.


 Hi Guy and Anders,

 sorry for the breakage, it was compiling fine with both my Ubuntu and
 Windows boxes :/

 By modifying a bit asn2wrs.py so as to add G_GINT64_CONSTANT for -2^31
 also fixes the compilation but I'm not sure this is the best idea...
 Index: tools/asn2wrs.py
 ===
 --- tools/asn2wrs.py(revision 43636)
 +++ tools/asn2wrs.py(working copy)
 @@ -3225,7 +3225,7 @@
  if str(minv).isdigit():
minv += 'U'
  elif (str(minv)[0] == -) and str(minv)[1:].isdigit():
 -  if (long(minv)  -(2**31)):
 +  if (long(minv) = -(2**31)):
  minv = G_GINT64_CONSTANT(%s) % (str(minv))
  if str(maxv).isdigit():
if (long(maxv) = 2**32):


Hi,

According to
http://stackoverflow.com/questions/9941261/warning-this-decimal-constant-is-unsigned-only-in-iso-c90the
warning we see is expected (that's why INT32_MIN is defined as
(-INT32_MAX - 1L) for example).
Does the use of the G_GINT64_CONSTANT macro for this specific value (as
done in the patch above) seems an acceptable workaround for everybody?
Alternatively we

Re: [Wireshark-dev] ASN.1 integers and types

[Pascal Quantin]

2012/7/12 Pascal Quantin pascal.quan...@gmail.com

 2012/7/10 Pascal Quantin pascal.quan...@gmail.com

 2012/7/10 Anders Broman a.bro...@bredband.net

 Guy Harris skrev 2012-07-10 01:34:

  On Jul 9, 2012, at 2:41 PM, 
 buildbot-no-reply@wireshark.**orgbuildbot-no-re...@wireshark.orgwrote:

  The Buildbot has detected a new failure on builder OSX-10.5-x86 while
 building Wireshark (development).
 Full details are available at:
 http://buildbot.wireshark.org/**trunk/builders/OSX-10.5-x86/**
 builds/1821http://buildbot.wireshark.org/trunk/builders/OSX-10.5-x86/builds/1821

 Buildbot URL: 
 http://buildbot.wireshark.org/**trunk/http://buildbot.wireshark.org/trunk/

 Buildslave for this Build: osx-10.5-x86

 Build Reason: scheduler
 Build Source Stamp: 43629
 Blamelist: pascal

 BUILD FAILED: failed compile

 /bin/sh ../../libtool --tag=CC   --mode=compile ccache gcc
 -DHAVE_CONFIG_H -I. -I../.. -I./../.. -I./.. -I/usr/local/include
 -I/usr/local/include  -DINET6 -DG_DISABLE_DEPRECATED
 -DG_DISABLE_SINGLE_INCLUDES -DGTK_DISABLE_DEPRECATED -DGTK_DISAB
 LE_SINGLE_INCLUDES -D_U_=__attribute__((unused))**
  -D_FORTIFY_SOURCE=2 -I/usr/local/include  '-DPLUGIN_DIR=/usr/local/lib/
 **wireshark/plugins/1.9.0-SVN-**43629' -Werror -no-cpp-precomp -g -O2
 -Wall -W -Wextra -Wdeclaration-after-statement -Wendif-labels
 -Wpointer-arith -Wno-pointer-sign -Wcast-align -Wformat-security
 -Wold-style-definition -I/usr/X11/include/freetype2 -I/usr/X11/include
 -I/usr/X11/include/libpng12 -I/usr/X11/include/pixman-1
 -I/usr/local/include/gtk-2.0 -I/usr/local/lib/gtk-2.0/**include
 -I/usr/local/include/atk-1.0 -I/usr/local/include/cairo
 -I/usr/local/include/pango-1.0 -I/usr/local/include/glib-2.0
 -I/usr/local/lib/glib-2.0/**include   -MT libdissectors_la-packet-mpeg-
 **audio.lo -MD -MP -MF .deps/libdissectors_la-packet-**mpeg-audio.Tpo
 -c -o libdissectors_la-packet-mpeg-**audio.lo `test -f
 'packet-mpeg-audio.c' || echo './'`packet-mpeg-audio.c
 cc1: warnings being treated as errors
 ../../asn1/lpp/lpp.cnf: In function 'dissect_lpp_INTEGER_**M2147483648_
 2147483647':
 ../../asn1/lpp/lpp.cnf:1328: warning: this decimal constant is unsigned
 only in ISO C90

 The offending code is

 static int
 dissect_lpp_INTEGER_**M2147483648_2147483647(tvbuff_t *tvb _U_, int
 offset _U_, asn1_ctx_t *actx _U_, proto_tree *tree _U_, int hf_index _U_) {
offset = dissect_per_constrained_**integer(tvb, offset, actx, tree,
 hf_index,
  -
 2147483648, 2147483647U, NULL, FALSE);

return offset;
 }

 The two integral constants in that call correspond to guint32
 arguments; the first of those is, obviously, negative.

 ITU-T Recommendation X.680 says

 3.8.40  integer type: A simple type with distinguished values
 which are the positive and negative whole numbers, including zero (as a
 single value).

 NOTE – Particular encoding rules limit the range of an
 integer, but such limitations are chosen so as not to affect any user of
 ASN.1.

 and I don't see anything about a type that includes only the positive
 whole numbers, including zero - i.e., no unsigned type - so perhaps, if
 we're to strictly interpret ASN.1, either all integral types should be
 signed, and any integral type with values  2147483647 should be
 64-bit (or we should introduce bignums so that we don't have to bail out on
 *any* ASN.1 number) or, at least, all *unconstrained* integral types should
 be signed and 64-bit (or, if we introduce bignums, bignum), with only
 integral types constrained to a minimum value= 0 unsigned, and with the
 width of the type chosen based on the constraints.

 The right short-term fix might be to make the arguments to
 dissect_per_constrained_**integer() be gint64 rather than guint32 -
 and perhaps have the pointer for the returned value be a gint64 * rather
 than a guint32 *.

 Yes I vote for that.


 Hi Guy and Anders,

 sorry for the breakage, it was compiling fine with both my Ubuntu and
 Windows boxes :/

 By modifying a bit asn2wrs.py so as to add G_GINT64_CONSTANT for -2^31
 also fixes the compilation but I'm not sure this is the best idea...
 Index: tools/asn2wrs.py
 ===
 --- tools/asn2wrs.py(revision 43636)
 +++ tools/asn2wrs.py(working copy)
 @@ -3225,7 +3225,7 @@
  if str(minv).isdigit():
minv += 'U'
  elif (str(minv)[0] == -) and str(minv)[1:].isdigit():
 -  if (long(minv)  -(2**31)):
 +  if (long(minv) = -(2**31)):
  minv = G_GINT64_CONSTANT(%s) % (str(minv))
  if str(maxv).isdigit():
if (long(maxv) = 2**32):


 Hi,

 According to
 http://stackoverflow.com/questions/9941261/warning-this-decimal-constant-is-unsigned-only-in-iso-c90the
  warning we see is expected (that's why INT32_MIN is defined as
 (-INT32_MAX - 1L) for example).
 Does the use of the G_GINT64_CONSTANT macro for this specific value (as
 done in the patch above) seems

Re: [Wireshark-dev] Make the NTLMSSP Unknown message type string more explicit

[Pascal Quantin]

2012/7/14 Richard Sharpe realrichardsha...@gmail.com

 Hi folks,

 One problem I saw at Sharkfest was that the NTLMSSP dissector was
 printing UNKNOWN message type on the info field, which was being
 confused as an Unknown SMB2 message type by the presenter.

 This makes it more explicit:

 Index: epan/dissectors/packet-ntlmssp.c
 ===
 --- epan/dissectors/packet-ntlmssp.c(revision 43690)
 +++ epan/dissectors/packet-ntlmssp.c(working copy)
 @@ -2173,7 +2173,7 @@
  col_append_sep_fstr(pinfo-cinfo, COL_INFO, , ,%s,
  val_to_str(ntlmssph-type,
 ntlmssp_message_types,
 -   Unknown message type));
 +   Unknown NTLMSSP message type));

  /* Call the appropriate dissector based on the Message Type */
  switch (ntlmssph-type) {


Hi Richard,

thanks for the suggestion: committed in revision 43713.

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

[Wireshark-dev] Possible bug in dissect_pipe_dcerpc() (packet-smb-pipe.c)

[Pascal Quantin]

Hi all,

while working on fixing a few Clang warnings in packet-smb-pipe.c, I
discovered that the hash_key variable in dissect_pipe_dcerpc() function is
never used.
According to the nice comment Guy put in revision  above the variable
assignment, I have the feeling that it is actually useful in case of
reassembly in both directions and that the following patch should be
applied:

Index: packet-smb-pipe.c
===
--- packet-smb-pipe.c   (révision 44082)
+++ packet-smb-pipe.c   (copie de travail)
@@ -3348,7 +3348,7 @@
 * in this direction, by searching for its reassembly
 * structure.
 */
-   fd_head=fragment_get(pinfo, fid, dcerpc_fragment_table);
+   fd_head=fragment_get(pinfo, hash_key,
dcerpc_fragment_table);
if(!fd_head){
/* No reassembly, so this is a new pdu. check if the
   dissector wants us to reassemble it or if we
@@ -3370,11 +3370,11 @@
   more data ?
*/
if(pinfo-desegment_len){
-   fragment_add_check(d_tvb, 0, pinfo, fid,
+   fragment_add_check(d_tvb, 0, pinfo,
hash_key,
dcerpc_fragment_table,
dcerpc_reassembled_table,
0, reported_len, TRUE);
-   fragment_set_tot_len(pinfo, fid,
+   fragment_set_tot_len(pinfo, hash_key,
dcerpc_fragment_table,
pinfo-desegment_len+reported_len);
}
@@ -3392,7 +3392,7 @@
while(fd_head-next){
fd_head=fd_head-next;
}
-   fd_head=fragment_add_check(d_tvb, 0, pinfo, fid,
+   fd_head=fragment_add_check(d_tvb, 0, pinfo, hash_key,
dcerpc_fragment_table, dcerpc_reassembled_table,
fd_head-offset+fd_head-len,
reported_len, TRUE);
@@ -3426,7 +3426,7 @@
 * up so that we don't have to distinguish between the first
 * pass and subsequent passes?
 */
-   fd_head=fragment_add_check(d_tvb, 0, pinfo, fid,
dcerpc_fragment_table,
+   fd_head=fragment_add_check(d_tvb, 0, pinfo, hash_key,
dcerpc_fragment_table,
dcerpc_reassembled_table, 0, 0, TRUE);
if(!fd_head){
/* we didnt find it, try any of the heuristic dissectors

Am I right or should we remove the hash_key variable?

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

Re: [Wireshark-dev] Possible bug in dissect_pipe_dcerpc() (packet-smb-pipe.c)

[Pascal Quantin]

2012/7/28 Evan Huus eapa...@gmail.com

 On Fri, Jul 27, 2012 at 6:14 PM, Pascal Quantin
 pascal.quan...@gmail.com wrote:
  Hi all,
 
  while working on fixing a few Clang warnings in packet-smb-pipe.c, I
  discovered that the hash_key variable in dissect_pipe_dcerpc() function
 is
  never used.
  According to the nice comment Guy put in revision  above the variable
  assignment, I have the feeling that it is actually useful in case of
  reassembly in both directions and that the following patch should be
  applied:
 
  Index: packet-smb-pipe.c
  ===
  --- packet-smb-pipe.c   (révision 44082)
  +++ packet-smb-pipe.c   (copie de travail)
  @@ -3348,7 +3348,7 @@
   * in this direction, by searching for its reassembly
   * structure.
   */
  -   fd_head=fragment_get(pinfo, fid, dcerpc_fragment_table);
  +   fd_head=fragment_get(pinfo, hash_key,
  dcerpc_fragment_table);
  if(!fd_head){
  /* No reassembly, so this is a new pdu. check if
 the
 dissector wants us to reassemble it or if we
  @@ -3370,11 +3370,11 @@
 more data ?
  */
  if(pinfo-desegment_len){
  -   fragment_add_check(d_tvb, 0, pinfo, fid,
  +   fragment_add_check(d_tvb, 0, pinfo,
  hash_key,
  dcerpc_fragment_table,
  dcerpc_reassembled_table,
  0, reported_len, TRUE);
  -   fragment_set_tot_len(pinfo, fid,
  +   fragment_set_tot_len(pinfo, hash_key,
  dcerpc_fragment_table,
 
 pinfo-desegment_len+reported_len);
  }
  @@ -3392,7 +3392,7 @@
  while(fd_head-next){
  fd_head=fd_head-next;
  }
  -   fd_head=fragment_add_check(d_tvb, 0, pinfo, fid,
  +   fd_head=fragment_add_check(d_tvb, 0, pinfo, hash_key,
  dcerpc_fragment_table, dcerpc_reassembled_table,
  fd_head-offset+fd_head-len,
  reported_len, TRUE);
  @@ -3426,7 +3426,7 @@
   * up so that we don't have to distinguish between the first
   * pass and subsequent passes?
   */
  -   fd_head=fragment_add_check(d_tvb, 0, pinfo, fid,
  dcerpc_fragment_table,
  +   fd_head=fragment_add_check(d_tvb, 0, pinfo, hash_key,
  dcerpc_fragment_table,
  dcerpc_reassembled_table, 0, 0, TRUE);
  if(!fd_head){
  /* we didnt find it, try any of the heuristic dissectors
 
  Am I right or should we remove the hash_key variable?
 
  Regards,
  Pascal.

 I'm not sure what the correct course of action is, but there's already
 a bug for it. I found the same issue with CppCheck a few weeks ago :)

 https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=7451


Hi Evan,

thanks for the reminder: I missed this bug ;)
I guess Guy would be the best able to answer this question (if he remembers
the code he wrote in 2003!).

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

Re: [Wireshark-dev] libxml2-2.dll was not found {was RE: [Wireshark-announce] Wireshark 1.6.9 is now available]

[Pascal Quantin]

Le 27 juil. 2012 à 22:08, JAMES, WARREN wj3...@att.com a écrit :

 Greetings,
 
 We have a problem with Wireshark 1.6.9:
 
 Program fails to start with error: This application has failed to start 
 because libxml2-2.dll was not found.  Re-installing the application may fix 
 the problem.  But reinstalling does not fix it.
 
 
 This is the version downloaded from wireshark
 http://wiresharkdownloads.riverbed.com/wireshark/win32/wireshark-win32-1.6.9.exe
 
 
 
 Multiple users reporting the problem.  I do not know if the 64bit Windows 
 version has the same but it looks like the same as this report:
 http://www.wireshark.org/lists/wireshark-dev/201207/msg00221.html
 
 
 
 Thanks for taking a look!

Hi,

as suggested by Gerald in 
http://www.wireshark.org/lists/wireshark-dev/201207/msg00235.html , could you 
give a try to wireshark-win32-1.6.10pre1-44077 or later from 
http://www.wireshark.org/download/prerelease/ and see if that fixes the issue?

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

Re: [Wireshark-dev] Is Python Still Considered Optional for the Build Process? What Should the Minimum Version Be?

[Pascal Quantin]

Le 31 juil. 2012 à 09:43, Anders Broman anders.bro...@ericsson.com a écrit :

 Hi,
 Others have to comment on whether we require python or not but it would be 
 nice if you attached your script to a bug report so we could have a look at 
 it and have a record of it. I think it should be OK to require python 2.6 as 
 the lowest supported level to make things simpler.
 Best regards
 Anders

Hi,
just for information the Linux development machine I have at work (Debian 
Lenny) is still packaging python 2.5 by default (unfortunately). It would be 
great if we could keep compatibility with older machines.

Regards,
Pascal.

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

Re: [Wireshark-dev] Is Python Still Considered Optional for the Build Process? What Should the Minimum Version Be?

[Pascal Quantin]

Le mardi 31 juillet 2012, Balint Reczey a écrit :

 On 07/31/2012 09:59 AM, Pascal Quantin wrote:

 Le 31 juil. 2012 à 09:43, Anders Broman anders.bro...@ericsson.com
 mailto:anders.bro...@ericsson.com a écrit :

  Hi,
 Others have to comment on whether we require python or not but it would
 be
 nice if you attached your script to a bug report so we could have a look
 at it
 and have a record of it. I think it should be OK to require python 2.6
 as the
 lowest supported level to make things simpler.
 Best regards
 Anders


 Hi,
 just for information the Linux development machine I have at work (Debian
 Lenny)
 is still packaging python 2.5 by default (unfortunately). It would be
 great if
 we could keep compatibility with older machines.

 Regards,
 Pascal.

  Hi Pascal,

 Lenny is oldstable and is not supported even by the Debian Project itself.
 Please upgrade to Squeeze.

 Cheers,
 Balint


Hi Balint,

I would be happy to do so but the IT guys do not share my point of vue ;)
For what it is worth, projects like Mercurial SCM (written mostly in
Python) are still maintaining compatibility with Python 2.4.

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

[Wireshark-dev] Wireshark-commits: [Wireshark-commits] rev 44161: /trunk/epan/dissectors/ /trunk/epan/dissectors/: packet-gmr1_bcch.c packet-gmr1_common.c packet-gmr1_rr.c

[Pascal Quantin]

 http://anonsvn.wireshark.org/viewvc/viewvc.cgi?view=revrevision=44161

 User: mmann
 Date: 2012/07/31 10:19 AM

 Log:
  update GMR-1 protocols display filers

 Directory: /trunk/epan/dissectors/
   ChangesPathAction
   +67 -67packet-gmr1_bcch.c  Modified
   +14 -14packet-gmr1_common.cModified
   +100 -100  packet-gmr1_rr.cModified



Hi Michael,

What is the rationale for this change exactly? So as to please the
check*.pl scripts?
For me it made sense to split big protocols in various files while still
having a common root for filters.
Moreover the rename from gmr1.rr.* to gmr1_ccch.* does not seem valid to me
as the corresponding fields can be received either on CCCH or DCCH channels
(the protocol name gmr1_ccch does not seem well chosen and might be named
gmr1_rr instead).

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

Re: [Wireshark-dev] Wireshark-commits: [Wireshark-commits] rev 44161: /trunk/epan/dissectors/ /trunk/epan/dissectors/: packet-gmr1_bcch.c packet-gmr1_common.c packet-gmr1_rr.c

[Pascal Quantin]

2012/7/31 mman...@netscape.net

  I guess where I (and the .pl script) got tripped up was the fact that
 there were separate protocols registered and they gave the impression they
 were unique and not just one big protocol broken up over several files.
 The script just generates the questionable filters, I was using human
 judgement to determine if the filters actually needed to be changed.
 Looking through the filter names, renaming to gmr1_ccch.* seems to make
 more sense then renaming the protocol to gmr1_rr.  It was all a judgement
 call by me, but I'm happy to admit I'm wrong to someone who knows the
 specific protocols better.  The overall goal is just consistency in display
 filter names (bug 2794), but it can get complicated for the .pl script when
 protocols are broken up over multiple files.


Hi,

the Radio Resource protocol is used both on common and dedicated channels.
Thus the rename to gmr1_ccch instead of gmr1_rr does not seem the best
option to me as it covers only half of the fields (CCCH means Common
Control CHannel).
The same things goes for the changes done in packet-gsm_a_rr.c (I guess
that packet-gmr1_rr.c writing got badly inspired by packet-gsm_a_rr.c). I
will change it so as to reflect more the reality.

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

Re: [Wireshark-dev] packet-rlc.c changes

[Pascal Quantin]

Hi Rishie,

2012/8/3 Rishie Sharma storfiske...@gmail.com

 Hi! I am the one who (through Anders Broman) made changes to RLC. I
 subscribed to the list today to comment on some of the changes.

 Remove a created-but-unused subtree (and its ett).  It's not obvious to
 me  whether this tree was going to be used for something or not.

 I was going to add a subtree so you can filter on the values easily
 (instead of just proto_item_append_text:ing the values) but then I got
 caught up in something else and forgot about it, it's not important.

 I was unaware that packet-catapult-dct2000.c and packet-fp_hint.c also
 use packet-rlc.c. That makes the whole ordeal a bit scarier because I don't
 know what they are and I've made some radical changes to RLC so I've
 probably broken something there like changing variables and such. I saw
 that comment on UDP framing protocol in RLC but to be honest I did not
 understand what it is and what it's used for so if someone who knows
 could try and see how much I've broken so far  that would be great.


I just had a quick look and fixed what seemed the most obvious (like the
removal of the test on ciphered/deciphered variables while they did not
interfere with your own code). I did not verify the changes done related to
reassembly so it would be nice if you could double check this part.
The UDP framing protocol can be used to decode directly a RLC PDU without
having it encapsulated in MAC/FP PDUs. I use it myself to decode PDUs
logged in a UE and after a quick check it seems to be still working.


 With lchid and rbid for me it's just a number that is used to identify a
 sequence in RLC so if you say it is rbid and not lchid it's probably
 correct.


The Logical Channel Identity is used at MAC level while the Radio Bearer
Identity is the entity used in RLC layer (to handle the sequence number,
state variables, ciphering state... per entity) that is mapped on a LCH-ID.
So yes they are different.



 The changes to the ciphering and deciphering are because me and Jacob
 Nordgren are trying around to see if we can actually decrypt an encrypted
 RLC in the RLC code with a KASUMI algorithm implementation and yesterday we
 did have some progress. I am unsure how the copyrights and licenses and
 such work with this though, Jacob wrote the KASUMI by himself following the
 3gpp specification. I wonder, would that be OK to put GPL on and commit to
 the Wireshark SVN?


It would be nice to add it in the epan/crypt folder. I do have myself the
code for SNOW3G and ZUC ciphers and the corresponding integrity and
ciphering algorithms (used for LTE) that I might add to Wireshark also
(Martin, ping me if you are interested).


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

Re: [Wireshark-dev] packet-rlc.c changes

[Pascal Quantin]

Le 3 août 2012 à 12:34, Pascal Quantin pascal.quan...@gmail.com a écrit :

Hi Rishie,

2012/8/3 Rishie Sharma storfiske...@gmail.com

 Hi! I am the one who (through Anders Broman) made changes to RLC. I
 subscribed to the list today to comment on some of the changes.

 Remove a created-but-unused subtree (and its ett).  It's not obvious to
 me  whether this tree was going to be used for something or not.

 I was going to add a subtree so you can filter on the values easily
 (instead of just proto_item_append_text:ing the values) but then I got
 caught up in something else and forgot about it, it's not important.

 I was unaware that packet-catapult-dct2000.c and packet-fp_hint.c also
 use packet-rlc.c. That makes the whole ordeal a bit scarier because I don't
 know what they are and I've made some radical changes to RLC so I've
 probably broken something there like changing variables and such. I saw
 that comment on UDP framing protocol in RLC but to be honest I did not
 understand what it is and what it's used for so if someone who knows
 could try and see how much I've broken so far  that would be great.


I just had a quick look and fixed what seemed the most obvious (like the
removal of the test on ciphered/deciphered variables while they did not
interfere with your own code). I did not verify the changes done related to
reassembly so it would be nice if you could double check this part.

Martin Mathieson might have some dct2000 captures so as to check that
everything is still working as expected. I do not have any myself, so we
will have to rely on someone else to confirm that it is still working as
expected ;)

The UDP framing protocol can be used to decode directly a RLC PDU without
having it encapsulated in MAC/FP PDUs. I use it myself to decode PDUs
logged in a UE and after a quick check it seems to be still working.


 With lchid and rbid for me it's just a number that is used to identify a
 sequence in RLC so if you say it is rbid and not lchid it's probably
 correct.


The Logical Channel Identity is used at MAC level while the Radio Bearer
Identity is the entity used in RLC layer (to handle the sequence number,
state variables, ciphering state... per entity) that is mapped on a LCH-ID.
So yes they are different.



 The changes to the ciphering and deciphering are because me and Jacob
 Nordgren are trying around to see if we can actually decrypt an encrypted
 RLC in the RLC code with a KASUMI algorithm implementation and yesterday we
 did have some progress. I am unsure how the copyrights and licenses and
 such work with this though, Jacob wrote the KASUMI by himself following the
 3gpp specification. I wonder, would that be OK to put GPL on and commit to
 the Wireshark SVN?


It would be nice to add it in the epan/crypt folder. I do have myself the
code for SNOW3G and ZUC ciphers and the corresponding integrity and
ciphering algorithms (used for LTE) that I might add to Wireshark also
(Martin, ping me if you are interested).


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

Re: [Wireshark-dev] packet-rlc.c changes

[Pascal Quantin]

Le 3 août 2012 à 17:25, Christopher Maynard christopher.mayn...@gtech.com a 
écrit :

 Martin Mathieson martin.r.mathieson@... writes:
 
 Martin Mathieson might have some dct2000 captures so as to check that
 everything is still working as expected. I do not have any myself, so we will
 have to rely on someone else to confirm that it is still working as expected 
 ;)
 
 
 Yes I'm not sure anyone is using that support at the moment, or if it
 didn't work, they've quietly given up :(  I don't think I have any of those 
 log
 files to hand, but will try to recreate some when I find the time.  Was 
 thinking
 I'd let the dust settle on your changes so I'd only need to fix things up 
 once.
  I'm happy to see all of this support being added, but I'm not really working
 with 3G any more.
 
 Martin
 
 FYI ... there looks to be some capture files in the menagerie with dct2000
 packets in them.  Thanks to Jakub, you can search for some here:
 http://www.wireshark.org/~darkjames/capture-files.txt

Thanks for the reminder Chris. Unfortunately there is no capture with RLC UMTS 
packets in the menagerie neither on the wiki (the DCT2000 captures are for LTE).

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

[Wireshark-dev] Setup the filter as string instead of frame[start offset:length]

[Pascal Quantin]

Le jeudi 9 août 2012, Kumar, Chandan (Chandan) a écrit :
 
My request as follows:
Could you, please help me to make change in Wireshark so that I would be able 
to select IE by means of filter like others element?
 
I want to make IE’s as a filterable field instead of displaying frame [start 
offset: length]
 
Did some change for this into epan/proto.c file in Wireshark – 1.6.2
Line number6934
 
ptr += g_snprintf(ptr, (gulong) (buf_len-(ptr-*filter)), frame[%d:%d] == , 
finfo-start, length);   
 
this line I have change like
ptr += g_snprintf(ptr, (gulong) (buf_len-(ptr-*filter)),%s == , 
finfo-rep-representation);
 
I am able to see the strings which want to make filterable using (Apply as 
filter --- Selected) but some wrong message windows came  stop the parsing 
for new filter.
Attaching two snap shot 1st with the Wireshark filter  2nd what I have 
implemented.

Hi Chandan,
As indicated by Gilbert your screeshots were not forwarded to the list.
Given the line number you modified, it looks like the field you want to filter 
is defined as FT_NONE. Hacking in proto.c is probably not what you want to do 
and instead you should change the protocol dissector code so as to use a more 
friendly filter format.
If you can share with us more information on the protocol used and field you 
want to filter, we might be able to help you.

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

Re: [Wireshark-dev] Setup the filter as string instead of frame[start offset:length]

[Pascal Quantin]

Le 10 août 2012 à 08:20, Kumar, Chandan (Chandan) 
chandan.ku...@alcatel-lucent.com a écrit :

 Could you, please help me to make change in Wireshark so that I would be able 
 to select IE by means of filter like others element?
  
 I want to make IE’s as a filterable field instead of displaying frame [start 
 offset: length]
  
 I Did some change for this into epan/proto.c file in Wireshark – 1.6.2
 Line number6934
  
 ptr += g_snprintf(ptr, (gulong) (buf_len-(ptr-*filter)), frame[%d:%d] == , 
 finfo-start, length);   
  
 this line I have change like
 ptr += g_snprintf(ptr, (gulong) (buf_len-(ptr-*filter)),%s == , 
 finfo-rep-representation);
  
 I am able to see the strings which want to make filterable using (Apply as 
 filter --- Selected) but some wrong message windows came  stop the parsing 
 for new filter.
  
 What I have to do to display correctly.

Please have a look at the answer I sent yesterday:

Hi Chandan,
As indicated by Gilbert your screeshots were not forwarded to the list.
Given the line number you modified, it looks like the field you want to filter 
is defined as FT_NONE. Hacking in proto.c is probably not what you want to do 
and instead you should change the protocol dissector code so as to use a more 
friendly filter format.
If you can share with us more information on the protocol used and field you 
want to filter, we might be able to help you.

As indicated in README.developer file:
FT_NONE: no field type. Used for fields that aren't given a value, and that 
can only be tested for presence or absence; a field that represents a data 
structure, with a subtree below it containing fields for the members of the 
structure, or that represents an array with a subtree below it containing 
fields for the members of the array, might be an FT_NONE field.

So if I understood your request correctly you should probably change the 
dissector code to define the field to something other than FT_NONE.
What field are you trying to filter?

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

Re: [Wireshark-dev] [Wireshark-commits] rev 44435: /trunk/epan/ /trunk/epan/dissectors/: packet-afp.c packet-ncp2222.inc /trunk/epan/: epan.c expert.c expert.h proto.c proto.h

[Pascal Quantin]

Le 11 août 2012 à 08:26, Joerg Mayer jma...@loplof.de a écrit :

 On Fri, Aug 10, 2012 at 08:33:02PM +, ger...@wireshark.org wrote:
 http://anonsvn.wireshark.org/viewvc/viewvc.cgi?view=revrevision=44435
 
 User: gerald
 Date: 2012/08/10 01:33 PM
 
 Log:
 Make the corresponding packet_info available to each tree item. This
 lets us pass a NULL pinfo to expert_add_info_format() and
 expert_add_undecoded_item(), which makes it possible to use those
 routines deep in the bowels of many dissectors. As a proof of concept
 remove the recent pinfo additions to packet-afp.c. This should also make
 it easier to fix bug 3884.
 
 Does this parameter have any use left? If not we could and should remove it
 throughout the source including the function header.

Hi,
according to my understanding pinfo can be NULL if pi is not NULL. So most of 
the changes done in r1 will lead to an expert info not being displayed at 
all.

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

Re: [Wireshark-dev] Wireshark-commits: [Wireshark-commits] rev 44161: /trunk/epan/dissectors/ /trunk/epan/dissectors/: packet-gmr1_bcch.c packet-gmr1_common.c packet-gmr1_rr.c

[Pascal Quantin]

Le 19 août 2012 à 12:40, Sylvain Munaut 246...@gmail.com a écrit :

 Hi,

 I've just seen those changes (filter names) now and I'm really not
 happy with them ...

 1) I explicitely asked this list for objections against the gmr1.xx vs
 gmr1_xx name and I was told that using gmr1.xx made sense given it's
 always the same protocol. And nobody expressed any view against it and
 Andrew said it was a reasonable choice. Now all saved filters /
 examples / ...would have to be changed for really no good reason.

 2) I would really appreciate if the author of the dissector was at
 least CC'ed when doing changes to the dissector ... This is not the
 first time and in every instance, the original commit had to be
 followed by fixups commits because the patch author seemed to be
 more concerned with removing warnings at all costs than actually doing
 the right fix ...

 Cheers,

Sylvain

Hi Sylvain,

If you check the mailing list archive you will see that I also raised
this issue regarding filter names for protocols split across several
files. See http://www.wireshark.org/lists/wireshark-dev/201207/msg00258.html
for the mail exchange.
So far only Michael and myself have expressed our opinion on those
meta protocols split across several files. Personally I preferred
the previous filter scheme despite the warnings generated by the
checkfiltername.pl script. It would be good if other people were also
giving their feeling (as you did) so that we can decide once for all
whether the dissectors or the script must be changed for this use case
and try to stick to this decision in the future.
Note that the change was done in the development branch only and that
next stable release from this code base is due in a year so we still
have plenty of time to change things.

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

Re: [Wireshark-dev] Why are authors never Cc'ed before their code is changed?

[Pascal Quantin]

2012/8/19 Harald Welte lafo...@gnumonks.org

 Hi all,

 I understand that different FOSS projects have different cultures,
 norms, rules, etc.  However, my experience with wireshark it has reached
 a point where I think a post like this is requierd.

 I don't want to see this as some kind of flame, or to claim that the
 wireshark development model is bad.  I just really don't understand it,
 coming from a different background.  Please help me understand it.

 In other large projects (let's say the Linux kernel), it is customary
 that the original author of code (or a designated maintainer who has
 taken over that particular module) is always Cc'ed before a change to
 his code is being made.

 In wireshark, it has happened repeatedly, that code contributed by
 Osmocom developers (like the GMR dissector of Sylvain Munaut, or my
 GSMTAP dissector) has been modified erroneously (and thus broken)
 without any notice to us.

 I find this at least disturbing (if not annoying) adn am wondering what
 is the benefit of this practise to wireshark or its users?

 It is generally a fair assumption to make that somebody who writes a
 particular dissector actually cares about that code being functional,
 and that he probably knows the respective protocol quite well.  In most
 caess, I would expect that author to be able to review changes to his
 code.

 So why are those authors not Cc'ed in any kind of patches, or merge
 requests to their code?  If you don't want to wait for their explicit
 approval for efficiency reasons, you could at least notify them that
 there was a change to their code that they should review.

 The current situation ends up like this:

 * People like me who just contribute particular dissectors have no time
   to go through all of the committlog or read all of the mailing list.

 * Somebody else quietly makes a change, without discussing the change
   beforehand, without Cc'ing the proposed change to us

 * A wireshark developer committs that patch, again without Cc'ing the
   original author

 * Wireshark ends up being broken for the given protocol

 * This is not discovered for a long time, until one of the few 'bleedign
   edge' users of those protocols discovers a problem and finds the time
   to report it, at which point we get the complaint about something not
   working and have to go back in history.

 I would like to raise the following questions:

 1) Is this the way how the wireshark development model / flow is
supposed to work ?

 2) If yes, do you really think that the gain in flexibilty caused by
 this anarchy overweighs the benefit of having dissector-authors give
 timely feedback to proposed changes, or prevent breakage?

 3) Do you have any idea how to improve this situation?

 4) How do other wireshark dissector authors deal with this problem?

 Thanks in advance!

 Regards,
 Harald


Hi Harald,

I can fully understand you concern and the warning you put in
packet-gsmtap.* files (following several changes done without notice to
Osmocom guys) has been a good step forward. As far as I know the GSMTAP
compatibility has not been broken since and this notice prevented new
breakage (see bug 7615 comments for example). Did you have any major issue
since this warning was put in place (except the filter rename Sylvain
raised)?

For me not all changes have the same potential of breakage: a change in an
API used by an external tool can easily lead to a complete incompatibility
(GSMTAP format unapproved changes for example) while a filter rename or a
wrong subtree used to display a field (GMR-1 breakages seen lately) are
just an annoyance (unless you have an external tool configuring filters
by command line?).
I agree that this massive filter rename could / should have been discussed
before being done, and for me things can still be changed as it is only
done in the development tree (see my reply to Sylvain). That said, applying
general rules (like filter names) to the whole code base once defined
should have precedence over a single developer feelings.

I can see different type of commits:
- enhancement / fix for an existing dissector. This case is easier to
handle and adding an original author in copy is a good idea when you have a
single contributor to a given dissector (your use case). It can become much
more complex when you have several authors across the years... If you check
bugzilla, you will see that checking with an original author is sometimes
done, depending on the knowledge of the reviewer for this given protocol
and the impact of the change. This is not a golden rule though.
- general code cleaning spreading across several files. Usually it should
not impact the dissector usability while complying with the coding style.
Getting in touch with any contributor simply because a given Wireshark
internal API gets deprecated and replaced by another one is not doable from
my point of vue. When the changes are related to warnings removal (if I
remember correctly it 

Re: [Wireshark-dev] Wireshark-commits: [Wireshark-commits] rev 44161: /trunk/epan/dissectors/ /trunk/epan/dissectors/: packet-gmr1_bcch.c packet-gmr1_common.c packet-gmr1_rr.c

[Pascal Quantin]

2012/8/20 mman...@netscape.net

 Sylvain,

 The checkdisplayfilter.pl script reflects my interpretation of the
 desired display filter format, and since there hasn't been that much
 feedback on the outputted results (with Pascal's comments on the GSM
 dissectors being the exception), I continue to plod along manually checking
 and possibly updating dissectors as they show up in the list.  It's not set
 in stone, but lacking any officially documented rules, I thought it was
 turning into the defacto standard.  I'm more than willing to adapt the
 script, I just want the consistency expressed in bug 2794.  The problem may
 be defining consistent.

 I definitely struggled with the GMR-1 filters (whether they or the script
 should be changed), and that's one of the main reasons I intentionally made
 the change its own revision (makes reverting a little easier).  I got the
 impression that the GMR-1 protocols were more a grouping of protocols
 (like the ZigBee or SCSI protocols), than subdissectors, which is why I
 went with the underscore separator over the period.  I don't see where most
 users would notice it because you shouldn't see much of a difference in the
 autocompletion when typing in a display filter since the
 subdissectors of common / rr / cc would still be at the top of the list.
 The CCCH stuff (which appears to be an obvious mistake) came from either
 another similar dissector architecture, the protocol filter name or the
 naming of the hf_ variables in the registration array (where I found a
 common theme using their names).

 The GMR-1 protocol follows one of the biggest reasons for the script -
 ensuring display filter names start with the protocol filter name,
 followed by a period.  The problem I have is that I don't like the idea of
 having a period in the protocol filter name itself.  This check hasn't
 been added to the script yet (maybe even to the protocol registration code
 itself), but I have certainly considered it.  To me a period in the
 protocol filter name adds some confusion to what's being autocompleted
 and also suggests that a protocol may have been architected with multiple
 dissectors to (unnecessarily) break the code up into multiple source
 modules (for strictly reasons of size).  Multiple source modules for a
 protocol is somewhat discouraged as there are already 1000+ dissector files
 (with some larger than the totality of the GMR-1 code).  If the GMR-1
 protocol was implemented in a single dissector/file, the
 checkdisplayfilter.pl script wouldn't have complained about the
 subfilters of common / rr / cc.


GMR-1 dissectors, like GSM-A dissectors, can be seen either as separate
protocols belonging to the same family, or as a single protocol with sub
dissectors:it depends a bit on your point of view :) Personnally I see them
as a single one (like Sylvain) and was rather happy with the '.' separator
instead of '_' one.
For example at the beginning in Wireshark there was a single packet-gsm_a.c
file that became huge and was split into several files in r25915 and r25917.
When looking at checkfiltername.pl script, it looks like there are already
variants allowed for PROTOABBREV ('-' vs '_' for example). Would allowing
'.' vs '_' really be an issue? If think it would make sense for big
protocols like GSM or GMR-1 (and there is maybe a few other ones). If
accepted, we should be careful when reviewing patches to ensure that this
capability is not used without any valuable reason.

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

Re: [Wireshark-dev] Why are authors never Cc'ed before their code is changed?

[Pascal Quantin]

2012/8/19 Lori Jakab l...@lispmob.org

 On 08/19/12 06:56, Pascal Quantin wrote:
  Having a RSS link (or something similar) to the subversion file log
  (
 http://anonsvn.wireshark.org/viewvc/trunk/epan/dissectors/packet-gsmtap.c?view=log
  for example) could be a way to easily monitor the changes done to a
  given file for whoever is interested. Of course it would not prevent
  the offending commit but it would allow a faster feedback / bugfix if
  needed (which could be sufficient from my point of vue). Would it be
  an acceptable first step towards improving the monitoring for changes
  by original authors / contributors?

 I think that some kind of automatic and *opt-in* method to notify the
 author(s) of a certain dissector that changes have been made to their
 code should be available. Both the special header field proposed by Evan
 (watch) and Sylvain (maintainer) and the RSS feed would fulfill
 this. And they are not mutually exclusive either. RSS would allow
 interested non-authors as well to easily follow changes, while the
 maintainer option could be integrated with bugzilla so that authors are
 automatically CC'ed on patches submitted for files they maintain.


Hi,

it appears that Wireshark git mirror (http://http://code.wireshark.org/git/)
already has RSS / Atom links (thanks for the hint Jakub ;) ). So whoever is
interested can already subscribe to feeds.
To get the full commit history you can use:
http://code.wireshark.org/git/?p=wireshark;a=atom
http://code.wireshark.org/git/?p=wireshark;a=rss
And to follow a specific file, you can use the 'f' parameter:

http://code.wireshark.org/git/?p=wireshark;a=atom;f=epan/dissectors/packet-gmr1_bcch.c

http://code.wireshark.org/git/?p=wireshark;a=rss;f=epan/dissectors/packet-gmr1_bcch.c

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

Re: [Wireshark-dev] http://anonsvn issues

[Pascal Quantin]

2012/8/27 Jeff Morriss jeff.morriss...@gmail.com

 Hi Gerald,

 I noticed that looking at a revision by pointing my web browser at
 http://anonsvn.wireshark.org/viewvc?revision=Xview=revision doesn't look
 very good today (fonts are big, spacing seems to be off).  More troubling
 is I'm not getting any colors on the diff to previous page (which makes
 it very hard to tell what's changed).


 Hi Jeff,
it's working fine for me (Firefox 14.0.1 both on Linux and Windows). But I
can get the same wrong display as you if I explicitly deactivate the style
in the menu (View - Page Style - No style). Could you check your browser
configuration?

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

Re: [Wireshark-dev] Problems with regenerating lppe dissector

[Pascal Quantin]

2012/9/10 Jakub Zawadzki darkjames...@darkjames.pl

 Hi,

 I'm trying to regenerate packet-lppe.c from asn1/lppe using command:
   ../../tools/asn2wrs.py -p lppe -c ./lppe.cnf -s ./packet-lppe-template
 -D . -O ../../epan/dissectors LPPe.asn

 Regenerated version doesn't compiles:

 ../../asn1/lppe/packet-lppe-fn.c:868:77: error: use of undeclared
 identifier 'dissect_LPP_PDU_Definitions_GNSS_ID_Bitmap'
   { hf_lppe_gnssTimeReference, ASN1_EXTENSION_ROOT, ASN1_OPTIONAL
  , dissect_LPP_PDU_Definitions_GNSS_ID_Bitmap },
 ../../asn1/lppe/packet-lppe-fn.c:1153:75: error: use of undeclared
 identifier 'dissect_LPP_PDU_Definitions_GNSS_ID'
   { hf_lppe_gnss_ID, ASN1_EXTENSION_ROOT, ASN1_NOT_OPTIONAL,
 dissect_LPP_PDU_Definitions_GNSS_ID },
 ...

 Looking at diff, I have lot of identifier renames, like:
 -  { hf_lppe_gnssTimeReference, ASN1_EXTENSION_ROOT, ASN1_OPTIONAL
  , dissect_lpp_GNSS_ID_Bitmap },
 +  { hf_lppe_gnssTimeReference, ASN1_EXTENSION_ROOT, ASN1_OPTIONAL
  , dissect_LPP_PDU_Definitions_GNSS_ID_Bitmap },
 -  { hf_lppe_ccpAssistanceSuppport, ASN1_EXTENSION_ROOT,
 ASN1_OPTIONAL, dissect_lpp_GNSS_SignalIDs },
 +  { hf_lppe_ccpAssistanceSuppport, ASN1_EXTENSION_ROOT,
 ASN1_OPTIONAL, dissect_LPP_PDU_Definitions_GNSS_SignalIDs },
 ...

 and hf types changes:
{ eARFCN, lppe.eARFCN,
 -FT_UINT32, BASE_DEC, NULL, 0,
 +FT_NONE, BASE_NONE, NULL, 0,
{ dl-CarrierFreq, lppe.dl_CarrierFreq,
 -FT_UINT32, BASE_DEC, NULL, 0,
 +FT_NONE, BASE_NONE, NULL, 0,
 ...

 I really need to change only one line:

 -static int dissect_OMA_LPPe_MessageExtension_PDU(tvbuff_t *tvb _U_,
 packet_info *pinfo _U_, proto_tree *tree _U_) {
 +static int dissect_OMA_LPPe_MessageExtension_PDU(tvbuff_t *tvb _U_,
 packet_info *pinfo _U_, proto_tree *tree _U_, void *data _U_) {

 So I'll commit only this line change, but it'd be great if someone could
 look at it.


Hi Jakub,

I'll take care of it later today (as I added both LPP and LPPe dissectors
to the tree, I hope I will be able to figure out what's happening ;) ).

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

Re: [Wireshark-dev] Problems with regenerating lppe dissector

[Pascal Quantin]

2012/9/10 Pascal Quantin pascal.quan...@gmail.com

 2012/9/10 Jakub Zawadzki darkjames...@darkjames.pl

 Hi,

 I'm trying to regenerate packet-lppe.c from asn1/lppe using command:
   ../../tools/asn2wrs.py -p lppe -c ./lppe.cnf -s ./packet-lppe-template
 -D . -O ../../epan/dissectors LPPe.asn

 Regenerated version doesn't compiles:

 ../../asn1/lppe/packet-lppe-fn.c:868:77: error: use of undeclared
 identifier 'dissect_LPP_PDU_Definitions_GNSS_ID_Bitmap'
   { hf_lppe_gnssTimeReference, ASN1_EXTENSION_ROOT, ASN1_OPTIONAL
  , dissect_LPP_PDU_Definitions_GNSS_ID_Bitmap },
 ../../asn1/lppe/packet-lppe-fn.c:1153:75: error: use of undeclared
 identifier 'dissect_LPP_PDU_Definitions_GNSS_ID'
   { hf_lppe_gnss_ID, ASN1_EXTENSION_ROOT, ASN1_NOT_OPTIONAL,
 dissect_LPP_PDU_Definitions_GNSS_ID },
 ...

 Looking at diff, I have lot of identifier renames, like:
 -  { hf_lppe_gnssTimeReference, ASN1_EXTENSION_ROOT, ASN1_OPTIONAL
  , dissect_lpp_GNSS_ID_Bitmap },
 +  { hf_lppe_gnssTimeReference, ASN1_EXTENSION_ROOT, ASN1_OPTIONAL
  , dissect_LPP_PDU_Definitions_GNSS_ID_Bitmap },
 -  { hf_lppe_ccpAssistanceSuppport, ASN1_EXTENSION_ROOT,
 ASN1_OPTIONAL, dissect_lpp_GNSS_SignalIDs },
 +  { hf_lppe_ccpAssistanceSuppport, ASN1_EXTENSION_ROOT,
 ASN1_OPTIONAL, dissect_LPP_PDU_Definitions_GNSS_SignalIDs },
 ...

 and hf types changes:
{ eARFCN, lppe.eARFCN,
 -FT_UINT32, BASE_DEC, NULL, 0,
 +FT_NONE, BASE_NONE, NULL, 0,
{ dl-CarrierFreq, lppe.dl_CarrierFreq,
 -FT_UINT32, BASE_DEC, NULL, 0,
 +FT_NONE, BASE_NONE, NULL, 0,
 ...

 I really need to change only one line:

 -static int dissect_OMA_LPPe_MessageExtension_PDU(tvbuff_t *tvb _U_,
 packet_info *pinfo _U_, proto_tree *tree _U_) {
 +static int dissect_OMA_LPPe_MessageExtension_PDU(tvbuff_t *tvb _U_,
 packet_info *pinfo _U_, proto_tree *tree _U_, void *data _U_) {

 So I'll commit only this line change, but it'd be great if someone could
 look at it.


 Hi Jakub,

 I'll take care of it later today (as I added both LPP and LPPe dissectors
 to the tree, I hope I will be able to figure out what's happening ;) ).

 Regards,
 Pascal.


Hi Jakub,

LPPe dissector has a dependency to LPP dissector. To generate it, you must
first generate lpp-exp.cnf file. This is handled in the Makefile.common
file found in asn1/lppe:

EXTRA_CNF = \
$(builddir)/../lpp/lpp-exp.cnf

$(builddir)/../lpp/lpp-exp.cnf:
(cd $(builddir)/../lpp  $(MAKE_CNF_EXPORT))

Using make instead of executing the asn2wrs.py script directly should allow
you to generate the dissector without errors.

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

Re: [Wireshark-dev] gsm decode flow

[Pascal Quantin]

2012/9/19 pingu kool gsmandv...@gmail.com

 hi list, I want to understand the source flow of gsm dissector, I tried to
 search in, but got confused regarding actual flow happening at the time of
 dissection, can anybody help me in this.
 Thanks in advance..


Hi,

assuming you are talking about the dissection of DTAP messages (RR, MM, CC,
GMM, SM, ...), the entry point is the gsm_dtap dissector found in
packet-gsm_a_dtap.c file.
Then depending on the Protocol Discriminator, the dissect_dtap function
selects the right ett, hf, and arrays to be used for dissection.

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

Re: [Wireshark-dev] RRC filters

[Pascal Quantin]

Hi Lucio,

2012/9/25 Lucio Di Giovannantonio lucio.digiovannanto...@gmail.com

 Hello to everybody, I've found something strange in rrc filters
 expression, in several cases the same filter abbreviation have different
 type, this can be a problem and/or can cause a crash?

 for example:

 { hf_rrc_criticalExtensions_**117,
   { criticalExtensions, rrc.criticalExtensions,
 FT_UINT32, BASE_DEC, VALS(rrc_T_criticalExtensions_**117_vals), 0,
 T_criticalExtensions_117, HFILL }},

 and

 { hf_rrc_criticalExtensions_**118,
   { criticalExtensions, rrc.criticalExtensions,
 FT_NONE, BASE_NONE, NULL, 0,
 T_criticalExtensions_118, HFILL }},


This is a side effect of the code auto generated from the ASN.1
description. I proposed a workaround in bug 2402 comment #14.
With it, the filters become:
{ hf_rrc_criticalExtensions_117,
  { criticalExtensions, rrc.criticalExtensions,
FT_UINT32, BASE_DEC, VALS(rrc_T_criticalExtensions_117_vals), 0,
T_criticalExtensions_117, HFILL }},

and

{ hf_rrc_criticalExtensions_118,
  { criticalExtensions, rrc.criticalExtensions_label,
FT_NONE, BASE_NONE, NULL, 0,
T_criticalExtensions_118, HFILL }},

But I'm not really satisfied with the _label extension and could not come
up to a better wording, so did not commit it. Any comment / suggestion is
welcome :)

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

Re: [Wireshark-dev] RRC filters

[Pascal Quantin]

2012/9/25 Anders Broman anders.bro...@ericsson.com

 **


  --
 *From:* wireshark-dev-boun...@wireshark.org [mailto:
 wireshark-dev-boun...@wireshark.org] *On Behalf Of *Pascal Quantin
 *Sent:* den 25 september 2012 16:35
 *To:* Developer support list for Wireshark
 *Subject:* Re: [Wireshark-dev] RRC filters

 Hi Lucio,

 2012/9/25 Lucio Di Giovannantonio lucio.digiovannanto...@gmail.com

 Hello to everybody, I've found something strange in rrc filters
 expression, in several cases the same filter abbreviation have different
 type, this can be a problem and/or can cause a crash?

 for example:

 { hf_rrc_criticalExtensions_**117,
   { criticalExtensions, rrc.criticalExtensions,
 FT_UINT32, BASE_DEC, VALS(rrc_T_criticalExtensions_**117_vals),
 0,
 T_criticalExtensions_117, HFILL }},

 and

 { hf_rrc_criticalExtensions_**118,
   { criticalExtensions, rrc.criticalExtensions,
 FT_NONE, BASE_NONE, NULL, 0,
 T_criticalExtensions_118, HFILL }},


 This is a side effect of the code auto generated from the ASN.1
 description. I proposed a workaround in bug 2402 comment #14.
 With it, the filters become:
 { hf_rrc_criticalExtensions_117,
   { criticalExtensions, rrc.criticalExtensions,
 FT_UINT32, BASE_DEC, VALS(rrc_T_criticalExtensions_117_vals), 0,
 T_criticalExtensions_117, HFILL }},

 and

 { hf_rrc_criticalExtensions_118,
   { criticalExtensions, rrc.criticalExtensions_label,
 FT_NONE, BASE_NONE, NULL, 0,
 T_criticalExtensions_118, HFILL }},

 But I'm not really satisfied with the _label extension and could not come
 up to a better wording, so did not commit it. Any comment / suggestion is
 welcome :)

 Regards,
 Pascal.

 Is this due to duplicated field names? If so one could try to rename
 them, but as I remember there is lots...


Yes this is due to the duplicated field names. Renaming all of them is a
nightmare... That's why my patch was addressing the worst case (FT_NONE vs
everything else). It will not cover all cases for sure, but it was a bit
better than nothing...
___
Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org
Archives:http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] RRC filters

[Pascal Quantin]

2012/9/25 Lucio Di Giovannantonio lucio.digiovannanto...@gmail.com


 Hi pascal, thank you for your resply, maybe container could be better?

 Regards
 Lucio


Hi Lucio,

thanks for your suggestion, I like it. I will wait a few days to see if
someone suggests a better wording (or a better approach than my patch
proposal in bug 2402 comment 10) and then commit it.

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

Re: [Wireshark-dev] RRC filters

[Pascal Quantin]

2012/9/26 Anders Broman a.bro...@bredband.net

  Pascal Quantin skrev 2012-09-26 19:41:



 2012/9/25 Lucio Di Giovannantonio lucio.digiovannanto...@gmail.com


 Hi pascal, thank you for your resply, maybe container could be better?

 Regards
 Lucio


 Hi Lucio,

 thanks for your suggestion, I like it. I will wait a few days to see if
 someone suggests a better wording (or a better approach than my patch
 proposal in bug 2402 comment 10) and then commit it.

 Regards,
 Pascal.

 For fields like this
 { hf_rrc_dl_UM_RLC_Mode_01,
   { dl-UM-RLC-Mode, rrc.dl_UM_RLC_Mode,
 FT_NONE, BASE_NONE, NULL, 0,
 DL_UM_RLC_Mode_r5, HFILL }},
 { hf_rrc_dl_UM_RLC_Mode_02,
   { dl-UM-RLC-Mode, rrc.dl_UM_RLC_Mode,
 FT_NONE, BASE_NONE, NULL, 0,
 DL_UM_RLC_Mode_r6, HFILL }},

 Using the blurb or dl_UM_RLC_Mode_01 should be better than the current
 scheme.


Thanks for the suggestion Anders. I will explore using the blurb and
falling back to _container when no blub is available and see what it gives.

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

Re: [Wireshark-dev] Do Windows compilers require WS_VAR_IMPORT in .h files

[Pascal Quantin]

2012/9/28 Joerg Mayer jma...@loplof.de

 Hello,

 I'm working on building wireshark with gcc with -fvisibility=hidden. This
 will mostly mimic the behaviour already on Windows. The gcc attribute
 to change the visibility causes errors when used in .h files (well, in
 declarations without a  the object).
 I have replaced WS_VAR_IMPORT with extern in .h files. Can someone on
 Windows
 please test whether this still works?


Hi Jörg,

it fails with the following errors (MSVC2010EE 32 bits):

link -dll /out:profinet.dll /NOLOGO /INCREMENTAL:no /DEBUG
/MACHINE:x86 /SafeSEH /DYNAMICBASE /FIXED:no  packet-dcerpc-pn-io.obj
packet-dcom-cba.obj  packet-dcom-cba-acco.obj  packet-pn-dcp.obj
packet-pn-mrp.obj  packet-pn-mrrt.obj  packet-pn-ptcp.obj  packet-pn-rt.obj
packet-pn.obj plugin.obj ..\..\epan\libwireshark.lib
D:\dev\wireshark-win32-libs\gtk2\lib\glib-2.0.lib
D:\dev\wireshark-win32-libs\gtk2\lib\gmodule-2.0.lib
D:\dev\wireshark-win32-libs\gtk2\lib\gobject-2.0.lib profinet.res
   Creating library profinet.lib and object profinet.exp
packet-dcom-cba.obj : error LNK2001: unresolved external symbol
_dcom_hresult_vals
packet-dcom-cba-acco.obj : error LNK2019: unresolved external symbol
_dcom_hresult_vals referenced in function _dissect_CBA_Connection_Data
packet-dcom-cba-acco.obj : error LNK2001: unresolved external symbol
_dcom_variant_type_vals
profinet.dll : fatal error LNK1120: 2 unresolved externals
NMAKE : fatal error U1077: 'C:\Program Files (x86)\Microsoft Visual Studio
10.0\VC\BIN\link.EXE' : return code '0x460'
Stop.
NMAKE : fatal error U1077: 'C:\Program Files (x86)\Microsoft Visual Studio
10.0\VC\BIN\nmake.exe' : return code '0x2'
Stop.
NMAKE : fatal error U1077: 'C:\Program Files (x86)\Microsoft Visual Studio
10.0\VC\BIN\nmake.exe' : return code '0x2'
Stop.
NMAKE : fatal error U1077: 'C:\Program Files (x86)\Microsoft Visual Studio
10.0\VC\BIN\nmake.exe' : return code '0x2'
Stop.

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

Re: [Wireshark-dev] Do Windows compilers require WS_VAR_IMPORT in .h files

[Pascal Quantin]

Hi Jörg,

2012/9/28 Joerg Mayer jma...@loplof.de

 Hello Pascal,

 On Fri, Sep 28, 2012 at 05:25:41PM +0200, Pascal Quantin wrote:
  2012/9/28 Joerg Mayer jma...@loplof.de
   I'm working on building wireshark with gcc with -fvisibility=hidden.
 This
   will mostly mimic the behaviour already on Windows. The gcc attribute
   to change the visibility causes errors when used in .h files (well, in
   declarations without a  the object).
   I have replaced WS_VAR_IMPORT with extern in .h files. Can someone on
   Windows
   please test whether this still works?
 
  it fails with the following errors (MSVC2010EE 32 bits):

 Can you please apply the attached patch on top of the previous one to check
 whether this fixed the compile problem in packet-dcom.c?
 If it does, I will rework the whole patch in the same manner.


It does not work:
packet-dcom.c
packet-dcom.c(473) : error C2054: '(' attendu après 'WS_VAL_IMPORT'
packet-dcom.c(473) : error C2082: redéfinition du paramètre formel
'dcom_variant_type_vals'
packet-dcom.c(473) : error C2143: erreur de syntaxe : absence de ';' avant
'='
packet-dcom.c(522) : error C2054: '(' attendu après 'WS_VAL_IMPORT'
packet-dcom.c(522) : error C2082: redéfinition du paramètre formel
'dcom_hresult_vals'
packet-dcom.c(522) : error C2143: erreur de syntaxe : absence de ';' avant
'='
which would roughly translate as:
packet-dcom.c(473) : error C2054: '(' expected after 'WS_VAL_IMPORT'
packet-dcom.c(473) : error C2082: redefiniton of formal parameter
'dcom_variant_type_vals'
packet-dcom.c(473) : error C2143: syntax error: missing ';' before '='
packet-dcom.c(522) : error C2054: '(' expected after 'WS_VAL_IMPORT'
packet-dcom.c(522) : error C2082: redefinition of formal parameter
'dcom_hresult_vals'
packet-dcom.c(522) : error C2143: syntax error: missing ';' before '='

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

Re: [Wireshark-dev] RRC filters

[Pascal Quantin]

2012/9/27 Pascal Quantin pascal.quan...@gmail.com

 2012/9/26 Anders Broman a.bro...@bredband.net

  Pascal Quantin skrev 2012-09-26 19:41:



 2012/9/25 Lucio Di Giovannantonio lucio.digiovannanto...@gmail.com


 Hi pascal, thank you for your resply, maybe container could be better?

 Regards
 Lucio


 Hi Lucio,

 thanks for your suggestion, I like it. I will wait a few days to see if
 someone suggests a better wording (or a better approach than my patch
 proposal in bug 2402 comment 10) and then commit it.

 Regards,
 Pascal.

 For fields like this
 { hf_rrc_dl_UM_RLC_Mode_01,
   { dl-UM-RLC-Mode, rrc.dl_UM_RLC_Mode,
 FT_NONE, BASE_NONE, NULL, 0,
 DL_UM_RLC_Mode_r5, HFILL }},
 { hf_rrc_dl_UM_RLC_Mode_02,
   { dl-UM-RLC-Mode, rrc.dl_UM_RLC_Mode,
 FT_NONE, BASE_NONE, NULL, 0,
 DL_UM_RLC_Mode_r6, HFILL }},

 Using the blurb or dl_UM_RLC_Mode_01 should be better than the current
 scheme.


 Thanks for the suggestion Anders. I will explore using the blurb and
 falling back to _container when no blub is available and see what it gives.


Using the examples given by Lucio and Anders and the following patch:
Index: tools/asn2wrs.py
===
--- tools/asn2wrs.py(révision 45206)
+++ tools/asn2wrs.py(copie de travail)
@@ -1581,7 +1581,13 @@
   else:
 blurb = '%s' % (t)
   attr = self.eth_hf[f]['attr'].copy()
-  attr['ABBREV'] = '%s.%s' % (self.proto, attr['ABBREV'])
+  if attr['TYPE'] == 'FT_NONE':
+if blurb != 'NULL' and (attr['ABBREV'].lower() in t.lower()):
+  attr['ABBREV'] = '%s.%s_type' % (self.proto, t)
+else:
+  attr['ABBREV'] = '%s.%s_type' % (self.proto, attr['ABBREV'])
+  else:
+attr['ABBREV'] = '%s.%s' % (self.proto, attr['ABBREV'])
   if 'BLURB' not in attr:
 attr['BLURB'] = blurb
   fx.write('{ %s,\n' % (self.eth_hf[f]['fullname']))

the filters become:

{ hf_rrc_criticalExtensions_117,
   { criticalExtensions, rrc.criticalExtensions,
FT_UINT32, BASE_DEC, VALS(rrc_T_criticalExtensions_117_vals), 0,
T_criticalExtensions_117, HFILL }},
{ hf_rrc_criticalExtensions_118,
  { criticalExtensions, rrc.T_criticalExtensions_118_type,
FT_NONE, BASE_NONE, NULL, 0,
T_criticalExtensions_118, HFILL }},
{ hf_rrc_dl_UM_RLC_Mode_01,
  { dl-UM-RLC-Mode, rrc.DL_UM_RLC_Mode_r5_type,
FT_NONE, BASE_NONE, NULL, 0,
DL_UM_RLC_Mode_r5, HFILL }},
{ hf_rrc_dl_UM_RLC_Mode_02,
  { dl-UM-RLC-Mode, rrc.DL_UM_RLC_Mode_r6_type,
FT_NONE, BASE_NONE, NULL, 0,
DL_UM_RLC_Mode_r6, HFILL }},

For now I just systematically rename the FT_NONE filters are those are the
one triggering the most incompatible filters. For consistency I was
thinking about systematically adding _type at the end of the filter
(whether we are using the blurb for better filter name or not).
Being a Python newbie, I guess there would be a much smarter way to rename
the filters only if they are using conflicting types but I do not have the
time to look at it right now. Anyone willing to continue working on it is
welcome.

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

Re: [Wireshark-dev] r45266: proto_tree_add_uint_format_value(..., value, ..., value + 1)

[Pascal Quantin]

Hi Jakub,

2012/10/3 Jakub Zawadzki darkjames...@darkjames.pl

 Hi,

 part of r45266 (or 6427287[1]):

 #v+
 -  proto_tree_add_item(tf_tree, hf_gsm_a_sm_tft_pkt_flt_id, tvb,
 curr_offset, 1, ENC_BIG_ENDIAN);
 +  oct = tvb_get_guint8(tvb, curr_offset)  0x0f;
 +  proto_tree_add_uint_format_value(tf_tree, hf_gsm_a_sm_tft_pkt_flt_id,
 tvb, curr_offset, 1, oct, %d, oct+1);
 #v-

 Now user type display filter: 'gsm_a.gm.sm.tft.pkt_flt_id == 4',
 later he checks the value in tree and there is 5.

 I'm not sure if it's odd only for me (have not read 3GPP 27.007) or if it
 could confuse all the users,
 also familiar with this specification.

 [1]
 http://code.wireshark.org/git/?p=wireshark;a=commitdiff;h=64272873f088a62b8db71e23e0e38c5c8d80194d


a packet filter identifier goes from 1 to 16 but is encoded on 4 bits, thus
my modification. But I understand the confusion it can create when applying
a filter. I could add the raw value in parenthesis (as we do for value
string arrays) to make things a bit clearer. What do you think? Any other
suggestion?

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

Re: [Wireshark-dev] r45266: proto_tree_add_uint_format_value(..., value, ..., value + 1)

[Pascal Quantin]

Hi,

2012/10/3 Jakub Zawadzki darkjames...@darkjames.pl

 Hi Pascal,

 On Wed, Oct 03, 2012 at 10:36:47AM +0200, Pascal Quantin wrote:
  2012/10/3 Jakub Zawadzki darkjames...@darkjames.pl
 
   Hi,
  
   part of r45266 (or 6427287[1]):
  
   #v+
   -  proto_tree_add_item(tf_tree, hf_gsm_a_sm_tft_pkt_flt_id, tvb,
   curr_offset, 1, ENC_BIG_ENDIAN);
   +  oct = tvb_get_guint8(tvb, curr_offset)  0x0f;
   +  proto_tree_add_uint_format_value(tf_tree,
 hf_gsm_a_sm_tft_pkt_flt_id,
   tvb, curr_offset, 1, oct, %d, oct+1);
   #v-
  
   Now user type display filter: 'gsm_a.gm.sm.tft.pkt_flt_id == 4',
   later he checks the value in tree and there is 5.
  
   I'm not sure if it's odd only for me (have not read 3GPP 27.007) or if
 it
   could confuse all the users,
   also familiar with this specification.
  
   [1]
  
 http://code.wireshark.org/git/?p=wireshark;a=commitdiff;h=64272873f088a62b8db71e23e0e38c5c8d80194d
  
 
  a packet filter identifier goes from 1 to 16 but is encoded on 4 bits,
 thus
  my modification.

  But I understand the confusion it can create when applying
  a filter. I could add the raw value in parenthesis (as we do for value
  string arrays) to make things a bit clearer.
  What do you think? Any other suggestion?

 Still I don't understand why you decided to have different values for tree
 and filter.
 Why not:
   proto_tree_add_uint(tf_tree, hf_gsm_a_sm_tft_pkt_flt_id, tvb,
 curr_offset, 1, oct + 1); ?


That's what I did first but in that case the bit string displayed before
the filter name does not correspond to the real bit string of the message
in the hex pane:
 0010 = Packet filter identifier: 2
while the byte in the hex pane ix 0x31.
I found it even more confusing.

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

Re: [Wireshark-dev] Wireshark 1.8.3 problem - OOPS: dissector table sctp.ppi doesn't exist

[Pascal Quantin]

2012/10/4 Petr Sumbera petr.sumb...@oracle.com

 Hi,

 any idea what is wrong? Wireshark 1.8.2 didn't report this.

 tshark -v
 OOPS: dissector table sctp.ppi doesn't exist
 Protocol being registered is Datagram Transport Layer Security
 TShark 1.8.3 (SVN Rev 45256 from /trunk-1.8)

 Copyright 1998-2012 Gerald Combs ger...@wireshark.org and contributors.
 ...

 This seems to be related to 44501.


Hi Petr,
see bug 7784: https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=7784

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

Re: [Wireshark-dev] error while doing make rpm-package on wireshark latest trunk

[Pascal Quantin]

[Back to -dev mailing list]

2012/10/7 P Gyanesh Patra c3m3gyan...@gmail.com


  just need one info..
 i am compiling wireshark on centos6.1 64bit..
 while doing make rpm-package i am getting following error:

 make[1]: Entering directory `/root/wireshark-svn/wireshark/ui/qt'
 uic main_welcome.ui -o ui_main_welcome.h
 make[1]: uic: Command not found
 make[1]: *** [ui_main_welcome.h] Error 127
 make[1]: Leaving directory `/root/wireshark-svn/wireshark/ui/qt'
 make: *** [distdir] Error 1
 Please tell me what package i need to install as i have tried to search a
 lot but still unable to fix it.
 Gyanesh


 Hi Gyanesh,

uic is the Qt user interface compiler (used to build qtShark, a new GUI
based on Qt framework). So you need to install the Qt packages for CentOS.
Not sure why the compilation of qtShark is part of the make rpm-package
though as I have never built such package myself. Maybe someone else can
give an advice.

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

Re: [Wireshark-dev] [Wireshark-bugs] [Bug 5284] new_packet_list: redissection + redraw crashes when multi-data-source packet is selected

[Pascal Quantin]

Hi Evan,

2012/10/8 bugzilla-dae...@wireshark.org

 https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=5284

 Evan Huus eapa...@gmail.com changed:

What|Removed |Added

 
  Status|NEW |RESOLVED
  Resolution||FIXED

 --- Comment #28 from Evan Huus eapa...@gmail.com 2012-10-08 08:26:16
 PDT ---
 The last little bits of this have finally been properly fixed in rev
 45389. New
 bugs with that code are new bugs, as this one is getting rather unwieldy :)


Now when compiling with gcc-4.3.2 on my old Debian Lenny, I get:
make[3]: Entering directory `/home/pascal/soft/wireshark/trunk/epan'
/bin/sh ../libtool --tag=CC   --mode=compile gcc -DHAVE_CONFIG_H -I. -I..
-I./.. -I./../tools/lemon -I./wslua   -DINET6 -DG_DISABLE_DEPRECATED
-DG_DISABLE_SINGLE_INCLUDES -DGTK_DISABLE_DEPRECATED
-DGTK_DISABLE_SINGLE_INCLUDES  -D_FORTIFY_SOURCE=2 -I/usr/local/include -I
/home/pascal/soft/include
'-DPLUGIN_DIR=/usr/local/lib/wireshark/plugins/1.9.0' -Werror
-DPYTHONDIR= -g -O2 -Wall -W -Wextra -Wdeclaration-after-statement
-Wendif-labels -Wpointer-arith -Wno-pointer-sign -Warray-bounds
-Wcast-align -Wformat-security -Wold-style-definition -D_REENTRANT
-I/usr/include/gtk-2.0 -I/usr/lib/gtk-2.0/include -I/usr/include/atk-1.0
-I/usr/include/cairo -I/usr/include/pango-1.0 -I/usr/include/glib-2.0
-I/usr/lib/glib-2.0/include -I/usr/include/freetype2
-I/usr/include/directfb -I/usr/include/libpng12 -I/usr/include/pixman-1
-MT libwireshark_la-emem.lo -MD -MP -MF .deps/libwireshark_la-emem.Tpo -c
-o libwireshark_la-emem.lo `test -f 'emem.c' || echo './'`emem.c
 gcc -DHAVE_CONFIG_H -I. -I.. -I./.. -I./../tools/lemon -I./wslua -DINET6
-DG_DISABLE_DEPRECATED -DG_DISABLE_SINGLE_INCLUDES -DGTK_DISABLE_DEPRECATED
-DGTK_DISABLE_SINGLE_INCLUDES -D_FORTIFY_SOURCE=2 -I/usr/local/include -I
/home/pascal/soft/include
-DPLUGIN_DIR=\/usr/local/lib/wireshark/plugins/1.9.0\ -Werror
-DPYTHONDIR= -g -O2 -Wall -W -Wextra -Wdeclaration-after-statement
-Wendif-labels -Wpointer-arith -Wno-pointer-sign -Warray-bounds
-Wcast-align -Wformat-security -Wold-style-definition -D_REENTRANT
-I/usr/include/gtk-2.0 -I/usr/lib/gtk-2.0/include -I/usr/include/atk-1.0
-I/usr/include/cairo -I/usr/include/pango-1.0 -I/usr/include/glib-2.0
-I/usr/lib/glib-2.0/include -I/usr/include/freetype2
-I/usr/include/directfb -I/usr/include/libpng12 -I/usr/include/pixman-1 -MT
libwireshark_la-emem.lo -MD -MP -MF .deps/libwireshark_la-emem.Tpo -c
emem.c  -fPIC -DPIC -o .libs/libwireshark_la-emem.o
emem.c:153: error: redefinition of typedef ‘emem_header_t’
ftypes/../emem.h:37: error: previous declaration of ‘emem_header_t’ was here
make[3]: *** [libwireshark_la-emem.lo] Error 1
make[3]: Leaving directory `/home/pascal/soft/wireshark/trunk/epan'
make[2]: *** [all-recursive] Error 1
make[2]: Leaving directory `/home/pascal/soft/wireshark/trunk/epan'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/home/pascal/soft/wireshark/trunk'
make: *** [all] Error 2

I do not have the time to look at it right now, so if you have some spare
time feel free :)

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

Re: [Wireshark-dev] r45266: proto_tree_add_uint_format_value(..., value, ..., value + 1)

[Pascal Quantin]

Le 11/10/2012 05:10, mman...@netscape.net a écrit :
 Pascal,
  
 Did you settle on the value, value+1?  I think I have the exact same
 problem in bug 7728
 (https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=7768)
Hi,

right now I'm displaying the value like what we would do with a
value_string array: computed value and raw value in parenthesis. It is
the best trade-off I could think to so far:
oct = tvb_get_guint8(tvb, curr_offset)  0x0f;
proto_tree_add_uint_format_value(tf_tree,
hf_gsm_a_sm_tft_pkt_flt_id, tvb, curr_offset, 1, oct, %d (%d), oct+1,
oct);
Any other idea is welcome.

Regards,
Pascal.

 -Original Message-
 From: Pascal Quantin pascal.quan...@gmail.com
 To: Developer support list for Wireshark wireshark-dev@wireshark.org
 Sent: Wed, Oct 3, 2012 8:18 am
 Subject: Re: [Wireshark-dev] r45266:
 proto_tree_add_uint_format_value(..., value, ..., value + 1)

 Hi,

 2012/10/3 Jakub Zawadzki darkjames...@darkjames.pl
 mailto:darkjames...@darkjames.pl

 Hi Pascal,

 On Wed, Oct 03, 2012 at 10:36:47AM +0200, Pascal Quantin wrote:
  2012/10/3 Jakub Zawadzki darkjames...@darkjames.pl
 mailto:darkjames...@darkjames.pl
 
   Hi,
  
   part of r45266 (or 6427287[1]):
  
   #v+
   -  proto_tree_add_item(tf_tree, hf_gsm_a_sm_tft_pkt_flt_id, tvb,
   curr_offset, 1, ENC_BIG_ENDIAN);
   +  oct = tvb_get_guint8(tvb, curr_offset)  0x0f;
   +  proto_tree_add_uint_format_value(tf_tree,
 hf_gsm_a_sm_tft_pkt_flt_id,
   tvb, curr_offset, 1, oct, %d, oct+1);
   #v-
  
   Now user type display filter: 'gsm_a.gm.sm.tft.pkt_flt_id == 4',
   later he checks the value in tree and there is 5.
  
   I'm not sure if it's odd only for me (have not read 3GPP
 27.007) or if it
   could confuse all the users,
   also familiar with this specification.
  
   [1]
  
 
 http://code.wireshark.org/git/?p=wireshark;a=commitdiff;h=64272873f088a62b8db71e23e0e38c5c8d80194d
  
 
  a packet filter identifier goes from 1 to 16 but is encoded on 4
 bits, thus
  my modification.

  But I understand the confusion it can create when applying
  a filter. I could add the raw value in parenthesis (as we do for
 value
  string arrays) to make things a bit clearer.
  What do you think? Any other suggestion?

 Still I don't understand why you decided to have different values
 for tree and filter.
 Why not:
   proto_tree_add_uint(tf_tree, hf_gsm_a_sm_tft_pkt_flt_id, tvb,
 curr_offset, 1, oct + 1); ?


 That's what I did first but in that case the bit string displayed
 before the filter name does not correspond to the real bit string of
 the message in the hex pane:
  0010 = Packet filter identifier: 2
 while the byte in the hex pane ix 0x31.
 I found it even more confusing.

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

Re: [Wireshark-dev] r45266: proto_tree_add_uint_format_value(..., value, ..., value + 1)

[Pascal Quantin]

2012/10/11 Mike Morrin morrinm...@gmail.com

 On 11/10/2012 06:26, Pascal Quantin wrote:

 Le 11/10/2012 05:10, mman...@netscape.net a écrit :

 Pascal,
 Did you settle on the value, value+1?  I think I have the exact same
 problem in bug 7728
 (https://bugs.wireshark.org/**bugzilla/show_bug.cgi?id=7768https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=7768
 )

 Hi,

 right now I'm displaying the value like what we would do with a
 value_string array: computed value and raw value in parenthesis. It is
 the best trade-off I could think to so far:
  oct = tvb_get_guint8(tvb, curr_offset)  0x0f;
  proto_tree_add_uint_format_**value(tf_tree,
 hf_gsm_a_sm_tft_pkt_flt_id, tvb, curr_offset, 1, oct, %d (%d), oct+1,
 oct);
 Any other idea is welcome.

  Why not use an hf with BASE_CUSTOM and write a custom display function
 to format the string?


Hi Mike,

you are right I could have used it. Given the low complexity of my display
and the fact that it is called twice in the code, I'm not sure it is worth
it though. But I should think more often to the existence of BASE_CUSTOM.

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

Re: [Wireshark-dev] WLAN decryption using a hex PSK key

[Pascal Quantin]

Le 20/10/2012 17:33, Sho Amano a écrit :
 Okey, I figured out that following quick hack works for me. Now I can see
 the decrypted TCP packets.
 (build running on Ubuntu 12.04 amd64)

 $ svn diff
 Index: epan/dissectors/packet-ieee80211.c
 ===
 --- epan/dissectors/packet-ieee80211.c(revision 45658)
 +++ epan/dissectors/packet-ieee80211.c(working copy)
 @@ -17369,7 +17369,7 @@
  keys-Keys[keys-nKeys] = key;
  keys-nKeys++;
}
 -  else if(dk-type == AIRPDCAP_KEY_TYPE_WPA_PMK)
 +  else if(dk-type == AIRPDCAP_KEY_TYPE_WPA_PSK)
{
  key.KeyType = AIRPDCAP_KEY_TYPE_WPA_PMK;
  

 Thanks.

Hi Sho,

thanks for the report and patch. I committed a slightly different
version in r45696 and scheduled it for backport in 1.8.4.

Regards,
Pascal.

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

Re: [Wireshark-dev] WLAN decryption using a hex PSK key

[Pascal Quantin]

2012/10/22 Sho Amano samano@gmail.com

 Hi Pascal,

 2012/10/22 Pascal Quantin pascal.quan...@gmail.com

 Le 20/10/2012 17:33, Sho Amano a écrit :
  Okey, I figured out that following quick hack works for me. Now I can
 see
  the decrypted TCP packets.
  (build running on Ubuntu 12.04 amd64)
 
  $ svn diff
  Index: epan/dissectors/packet-ieee80211.c
  ===
  --- epan/dissectors/packet-ieee80211.c(revision 45658)
  +++ epan/dissectors/packet-ieee80211.c(working copy)
  @@ -17369,7 +17369,7 @@
   keys-Keys[keys-nKeys] = key;
   keys-nKeys++;
 }
  -  else if(dk-type == AIRPDCAP_KEY_TYPE_WPA_PMK)
  +  else if(dk-type == AIRPDCAP_KEY_TYPE_WPA_PSK)
 {
   key.KeyType = AIRPDCAP_KEY_TYPE_WPA_PMK;
 
 
  Thanks.

 Hi Sho,

 thanks for the report and patch. I committed a slightly different
 version in r45696 and scheduled it for backport in 1.8.4.


 Thanks, I tried r45696 on Ubuntu 12.04 (amd64) and it worked well.
 But I have some questions.

 packet-ieee80211.c, line 17374:
   Since we convert PSK (64-byte ASCII) into PMK (32-byte binary) on line
 17377,
   what's the point of setting key.KeyType = AIRPDCAP_KEY_TYPE_WPA_PSK ?

 packet-ieee80211.c, line 17380:
   Using debugger, I verified that bytes-len is 32. So it is always
 smaller than
   AIRPDCAP_WPA_PSK_LEN, which is 64.

 packet-ieee80211.c, line 17381:
   Since we are using the converted PMK, maybe we should copy it into
 key.KeyData.Wpa.Pmk?
   (I know that is actually the same place :-)


Hi Sho,

I did mainly the change because using the PMK union / structure member for
a PSK key configured in UAT was hurting my eyes and looked like a bug.
From a quick glance it looks like the handling of PSK / PMK seems a bit
messy (PMK defines / union are almost not used, and mixed with PMK ones). I
will let someone more aware of those subtle differences do a follow-up
cleanup if needed.

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

[Wireshark-dev] wmem allocator and GLIB version

[Pascal Quantin]

Hi all,

wmem_glib_free_all() makes use of g_slist_free_full that was introduced in
GLIB 2.28 while our minimum requirement is GLIB 2.14.0. Could we manually
free list elements containing dynamically-allocated memory and call
g_slist_free() instead to keep compatibility with older GLIB versions?

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

Re: [Wireshark-dev] RFD: The Future of Memory Management in Wireshark

[Pascal Quantin]

Le 25/10/2012 22:10, Evan Huus a écrit :
 On Thu, Oct 25, 2012 at 4:00 PM, Jeff Morriss jeff.morriss...@gmail.com 
 wrote:
 Evan Huus wrote:
 On Thu, Oct 25, 2012 at 2:05 PM, Jeff Morriss jeff.morriss...@gmail.com
 wrote:
 Evan Huus wrote:
 The usage might look something like this:

 wmem_allocator_t *ep_scope = wmem_create_glib_allocator();
 doWork(ep_scope);
 wmem_destroy_glib_allocator(ep_scope);

 and then in doWork, instead of ep_alloc(numBytes) you would call
 wmem_alloc(ep_scope, numBytes).

 Hopefully stupid question (without having had time to look at the code):
 does that mean passing ep_scope all the way down to the dissectors and
 where
 they do their allocations?

 Unfortunately, yes. You'd have an se_scope as well (and potentially
 others) so they'd probably be wrapped up in a single `scopes` object,
 but it does mean one more parameter to pass around.

 I hope not; it's been a pain just to get pinfo
 all the way down into some of the routines (for expert infos).

 I know, but I don't know that there's a nice way around it.

 On that thought: since the amount of packet-related data keeps
 growing, might it be worth the effort to wrap all the current
 parameters (tvbuff, pinfo, tree, etc.) into a single 'dissect-me'
 struct to pass around? I know it's not really good style in a lot of
 ways, but it would make it a lot easier to expose new things to
 dissectors and automatically have them available in all of the
 internal functions.

 Oof.  Well, that's one advantage of the current system (that keeps the
 allocators in emem.c and has lots of little wrapper functions).

 For pinfo I had also contemplated a function to retrieve the current pinfo,
 with the thought that this function would have to get smarter if/when
 multiple threads are supported.

 A dissect-me blob honestly doesn't sound too bad at the moment though...
 Quite a number of dissector functions have a _lot_ of arguments (usually
 including tvb, tree, and, if we're lucky ;-), pinfo).
 General thoughts from the list on whether or not this would be a good idea?

+1 for me.

Regards,
Pascal.

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

Re: [Wireshark-dev] Build Wireshark

[Pascal Quantin]

2012/12/3 cheer_zeng cheer_z...@163.com

 **
 Hello
 My system is 64-bit win7 ,and I follow the wireshark develop guide
 ---Win32 :Step-by-step (
 http://www.wireshark.org/docs/wsdg_html_chunked/ChSetupWin32.html) to set
 up the environment .But I fail at the 2.2.10 Build Wireshark ,after i call 
 *nmake -f Makefile.nmake all* ,comes the error message :

 ***link -nologo -debug -incremental:no -opt:ref
 -def:win32/zlib.def -dll -i
 mplib:zdll.lib  -out:zlib1.dll -base:0x5A4C adler32.obj compress.obj
 crc32.o
 bj deflate.obj gzclose.obj gzlib.obj gzread.obj  gzwrite.obj infback.obj
 inflate
 .obj inftrees.obj trees.obj uncompr.obj zutil.obj inffas32.obj
 match686.obj zlib
 1.res
 inffas32.obj : fatal error LNK1112: module machine type 'X86' conflicts
 with tar
 get machine type 'x64'
 NMAKE : fatal error U1077: 'c:\Program Files (x86)\Microsoft Visual
 Studio 10.0
 \VC\Bin\amd64\link.EXE' : return code '0x458'
 Stop.
 NMAKE : fatal error U1077: 'c:\Program Files (x86)\Microsoft Visual
 Studio 10.0
 \VC\Bin\amd64\nmake.exe' : return code '0x2'
 Stop.*
 **
 I use setenv /Release /x64 /win7 in the windows SDK 7.1 Command Prompt
 to set environment variables for Visual C++ 2010 Express Edition,as i
 don;t have vcvars64.bat  in the amd64 directory descript in vcvarsall.dll

 Then what should i do to correct the error?


 as i am not new to this,so hope you all can help me.
 Thank you !!


Hi,

if you want to build a 64 bits Wirehshark, you must also change
WIRESHARK_TARGET_PLATFORM from win32 to win64 (either by setting an
environment variable or by editing config.nmake file).
Then you must do nmake -f Makefile.nmake setup once to download the win64
packages (you probably downloaded the 32 bits packages).

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

Re: [Wireshark-dev] Wireshark-dev Digest, Vol 79, Issue 6

[Pascal Quantin]

2012/12/4 Anders Broman anders.bro...@ericsson.com

 **
  Hi,
 The correct fix is to change the script make-usb.py in the tools dir to
 escape non ASCII chars
 similarly to make-sminmpec.pl
 sub escape_non_ascii {
 my $val = unpack 'C', $_[0];
 return sprintf '\0%.3o',$val;
 }
 and rebuild the file, then submitt a patch with the changes.

 Hi,

with the following patch:
Index: tools/make-usb.py
===
--- tools/make-usb.py(revision 46346)
+++ tools/make-usb.py(working copy)
@@ -36,11 +36,11 @@

 if mode == MODE_VENDOR_PRODUCT:
 if re.match(^[0-9a-f]{4}, line):
-vendors += { 0x%s, \%s\ },\n%(line[:4], re.sub(\,
\\\, re.sub(\?+, ?, line[4:].strip().replace(\\, 
+vendors += { 0x%s, \%s\ },\n%(line[:4], re.sub(\,
\\\, re.sub(\?+, ?, repr(line[4:].strip()).strip(').replace(\\,

 last_vendor = line[:4]
 elif re.match(^\t[0-9a-f]{4}, line):
 line = line.strip()
-products += { 0x%s%s, \%s\ },\n%(last_vendor,
line[:4], re.sub(\, \\\, re.sub(\?+, ?,
line[4:].strip().replace(\\, 
+products += { 0x%s%s, \%s\ },\n%(last_vendor,
line[:4], re.sub(\, \\\, re.sub(\?+, ?,
repr(line[4:].strip()).strip(').replace(\\, 


 vendors += { 0, NULL }\n};

SideWinder® Freestyle Pro is now displayed as SideWinder\\xc2\\xae
Freestyle Pro. I guess this is the kind of escaping you were thinking to
Anders, right?

Note that I'm a newbie in Python so there might be a smarter way to do it.
If nobody propose something else, I will push it as is and let the Python
experts do a follow up if needed.

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

Re: [Wireshark-dev] Wireshark-dev Digest, Vol 79, Issue 6

[Pascal Quantin]

2012/12/5 Anders Broman anders.bro...@ericsson.com

 **

 SideWinder® Freestyle Pro is now displayed as SideWinder\\xc2\\xae
 Freestyle Pro. I guess this is the kind of escaping you were thinking
 to Anders, right?
  Yes something along those lines.


Done in r46398.

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