Re: [Wireshark-dev] Building on Windows with CMake: Status and help needed
On 5 October 2013 12:03, Joerg Mayer jma...@loplof.de wrote: Hello, I've made some progress and am now able to almost build a first 32 bit executable with VSEE2010. The executable (capinfos) using nmake as build tool. The cmake stage (for nmake) is working as much as is needed, i.e. no GUI package detection right now. Compilation is working, but linking fails: capinfos.c.obj : error LNK2001: unresolved external symbol __imp__optind capinfos.c.obj : error LNK2019: unresolved external symbol __imp__getopt referenced in function _main I've spent some hours digging into it but everything I've tried has failed. Other open issues: - The same warning over and over again: cl : Command line warning D9025 : overriding '/MD' with '/MDd' - Problems with the WS_DLL_PUBLIC mechanism, one out of many examples: C:\wireshark\trunk\epan\plugins.c(31) : warning C4273: 'wslua_plugin_list' : inconsistent dll linkage c:\wireshark\trunk\epan\plugins.h(65) : see previous definition of 'wslua_plugin_list' My next steps (not necessarily in that order): - Try to get the remaining executables as close to linking as possible. - GTK3 and GTK2 builds (gtk detection). - Is there a recipe for Qt5 builds on Windows (esecially the qt5 package)? - Go for 64 bit builds. If someone feels motivated to help with any of the problems or unfinished tasks above or anything else: Go ahead - I don't want a monoploly on this ;-) Coordination via the list or IRC(freenode) #wireshark? Full logs of a build of svn revision 52377 cmake -G NMake Makefiles ..\..\trunk cmake --build . -- VERBOSE=1 can be found here: http://www.loplof.de/kram/cmake.log http://www.loplof.de/kram/build.log Hi Joerg, I was also working on this yesterday, but I was using CMake to build a Visual Studio solution (VS2010 Pro). I was trying to get randpkt to build and at least one issue you mention (import of getopt) is where I had issues. The issues I ran into were: * Needed to add a definition for MSC_VER_REQUIRED to CMakeList.txt. I cheated and just hacked in a fixed one for my version (MSC_VER_REQUIRED=1600). * randpkt, and a lot of other things depend on wsutil. CMake doesn't seem to add a dependency on wsutil though. * wsutil on windows also requires 5 files to be added to WSUTIL_PLATFORM_FILES: inet_aton.c, inet_ntop.c, inet_pton.c, strptime.c, wsgetopt.c * wsutil requires at least ws2_32.lib to link I still can't produce a dll yet as the link fails looking for strncasecmp required by strptime_internal. This has me stumped. I checked what the normal nmake produced dll imports (using dumpbin /imports libwsutil.dll) and that function isn't listed. I think it's something to do with all the macro wizardy in strptime.c For what it's worth I think the link libs we supply are mostly far beyond what is needed, for this dll produced by the normal nmake build the dependences are (using dumpbin /dependents): Dump of file ..\..\trunk\wireshark-gtk2\libwsutil.dll File Type: DLL Image has the following dependencies: KERNEL32.dll WS2_32.dll ADVAPI32.dll SHELL32.dll libglib-2.0-0.dll libgmodule-2.0-0.dll libgcrypt-11.dll MSVCR100.dll Summary 1000 .data C000 .rdata 1000 .reloc 1000 .rsrc 11000 .text I've also attached the build output for the dll from the normal nmake build and the CMake generated VS2010 build for comparison as there must be a vital difference somewhere. cl -WX /DPCAP_VERSION=4_1_3 /Zi /W3 /MD /DWIN32_LEAN_AND_MEAN /DMSC_VER_REQUIRED=1600 /D_CRT_SECURE_NO_DEPRECATE /D_CRT_NONSTDC_NO_DEPRECATE -DPSAPI_VERSION=1 /D_BIND_TO_CURRENT_CRT_VERSION=1 /MP /GS /w34295 /I. /I.. /IE:\Wireshark\wireshark-win32-libs\gtk3\include\glib-2.0 /IE:\Wireshark\wireshark-win32-libs\gtk3\lib\glib-2.0\include -DG_DISABLE_DEPRECATED -DG_DISABLE_SINGLE_INCLUDES /IE:\Wireshark\wireshark-win32-libs\gnutls-2.12.18-1.2-win32ws\include /DNOCRYPT /DIMPORT_LIGNUTLSDLL /IE:\Wireshark\wireshark-win32-libs\WPdpack\include -DWS_BUILD_DLL -Fd.\ -c file_util.c inet_aton.c inet_ntop.c inet_pton.c aes.c airpdcap_wep.c crash_info.c crc6.c crc7.c crc8.c crc10.c crc11.c crc16.c crc16-plain.c crc32.c crcdrm.c des.c eax.c g711.c md4.c md5.c mpeg-audio.c nstime.c privileges.c sha1.c strnatcmp.c str_util.c swar.c rc4.c report_err.c tempfile.c type_util.c u3.c strptime.c unicode-utils.c wsgetopt.c Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 16.00.40219.01 for 80x86 Copyright (C) Microsoft Corporation. All rights reserved. file_util.c inet_aton.c inet_ntop.c inet_pton.c aes.c airpdcap_wep.c crash_info.c crc6.c crc7.c crc8.c crc10.c crc11.c crc16.c crc16-plain.c crc32.c crcdrm.c des.c eax.c g711.c md4.c md5.c mpeg-audio.c nstime.c privileges.c sha1.c strnatcmp.c str_util.c swar.c rc4.c report_err.c tempfile.c type_util.c u3.c strptime.c unicode-utils.c wsgetopt.c link /INCREMENTAL:NO /NOLOGO
Re: [Wireshark-dev] Wireshark PIDL generated dissectors
On 10/03/2013 08:04 PM, ronnie sahlberg wrote: What do you propose? There is very little overlap between samba needs and wireshark needs for PIDL. It is probably better to continue running two separate forks of PIDL, one for samba and one for wireshark. Switching to samba PIDL seems to be a lot of work for miniscule gain. And who will do the work? I don't know what is the samba PIDL and the wireshark PIDL. For me there is only one pidl and it's in the samba repository. Then we have a 2 big use case: * Samba * Wireshark No later than 3 days ago I did huge changes to the code for the Wireshark dissector so that it starts to be able to parse byte-pipe dce-rpc and also parse inline arrays so yes the development on pidl to generate more dissectors continue. By the way I take the chance of this thread to underline that it's very hard to get the attention of the wireshark developpers to actually push patches (much harder than the Samba actually ...). I'm not sure that your patch will apply cleanly on the current version on the NDR.pm for wireshark, I'll port it if needed in the Samba tree. By the way it would be nice if other dev in wireshark understand the term autogenerated because I spotted on the packet-dcerpc-frsrpc.c not less than 5 manual changes since the last time ronnie pushed the last version of the regenerated file: commit c58d4ce28e00994ee54418c00ffddc3d1d701b21 Author: pascal pascal@f5534014-38df-0310-8fa8-9805f1628bb7 Date: Sat Mar 2 22:54:39 2013 + From Ed Beroset via https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=8416 : Remove C++ incompatibilities from most of the dcerpc code git-svn-id: http://anonsvn.wireshark.org/wireshark/trunk@48023 f5534014-38df-0310-8fa8-9805f1628bb7 commit 1e7435e4be8b92828974ff779dfff1bace76db2e Author: morriss morriss@f5534014-38df-0310-8fa8-9805f1628bb7 Date: Thu Sep 20 02:03:38 2012 + We always HAVE_CONFIG_H so don't bother checking whether we have it or not. git-svn-id: http://anonsvn.wireshark.org/wireshark/trunk@45017 f5534014-38df-0310-8fa8-9805f1628bb7 commit 85cfa7da0e396f6322b7ca5835354744d1f002be Author: morriss morriss@f5534014-38df-0310-8fa8-9805f1628bb7 Date: Wed Aug 8 03:28:02 2012 + Add SVN Id. git-svn-id: http://anonsvn.wireshark.org/wireshark/trunk@44323 f5534014-38df-0310-8fa8-9805f1628bb7 commit dc45bf2a9b3a9c8cfcd55ba3c639ea8a1d4c698f Author: cmaynard cmaynard@f5534014-38df-0310-8fa8-9805f1628bb7 Date: Sun Apr 29 23:39:55 2012 + Fix a clang warning due to 'type' not being initialized. git-svn-id: http://anonsvn.wireshark.org/wireshark/trunk@42341 f5534014-38df-0310-8fa8-9805f1628bb7 commit 15681f4c667c0778ff50eedb2eda9f97e5cbf270 Author: etxrab etxrab@f5534014-38df-0310-8fa8-9805f1628bb7 Date: Mon Sep 12 14:30:41 2011 + Leading white space in the field descriptive name is not allowed. git-svn-id: http://anonsvn.wireshark.org/wireshark/trunk@38976 f5534014-38df-0310-8fa8-9805f1628bb7 At this stupid game, manual changes are pretty sure to lose, and if someone is not paying attention next regeneration will override the manual changes. For thoses I already took care of them here: http://comments.gmane.org/gmane.network.samba.cvs/78414 (changeset 167e2f2b5543008e02613dcd56e36f7326912cdb) Last but not least I will grab the opportunity of having some wireshark devs listening to complain about the lack of feedback when publishing patches in wireshark's bugzilla. I tried several time in the past to get my patches for dce-rpc dissectors pushed and got no response my only way to get my patches was to get ronnie pushing them. It would be nice if it wouldn't have to be that way because : 1) sometime ronnie also ignore my requests (I sent update last week but no feedback) 2) It's quite annoying to have fixes that we know are good and will result in a much better dissection but nobody can take advantage of them because they are not integrated in wireshark's source tree. Matthieu. On Thu, Oct 3, 2013 at 7:58 PM, Andrew Bartlett abart...@samba.org wrote: On Thu, 2013-10-03 at 19:44 -0700, ronnie sahlberg wrote: Cool. And we contact you when samba-PIDL no longer can generate compileable wireshark dissectors? Contacting the Samba Team would seem to be the correct approach. Given Matthieu was working on generated dissectors only last week, it does not seem totally unreasonable. What do you propose? Andrew Bartlett -- Andrew Bartlett http://samba.org/~abartlet/ Authentication Developer, Samba Team http://samba.org Samba Developer, Catalyst IT http://catalyst.net.nz -- Matthieu Patou Samba Team http://samba.org ___ 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] Wireshark PIDL generated dissectors
On Sun, Oct 6, 2013 at 4:29 AM, Matthieu Patou m...@samba.org wrote: Last but not least I will grab the opportunity of having some wireshark devs listening to complain about the lack of feedback when publishing patches in wireshark's bugzilla. I tried several time in the past to get my patches for dce-rpc dissectors pushed and got no response my only way to get my patches was to get ronnie pushing them. This is mostly a shortage of developers - we tend to get more patch submissions and bug reports than we have time to deal with, so some of them slip through the cracks. If it's still open in Bugzilla, somebody will get around to it eventually, in theory. Evan ___ 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 PIDL generated dissectors
On Sun, Oct 06, 2013 at 01:29:50AM -0700, Matthieu Patou wrote: For me there is only one pidl and it's in the samba repository. Then we have a 2 big use case: * Samba * Wireshark By the way I take the chance of this thread to underline that it's very hard to get the attention of the wireshark developpers to actually push patches (much harder than the Samba actually ...). Which bugnumber(s) are still open? By the way it would be nice if other dev in wireshark understand the term autogenerated because I spotted on the packet-dcerpc-frsrpc.c not less than 5 manual changes since the last time ronnie pushed the last version of the regenerated file: It works quite fine with asn2wrs generated, because that generator is in a maintained state, while it's hard to maintain the pidl dissector in Wireshark: While samba was still maintained via svn, I used to (every few weeks or months) sync the samba changes into Wireshark, including the commit history. As I didn't have the disk space at that time to keep a copy of the samba repo, I stopped doing that. I'd like to have a current and working pidl generator in the Wireshark sources again. Ciao Jörg PS: One thing I'd like to have is to have a comment with the command line used to generate the dissector like we do with asn2wrs. -- Joerg Mayer jma...@loplof.de We are stuck with technology when what we really want is just stuff that works. Some say that should read Microsoft instead of technology. ___ Sent via:Wireshark-dev mailing list 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] Handling of generated dissectors
Hello, Matthieu raised an issue that I've seen with asn2wrs generated dissectors too, just not to the extent of the pidl dissectors. To make it much harder to miss that the changes we are doing are to generated dissectors I see two approaches: - Name the files differently, e.g. prefix with gpacket- instead of packet-, so we know when we check that file in that there should be an accompanying basefile or generator patch. - Have a checkin script check for the term generated in the first few lines and annotate the commit message that a generated file was changed. Thoughts? Jörg -- Joerg Mayer jma...@loplof.de We are stuck with technology when what we really want is just stuff that works. Some say that should read Microsoft instead of technology. ___ Sent via:Wireshark-dev mailing list 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] tshark: Read filter -R and IPv6 checksum vaildation fails on mips64
Hello all, I have been facing two issues with tshark on mips64 1. Read filter fails ( i debugged it to some extent and found the argument values passed to apply_test were wrong. I'm not an expert of yacc so could not able to debug it). 2. IPv6 ICMP checksum always throws as incorrect. on X86 the same packet shows as vaild checksum Linux: 2.6.34 mips64 Wireshark: 1.6.10, 1.6.16 and 1.8.10 ( tried three versions including latest) configure options = ./configure --host=mips64-target-linux-gnu --build=x86_64-crosscompile- linux-gnu --disable-wireshark --with-lua=no --with-pcre=no tshark reports IPv6 checksum as invaild == Internet Control Message Protocol v6 Type: Router Solicitation (133) Code: 0 Checksum: 0x5238 [incorrect, should be 0x9bee] [Expert Info (Warn/Checksum): ICMPv6 Checksum Incorrect, should be 0x9bee] [Message: ICMPv6 Checksum Incorrect, should be 0x9bee] [Severity level: Warn] [Group: Checksum] Read filter fails === root@shash:/root/ tshark -r testRadAcct12_vmac.0004_1.enc -R radius.Acct_Status_Type==1 Running as user root and group root. This could be dangerous. But grep works fine root@shash:/root/ tshark -r testRadAcct12_vmac.0004_1.enc -T fields -eradius.Acct_Status_Type Running as user root and group root. This could be dangerous. 1 Thanks Sasi ___ 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 52413: /trunk/epan/ /trunk/epan/dissectors/: Makefile.common packet-vj.c /trunk/epan/: CMakeLists.txt
On Sun, Oct 6, 2013 at 4:38 PM, Joerg Mayer jma...@loplof.de wrote: Can we please discuss the removal of files before doing so? I did [1], it just took me a few weeks to get around to removing it since nobody objected at the time. [1] https://www.wireshark.org/lists/wireshark-dev/201309/msg00182.html IIRC, while the 4 clause BSD license is incompatible with the GPL, the regents granted a general amnesty so code copyrighted by them gets treated like a 3 clause BSD license. There's also the issue of the Qualcomm claim (which is rather ambiguous). If this is true however, 4-clause BSD should be added to our acceptable licenses list. I currently just lack the nerve/time to look this up and by the time I have the cmake stuff sort of going for Windows I will probably have forgotten about this :-( Ciao Jörg On Sun, Oct 06, 2013 at 07:04:11PM +, eapa...@wireshark.org wrote: http://anonsvn.wireshark.org/viewvc/viewvc.cgi?view=revrevision=52413 User: eapache Date: 2013/10/06 07:04 PM Log: Remove packet-vj.c as it does not appear to be under a license we can use. Directory: /trunk/epan/dissectors/ ChangesPath Action +0 -1 Makefile.commonModified +0 -879packet-vj.cRemoved Directory: /trunk/epan/ ChangesPath Action +0 -1 CMakeLists.txtModified ___ Sent via:Wireshark-commits mailing list wireshark-comm...@wireshark.org Archives:http://www.wireshark.org/lists/wireshark-commits Unsubscribe: https://wireshark.org/mailman/options/wireshark-commits mailto:wireshark-commits-requ...@wireshark.org?subject=unsubscribe -- Joerg Mayer jma...@loplof.de We are stuck with technology when what we really want is just stuff that works. Some say that should read Microsoft instead of technology. ___ Sent via:Wireshark-dev mailing list 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] Handling of generated dissectors
On Sun, Oct 06, 2013 at 04:27:50PM -0400, Evan Huus wrote: On Sun, Oct 6, 2013 at 4:25 PM, Joerg Mayer jma...@loplof.de wrote: Hello, Matthieu raised an issue that I've seen with asn2wrs generated dissectors too, just not to the extent of the pidl dissectors. To make it much harder to miss that the changes we are doing are to generated dissectors I see two approaches: - Name the files differently, e.g. prefix with gpacket- instead of packet-, so we know when we check that file in that there should be an accompanying basefile or generator patch. - Have a checkin script check for the term generated in the first few lines and annotate the commit message that a generated file was changed. Thoughts? Ideally we wouldn't keep generated files in svn/git at all. We would keep the sources and (if necessary) the generating tool, and we would make generating them part of the build process. This slows down the initial build somewhat, but it makes it absolutely impossible for them to get out of sync. True. OK, looks like another solution which looks more convincing than the ones I proposed. Ciao Jörg -- Joerg Mayer jma...@loplof.de We are stuck with technology when what we really want is just stuff that works. Some say that should read Microsoft instead of technology. ___ Sent via:Wireshark-dev mailing list 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 52413: /trunk/epan/ /trunk/epan/dissectors/: Makefile.common packet-vj.c /trunk/epan/: CMakeLists.txt
On Sun, Oct 06, 2013 at 04:45:06PM -0400, Evan Huus wrote: On Sun, Oct 6, 2013 at 4:38 PM, Joerg Mayer jma...@loplof.de wrote: Can we please discuss the removal of files before doing so? I did [1], it just took me a few weeks to get around to removing it since nobody objected at the time. [1] https://www.wireshark.org/lists/wireshark-dev/201309/msg00182.html Oops, sorry. IIRC, while the 4 clause BSD license is incompatible with the GPL, the regents granted a general amnesty so code copyrighted by them gets treated like a 3 clause BSD license. There's also the issue of the Qualcomm claim (which is rather ambiguous). If this is true however, 4-clause BSD should be added to our acceptable licenses list. No, unfortunately it can't be added: It can only be added if the only copyright for the file is Copyright (c) 1989 Regents of the University of California. As you mentioned that is not the case here, we either need permission from * This file created by Irfan Khan ik...@qualcomm.com * Copyright (c) 2001 by QUALCOMM, Incorporated. or we can't distribute binaries using that file. What we can do though is provide the source file without compiling it in. So maybe put it into the wiki so the knowhow isn't lost in case someone wants to recreate it (or just use it for a locally built copy). Ciao Jörg -- Joerg Mayer jma...@loplof.de We are stuck with technology when what we really want is just stuff that works. Some say that should read Microsoft instead of technology. ___ Sent via:Wireshark-dev mailing list 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] Building on Windows with CMake: Status and help needed
The executables now compile and link except the gtk and qt guis. I have not yet been able to run the executables as running the binaries inside the build tree doesn't seem to work (unlike on linux). Ideas how to get this to work? Thanks Jörg -- Joerg Mayer jma...@loplof.de We are stuck with technology when what we really want is just stuff that works. Some say that should read Microsoft instead of technology. ___ Sent via:Wireshark-dev mailing list 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] Building on Windows with CMake: Status and help needed
On 10/6/2013 7:27 PM, Joerg Mayer wrote: The executables now compile and link except the gtk and qt guis. I have not yet been able to run the executables as running the binaries inside the build tree doesn't seem to work (unlike on linux). Ideas how to get this to work? Thanks Jörg This is undoubtedly about the fact that Makefile.nmake copies lots of DLLs and etc to a separate run directory. The exe's won't run from the build dir on Windows. See install_all: target in Makefile.nmake (top-level) ... # install-all will copy all files needed to run Wireshark/Tshark # to the INSTALL_DIR, so you can run/debug Wireshark/Tshark from there. install-all: install-generated-files ... Bill ___ 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
