Re: [Wireshark-dev] Npcap 0.01 call for test (2nd)
On 22 July 2015 at 17:25, Yang Luo hslu...@gmail.com wrote: SNIP - for those having User Account Control activated, you need to start Wireshark as administrator (even without restricting Npcap to admin during installation) to have the driver started. Unfortunate... If this is the loopback adapter that triggers the issue at startup, should its installation be optional? I don't know whether there are many people using Wireshark in a non-Admin privilege? If yes, then I think the lacking boot start support needs a solution. Making loopback code optional is kind of difficult, because its code is deep in the driver and has tight connection with other parts. Most, if not all, will be running Wireshark unelevated, as this is a basic tenet of Wireshark use. There are millions of lines of code in Wireshark dissectors and they really shouldn't be given admin privs. -- Graham Bloice ___ Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org Archives:https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] Npcap 0.01 call for test (2nd)
On 22 July 2015 at 18:37, Guy Harris g...@alum.mit.edu wrote: On Jul 22, 2015, at 9:37 AM, Graham Bloice graham.blo...@trihedral.com wrote: Most, if not all, will be running Wireshark unelevated, as this is a basic tenet of Wireshark use. There are millions of lines of code in Wireshark dissectors and they really shouldn't be given admin privs. Does anybody know whether there exists, in Windows: 1) an inter-process communications mechanism, either documented or reverse-engineered *and* likely to remain intact and usable from release to release and in future releases, over which a HANDLE can be passed; DuplicateHandle - https://msdn.microsoft.com/en-us/library/windows/desktop/ms724251(v=vs.85).aspx A HANDLE to what though, the handle types that can be duplicated with that call are limited? If it's a socket HANDLE, then WSADuplicateSocket ( https://msdn.microsoft.com/en-us/library/windows/desktop/ms741565(v=vs.85).aspx) is used. This creates a structure that can be handed off to the target process by some IPC mechanism. The IPC Mechanisms supported by Windows are listed here: https://msdn.microsoft.com/en-us/library/windows/desktop/aa365574(v=vs.85).aspx, pipes are commonly used. I don't think there are issues with pipes between a non-elevated process and an elevated one, but I haven't personally tried that. 2) a mechanism by which a non-privileged process can request that a subprocess be run with elevated privileges - presumably requiring either user consent or something else to indicate trust - with such an IPC channel established between the non-privileged process and the privileged process? A way to elevate a subprocess is via a call to ShellExecuteEx() setting the lpVerb in the passed in SHELLEXECUTEINFO structure to runas. See http://blogs.msdn.com/b/vistacompatteam/archive/2006/09/25/771232.aspx. This will invoke UAC if enabled (a it should be). UN*Xes that support libpcap generally have 1) in the form of UNIX-domain sockets (or, in newer versions of OS X, Mach messages, over which those newer versions of OS X support passing file descriptors), and probably have 2) in the form of, if nothing else, sudo or some GUI equivalent. The idea here is to have libpcap - and WinPcap, if the answers to those questions are both yes - invoke a *small* helper process to do what work needs elevated privileges to open capture devices, turn on monitor mode, change channels, etc., so that programs using those libraries do not *themselves* require elevated privileges. If the answer for the first question is no, then do we have some way to run dumpcap with elevated privileges and have a pipe between it and Wireshark/TShark? That's what currently happens on Windows using a named pipe, without the elevation though. -- Graham Bloice ___ Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org Archives:https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] Npcap 0.01 call for test (2nd)
On 22 July 2015 at 21:49, Graham Bloice graham.blo...@trihedral.com wrote: On 22 July 2015 at 18:37, Guy Harris g...@alum.mit.edu wrote: On Jul 22, 2015, at 9:37 AM, Graham Bloice graham.blo...@trihedral.com wrote: Most, if not all, will be running Wireshark unelevated, as this is a basic tenet of Wireshark use. There are millions of lines of code in Wireshark dissectors and they really shouldn't be given admin privs. Does anybody know whether there exists, in Windows: 1) an inter-process communications mechanism, either documented or reverse-engineered *and* likely to remain intact and usable from release to release and in future releases, over which a HANDLE can be passed; DuplicateHandle - https://msdn.microsoft.com/en-us/library/windows/desktop/ms724251(v=vs.85).aspx A HANDLE to what though, the handle types that can be duplicated with that call are limited? If it's a socket HANDLE, then WSADuplicateSocket ( https://msdn.microsoft.com/en-us/library/windows/desktop/ms741565(v=vs.85).aspx) is used. This creates a structure that can be handed off to the target process by some IPC mechanism. The IPC Mechanisms supported by Windows are listed here: https://msdn.microsoft.com/en-us/library/windows/desktop/aa365574(v=vs.85).aspx, pipes are commonly used. I don't think there are issues with pipes between a non-elevated process and an elevated one, but I haven't personally tried that. 2) a mechanism by which a non-privileged process can request that a subprocess be run with elevated privileges - presumably requiring either user consent or something else to indicate trust - with such an IPC channel established between the non-privileged process and the privileged process? A way to elevate a subprocess is via a call to ShellExecuteEx() setting the lpVerb in the passed in SHELLEXECUTEINFO structure to runas. See http://blogs.msdn.com/b/vistacompatteam/archive/2006/09/25/771232.aspx. This will invoke UAC if enabled (a it should be). UN*Xes that support libpcap generally have 1) in the form of UNIX-domain sockets (or, in newer versions of OS X, Mach messages, over which those newer versions of OS X support passing file descriptors), and probably have 2) in the form of, if nothing else, sudo or some GUI equivalent. The idea here is to have libpcap - and WinPcap, if the answers to those questions are both yes - invoke a *small* helper process to do what work needs elevated privileges to open capture devices, turn on monitor mode, change channels, etc., so that programs using those libraries do not *themselves* require elevated privileges. If the answer for the first question is no, then do we have some way to run dumpcap with elevated privileges and have a pipe between it and Wireshark/TShark? That's what currently happens on Windows using a named pipe, without the elevation though. An interesting article on process elevation and IPC using named pipes between process with different security levels: http://www.codeproject.com/Articles/19165/Vista-UAC-The-Definitive-Guide -- Graham Bloice ___ Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org Archives:https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] Windows driver signing certificate purchase decision for WinPcap and Npcap
On 21 July 2015 at 11:25, Pascal Quantin pascal.quan...@gmail.com wrote: Le 21 juil. 2015 11:38 AM, Graham Bloice graham.blo...@trihedral.com a écrit : On 21 July 2015 at 07:06, Pascal Quantin pascal.quan...@gmail.com wrote: Le 21 juil. 2015 4:15 AM, Yang Luo hslu...@gmail.com a écrit : Hi list, There's only 8 days left for Win10 RTM. It seems that both WinPcap and Npcap need to decide which kind of Windows driver signing certificate to buy. There are two kinds of certs: EV cert and non-EV cert. AFAIK, I think we don't need to buy an EV cert yet, as EV cert is complicated to use (has to use a hardware key) and much more expensive. You should have found out that current Npcap driver CAN be successfully installed into Windows 10 Insider Preview 10240 x64 ( which is a candidate for Win10 RTM) WITHOUT disabling Driver Signature Enforcement. The reason turns out to be: To ensure backwards compatibility, drivers which are properly signed by a valid cross-signing certificate that was issued before the release of Windows 10 will continue to pass signing checks on Windows 10. (see for details: http://blogs.msdn.com/b/windows_hardware_certification/archive/2015/04/01/driver-signing-changes-in-windows-10.aspx). My English is not that good, but I think this sentence means that if you buy a non-EV cert before Win10 release (AKA 2015/7/29), you can use the cert to sign a driver to any platform including Win10 until it expires. So you can just buy a 3-year long cert before 7/29 and use it to sign any drivers for these 3 years. 3 years later, we have no other choice but to buy an EV cert, but who knows whether Microsoft would change its driver signing policy again then? Am I understanding it right? Hi Yang, That's not my understanding. What matters here is the driver signing timestamp, and not the expiry date of your certificate. You have 3 cases: - a driver signed with a timestamp prior to the 29th of July will still load for backward compatibility (same rules as previous Windows versions) - for drivers with a signature timestamp from the 29th of July or later, you need to upload your signed driver on Microsoft portal to get a counter signature that will allow to install it on Windows 10 - 90 days after the 29th of July, the portal will not accept anymore drivers not signed with an EV certificate So as you see the grace period will be short and you cannot escape from the purchase of an EV certificate (unless you hurry up to Polish your driver before the deadline;)). Even the counter signature step seems a bit painful (I have not tried it myself yet). Pascal. I agree the intentions are not clear. The statement To ensure backwards compatibility, drivers which are properly signed by a valid cross-signing certificate that was issued before the release of Windows 10 will continue to pass signing checks on Windows 10. implies to me that it's the date of the cross-signing certificate that counts. IMHO if it was the driver signing date, then the sentence should have read ... drivers which are properly signed by a valid cross-signing certificate that were signed before ... Currently, when signing kernel-mode drivers you currently have to use the MS cross-signing appropriate to the issuer of your SPC. I checked the one we use in the day job, it was issued Feb 22 2011 and it's valid until Feb 22 2021. Of course MS may revoke that cert, but then existing signed drivers for Windows 10 will also fail. I'll try to get some clarity on this. If this is the case it would be very good news, but in that case I do not understand the 90 days deadline for the driver submission without EV signing on Microsoft portal. Anyway we will get the answer very soon :) Maybe they expect a big rush of driver signing requests with the release of Win 10, and know that the EV requirement will take time to get in place. -- Graham Bloice ___ Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org Archives:https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] Windows driver signing certificate purchase decision for WinPcap and Npcap
On 21 July 2015 at 07:06, Pascal Quantin pascal.quan...@gmail.com wrote: Le 21 juil. 2015 4:15 AM, Yang Luo hslu...@gmail.com a écrit : Hi list, There's only 8 days left for Win10 RTM. It seems that both WinPcap and Npcap need to decide which kind of Windows driver signing certificate to buy. There are two kinds of certs: EV cert and non-EV cert. AFAIK, I think we don't need to buy an EV cert yet, as EV cert is complicated to use (has to use a hardware key) and much more expensive. You should have found out that current Npcap driver CAN be successfully installed into Windows 10 Insider Preview 10240 x64 ( which is a candidate for Win10 RTM) WITHOUT disabling Driver Signature Enforcement. The reason turns out to be: To ensure backwards compatibility, drivers which are properly signed by a valid cross-signing certificate that was issued before the release of Windows 10 will continue to pass signing checks on Windows 10. (see for details: http://blogs.msdn.com/b/windows_hardware_certification/archive/2015/04/01/driver-signing-changes-in-windows-10.aspx). My English is not that good, but I think this sentence means that if you buy a non-EV cert before Win10 release (AKA 2015/7/29), you can use the cert to sign a driver to any platform including Win10 until it expires. So you can just buy a 3-year long cert before 7/29 and use it to sign any drivers for these 3 years. 3 years later, we have no other choice but to buy an EV cert, but who knows whether Microsoft would change its driver signing policy again then? Am I understanding it right? Hi Yang, That's not my understanding. What matters here is the driver signing timestamp, and not the expiry date of your certificate. You have 3 cases: - a driver signed with a timestamp prior to the 29th of July will still load for backward compatibility (same rules as previous Windows versions) - for drivers with a signature timestamp from the 29th of July or later, you need to upload your signed driver on Microsoft portal to get a counter signature that will allow to install it on Windows 10 - 90 days after the 29th of July, the portal will not accept anymore drivers not signed with an EV certificate So as you see the grace period will be short and you cannot escape from the purchase of an EV certificate (unless you hurry up to Polish your driver before the deadline;)). Even the counter signature step seems a bit painful (I have not tried it myself yet). Pascal. I agree the intentions are not clear. The statement *To ensure backwards compatibility, drivers which are properly signed by a valid cross-signing certificate that was issued before the release of Windows 10 will continue to pass signing checks on Windows 10.* implies to me that it's the date of the cross-signing certificate that counts. IMHO if it was the driver signing date, then the sentence should have read *... drivers which are properly signed by a valid cross-signing certificate that were signed before ...* Currently, when signing kernel-mode drivers you currently have to use the MS cross-signing appropriate to the issuer of your SPC. I checked the one we use in the day job, it was issued Feb 22 2011 and it's valid until Feb 22 2021. Of course MS may revoke that cert, but then existing signed drivers for Windows 10 will also fail. I'll try to get some clarity on this. -- Graham Bloice ___ Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org Archives:https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
[Wireshark-dev] Windows CMake, multiple copies of libffi-6.dll
Windows CMake always copies libffi-6.dll into the runtime directory, because it's found in two places in the support libraries, gnutls and gtk2. The version from gnutls is copied first, then overwritten by the gtk2 version, then on the next build the same happens again. because both copies are triggered if the file is different. Unfortunately, although the files are different sizes, neither has any resources embedded indicating version or build numbers to be able to determine which one is best. Does anyone know which one we should be using? Currently the gtk2 one is going out in builds, so seems to be OK. -- Graham Bloice ___ Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org Archives:https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] Windows Automated Builds missing init.lua
On 3 July 2015 at 00:22, Diego Nieto Cid dnie...@gmail.com wrote: Hi I'm having some trouble with the installation of the automated builds in Windows 8.1 64-bits. Everything goes well but when I try to load a Lua plugin Wireshark shows the message Lua Error ... attempt to index global 'base' (a nil value). AFAIK, 'base' should be defined by init.lua. But I cannot find any trace of that file neither in the installation directory nor in the exe itself (as shown by 7-Zip). I just downloaded version 1.99.8-267-gbcf7533. Below are the details of the downloaded file: URL: https://www.wireshark.org/download/automated/win64/Wireshark-win64-1.99.8-267-gbcf7533.exe My MD5: 957facb2e2c82b28ff9101c8bd09c060 My SHA-1: a49be3fdf9ad8285c51f5dd893459b1dcfe6d7c9 I've been trying with different versions since yesterday and all had the same problem. Even the released version, 1.99.7[1], doesn't have init.lua. Only the stable release, 1.12.6[2], has that file. 'console.lua' and 'dtd_gen.lua' are also missing. Anybody knows what's going on? Thanks! Diego Some recent commits, 0997129 and c00e469 should have fixed this. -- Graham Bloice ___ Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org Archives:https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
[Wireshark-dev] Windows x64 buildbot warnings
The buildbot is generating some warnings in the template instantiations of the sort: 73C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\include\algorithm(3050): warning C4267: 'argument' : conversion from 'size_t' to 'int', possible loss of data (C:\buildbot\wireshark\wireshark-master-64\win7x64\build\ui\qt\wireshark_application.cpp) [C:\buildbot\wireshark\wireshark-master-64\win7x64\build\cmbuild\ui\qt\qtui.vcxproj] C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\include\algorithm(3065) : see reference to function template instantiation 'void std::_Median_RanIt,bool(__cdecl *)(const QAction *,const QAction *)(_RanIt,_RanIt,_RanIt,_Pr)' being compiled with [ _RanIt=QListQAction *::iterator ,_Pr=bool (__cdecl *)(const QAction *,const QAction *) ] C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\include\algorithm(3127) : see reference to function template instantiation 'std::pair_RanIt,_RanIt std::_Unguarded_partition_RanIt,bool(__cdecl *)(const QAction *,const QAction *)(_RanIt,_RanIt,_Pr)' being compiled with [ _RanIt=QListQAction *::iterator ,_Pr=bool (__cdecl *)(const QAction *,const QAction *) ] C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\include\algorithm(3157) : see reference to function template instantiation 'void std::_Sort_Iter,int,bool(__cdecl *)(const QAction *,const QAction *)(_RanIt,_RanIt,_Diff,_Pr)' being compiled with [ _Iter=QListQAction *::iterator ,_RanIt=QListQAction *::iterator ,_Diff=int ,_Pr=bool (__cdecl *)(const QAction *,const QAction *) ] C:\buildbot\wireshark\wireshark-master-64\win7x64\build\ui\qt\wireshark_application.cpp(591) : see reference to function template instantiation 'void std::sortQListQAction *::iterator,bool(__cdecl *)(const QAction *,const QAction *)(_RanIt,_RanIt,_Pr)' being compiled with [ _RanIt=QListQAction *::iterator ,_Pr=bool (__cdecl *)(const QAction *,const QAction *) ] 73C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\include\algorithm(3051): warning C4267: 'argument' : conversion from 'size_t' to 'int', possible loss of data (C:\buildbot\wireshark\wireshark-master-64\win7x64\build\ui\qt\wireshark_application.cpp) [C:\buildbot\wireshark\wireshark-master-64\win7x64\build\cmbuild\ui\qt\qtui.vcxproj] 73C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\include\algorithm(3052): warning C4267: 'argument' : conversion from 'size_t' to 'int', possible loss of data (C:\buildbot\wireshark\wireshark-master-64\win7x64\build\ui\qt\wireshark_application.cpp) [C:\buildbot\wireshark\wireshark-master-64\win7x64\build\cmbuild\ui\qt\qtui.vcxproj] 73C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\include\algorithm(3053): warning C4267: 'argument' : conversion from 'size_t' to 'int', possible loss of data (C:\buildbot\wireshark\wireshark-master-64\win7x64\build\ui\qt\wireshark_application.cpp) [C:\buildbot\wireshark\wireshark-master-64\win7x64\build\cmbuild\ui\qt\qtui.vcxproj] I can't replicate this in an x64 build, but I'm using Qt 5.4 and the buildbot is using 5.3, I wonder if this is a QT issue fixed by the later version? -- Graham Bloice ___ Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org Archives:https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] Plan to make NPcap available for Wireshark
On 7 July 2015 at 16:56, Joerg Mayer jma...@loplof.de wrote:
On Mon, Jul 06, 2015 at 10:42:50AM +0800, Yang Luo wrote:
The first reason is causing more efforts for apps. Nearly all apps I know
have hard-coded the DLL file name, wpcap.dll by implicitly linking the
.lib
or LoadLibrary call. If I changed this name, all apps will need
modification for NPcap. LoadLibrary is easy to change, just add another
file name for its argument, but changing the implicit linking to NPcap
will
be much more pain, needs changing the SDK, changing the SDK means to give
up WinPcap, and even NPcap don't have a SDK yet, he has to compile with
NPcap from source. I don't see any softwares except Wireshark and nmap
would like to do this for NPcap. Because as you said, WinPcap can still
work under Win10, there's no indispensable reason for other apps to do
that
much for NPcap.
While I understand the logic behind our argument, I don't agree with it:
With the possibility of winpcap and npcap diverging, that may at one point
in time mean diverging and incompatible APIs. Also, what happens if a user
wants to use Wireshark with winpcap and also wants to use npcap? Does your
proposal have a solution to this?
Second reason is that from what I see, most apps use the Windows DLL
search
order, while I didn't test much, but at least nmap and WinDump does. Only
Wireshark has hard-coded DLL folder for now. Perhaps system32 is a
standard way we know to put DLLs, however using another DLL path and
adding it to Environment Variable %PATH% is also a standard way, it's
not
less secure than system32 way because a user needs Administrator right to
modify machine-wide options in Environment Variable. You may think that a
malicious user can mess with his own user-wide options, adding some
malicious path to his own %PATH%, but in that condition Wireshark will
probably also run under that user (Non-administrator right). So still no
harm to the Administrator-protected resources. Of course, if the
malicious
user is an Administrator, he can do whatever he wants, including
modifying
Environment Variable and messing with system32.
I never understood the nature of the security vulnerability in detail, but
hopefully someone who understands it can comment on that argument - my gut
feeling is that you are missing something, otherwise Gerald wouldn't have
made the effort to fix this the way he did.
The security vulnerability is DLL hijacking. See
http://resources.infosecinstitute.com/dll-hijacking/ for one explanation.
Basically apps should ensure they are loading DLL's from absolute known
paths, i.e. the app directory (or below) and the system paths.
BTW, I found that apps all like to hard-coded some names in WinPcap. Nmap
and Wireshark hard-coded the npf.sys driver name, Wireshark even
hard-coded the adapter binding name (like \Device\NPF_{}, but we
have
changed it to \Device\NPCAP_{}). I have changed this adapter
binding
name back to NPF for compatibility, but the driver name NPcap uses is
npcap.sys and cannot be changed back to npf.sys, because driver names
are system-global. So I think the logic checking npf.sys in Wireshark
also needs some change.
IMO using NPCAP or winpcap should be a compile time option with the
possiblity
to enable both options at the same time (in which case there should be an
option
to select preference). So I really think that npcap should start using
different
binary names and use standard directories instead of the non-standard
solution
you are using right now.
The Wireshark suite doesn't hard-code npf.sys per se, it just uses the
Service Control Manager (SCM) to check the state of the npf service. To
allow co-existence of both WinPCap and NPcap on the same machine that
service name should be different for the two libraries.
Arguably that check is a user convenience type of thing, because users
have, in the past, stopped the service and been unable to capture.
--
Graham Bloice
___
Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] Plan to make NPcap available for Wireshark
As WinPcap and NPcap seem to be diverging, in the short-term at least, should the dll's be named differently? The following is just an observation, not intended as any criticism. As NPCap has chosen to co-exist with WinPCap by using a (non-standard) Windows directory, although that (currently) doesn't seem to have any ill-effects, a similar co-existence choice would be to name the binaries differently and then use the standard directories. This would also enable using apps to not to have to hard-code the non-standard directory in any LoadLibrary() call to check at runtime for either version. On 5 July 2015 at 18:06, Yang Luo hslu...@gmail.com wrote: Good question, Graham. This is simply because WinPcap has taken the System32\SysWow64 dirs and NPcap wants to coexist with WinPcap. As NPcap has the same file names (wpcap.dll and packet.dll) for compatibility, we just can't put the the-same-name files in the same folder with WinPcap. Though I personally prefer the way to Make NPcap and WinPcap mutually exclusive (this needs user softwares like Wireshark and Nmap nothing to change), coexisting way has also its benefits, and finally we chose the latter. Cheers, Yang On Sun, Jul 5, 2015 at 1:28 AM, Graham Bloice graham.blo...@trihedral.com wrote: Out of interest why does NPcap not place its DLL's in System32\SysWow64 as that is on the standard DLL search path? On 4 July 2015 at 17:28, Yang Luo hslu...@gmail.com wrote: Hi Pascal, I hold the same opinion with you, because a user installing NPcap implies that he wants to use it, I think I will make it this way:) Cheers, Yang On Sat, Jul 4, 2015 at 6:07 PM, Pascal Quantin pascal.quan...@gmail.com wrote: Le 4 juil. 2015 4:26 AM, Yang Luo hslu...@gmail.com a écrit : Hi list, Given that current Wireshark can't make use of NPcap because of the DLL search path problem mentioned in https://www.wireshark.org/lists/wireshark-dev/201506/msg00030.html, I'd like to make a patch for Wireshark. As it is a security consideration that Wireshark don't want to search the DLLs in the Windows way. My plan is to explicitly add the NPcap path to Wireshark's DLL search logic. NPcap uses the C:\Windows\System32\NPcap and C:\Windows\SysWow64\NPcap to store its DLLs (WinPcap uses C:\Windows\System32 and C:\Windows\SysWow64 directly). As it is a sub directory of System32 folder. Its access control policy is the same with System32, and there should be no security problem I think. The second question is if WinPcap and NPcap are both available in a system, which will be loaded first? I'd like to hear your opinions:) Cheers, Yang Hi Yang, As WinPcap is older and could be installed for other programs, on my side I would consider NPcap has having higher precedence and be loaded first. Best regards, Pascal. ___ Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org Archives:https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org ?subject=unsubscribe ___ Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org Archives:https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org ?subject=unsubscribe -- Graham Bloice Software Developer Trihedral UK Limited ___ Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org Archives:https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org ?subject=unsubscribe ___ Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org Archives:https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org ?subject=unsubscribe -- Graham Bloice Software Developer Trihedral UK Limited ___ Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org Archives:https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] Plan to make NPcap available for Wireshark
Out of interest why does NPcap not place its DLL's in System32\SysWow64 as that is on the standard DLL search path? On 4 July 2015 at 17:28, Yang Luo hslu...@gmail.com wrote: Hi Pascal, I hold the same opinion with you, because a user installing NPcap implies that he wants to use it, I think I will make it this way:) Cheers, Yang On Sat, Jul 4, 2015 at 6:07 PM, Pascal Quantin pascal.quan...@gmail.com wrote: Le 4 juil. 2015 4:26 AM, Yang Luo hslu...@gmail.com a écrit : Hi list, Given that current Wireshark can't make use of NPcap because of the DLL search path problem mentioned in https://www.wireshark.org/lists/wireshark-dev/201506/msg00030.html, I'd like to make a patch for Wireshark. As it is a security consideration that Wireshark don't want to search the DLLs in the Windows way. My plan is to explicitly add the NPcap path to Wireshark's DLL search logic. NPcap uses the C:\Windows\System32\NPcap and C:\Windows\SysWow64\NPcap to store its DLLs (WinPcap uses C:\Windows\System32 and C:\Windows\SysWow64 directly). As it is a sub directory of System32 folder. Its access control policy is the same with System32, and there should be no security problem I think. The second question is if WinPcap and NPcap are both available in a system, which will be loaded first? I'd like to hear your opinions:) Cheers, Yang Hi Yang, As WinPcap is older and could be installed for other programs, on my side I would consider NPcap has having higher precedence and be loaded first. Best regards, Pascal. ___ Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org Archives:https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org ?subject=unsubscribe ___ Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org Archives:https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org ?subject=unsubscribe -- Graham Bloice Software Developer Trihedral UK Limited ___ Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org Archives:https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] Is Wireshark maintaining the official WinPcap repo now?
On 3 July 2015 at 17:29, Yang Luo hslu...@gmail.com wrote: Hi list, Since the last mail about how to make NPcap available for Wireshark, I have been waiting for WinPcap's official repo's news and I fortunately found this these days: https://github.com/wireshark/winpcap, is this the official WinPcap repo now? If yes, then what's the review policy? Like recently we have added the Admin-only mode into NPcap, it restricts the capturing access only to Administrators for security purpose (see details in: https://github.com/nmap/npcap and http://nmap.org/soc/#winpcap). I don't know if the review party would like this idea? (and like other parts of NPcap like current NDIS 6 implementation). And how hard would it be for NPcap to be merged into WinPcap upstream? I noticed that this repo used gerrit for code review and it is kind of strict system in my mind:) Cheers, Yang Hi, As discussed elsewhere, and at Sharkfest with Fyodor, the Wireshark project is now hosting the official WinPCap repo ( https://code.wireshark.org/review/winpcap) and are using Gerrit for code reviews, etc. The github repo is a read-only copy. This repo is basically a dump from the internal Riverbed\Cace repo. The current plan is to make minimal changes to this code to get it compiling with a modern compiler (VS2013) and do whatever is necessary to make it run on Win 10. XP support *might* be lost during this. This will likely be WinPCap 4.1.4. After that all, things are up for consideration, including rewriting WinPCap for NDIS6, moving over to NPCap, synchronising with current libpcap, the security enhancement you mention etc. -- Graham Bloice ___ Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org Archives:https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] Patch: Changes for better dissection of Notify Response (mixed in with experimental Posix stuff)
On 29 June 2015 at 16:07, Richard Sharpe realrichardsha...@gmail.com wrote: On Mon, Jun 29, 2015 at 8:03 AM, Alexis La Goutte alexis.lagou...@gmail.com wrote: Hi Richard, It is better to push patch (even if it is WIP) on Gerrit... Yeah. If only I could figure out how to do it now that the authentication stuff changed (or didn't). Noting your gmail address, for Google logins, the newer OpenId Connect (OAuth 2.0) offered by Google is now supported by Gerrit. However you might need to associate that login with your Gerrit account. Try the Gerrit login page anyway, the Google login is the 2nd item in the list. Regards, On Mon, Jun 29, 2015 at 4:56 PM, Richard Sharpe realrichardsha...@gmail.com wrote: Hi folks, I got sick of Notify Responses not being correctly dissected, so I added support. Unfortunately, they are mixed in with my experimental Posix stuff as well. If I get time later this week I will try to extract them into a separate patch. -- Regards, Richard Sharpe (何以解憂？唯有杜康。--曹操) ___ Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org Archives:https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe ___ Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org Archives:https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org ?subject=unsubscribe -- Regards, Richard Sharpe (何以解憂？唯有杜康。--曹操) ___ Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org Archives:https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org ?subject=unsubscribe -- Graham Bloice Software Developer Trihedral UK Limited ___ Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org Archives:https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] Automated build for 1.99.8 on Windows missing?
On 29 June 2015 at 16:54, Gerald Combs ger...@wireshark.org wrote: On 6/29/15 5:51 AM, Roland Knall wrote: Hi I was just trying to find an automated build for Windows on https://www.wireshark.org/download/automated/ . The only builds I can find are for 1.12rc7 and PDB builds for 1.99.8, but no builds for 1.99.8 in either x86 or x64 directories. Has this been changed on purpose, or am I missing something? It looks like the NSIS packaging step is re-linking a bunch of executables after they've been signed, which causes the signature verification step to fail. I wonder if that's related to my change for the PortableApps installer dependency (https://code.wireshark.org/review/#/c/9153/). That change doesn't seem to have been totally successful at what was intended anyway. -- Graham Bloice ___ Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org Archives:https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] How to compile and execute the source code of wireshark?
On 18 June 2015 at 15:17, JAI BHAGWAN YADAV saurav.yadav0...@gmail.com wrote: Hello all, I am a beginner, Q- How to compile and execute the source code of wireshark so that (i) Whenever I will compile and execute it, it will also run wireshark (ii) I will use printf firstly so I can see the output at terminal O.S. used: 64 bit, Ubuntu 12.04 What I tried? I have tried ./autogen.sh It run successfully. then./configure It also run successfully, takes 2 minutes to execute on my system (1 GB RAM, virtual machine). thenmake It also run successfully, takes 15-20 approx minutes to execute. Only warnings can be seen in between of these execution but no error occured. *But also no wireshark window get opened, it will only open when I execute the command ./wireshark. So, please tell me the correct way and order to write all the commands*. I want to make changes in the menu bar so that it will show the changes made in the wireshark and also print the output of the printf instruction I will put in one of the code. Have a look at the Developers Guide, section 3.6 ( https://www.wireshark.org/docs/wsdg_html_chunked/ChSrcRunFirstTime.html) -- Graham Bloice ___ Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org Archives:https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] Problems with ui/qt/config.pri when switching compilers or architecture - should it be cleaned
I think so. Yet another good reason to use CMake and out-of-tree builds :-) On 16 June 2015 at 09:51, Anders Broman anders.bro...@ericsson.com wrote: Hi, Should config.pri be deleted when doing ”clean”? Add to Wireshark.pro? - win32: QMAKE_CLEAN += *.pdb + win32: QMAKE_CLEAN += *.pdb *.pri Regards Anders ___ Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org Archives:https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org ?subject=unsubscribe -- Graham Bloice Software Developer Trihedral UK Limited ___ Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org Archives:https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] Problems building on Mac OS Yosemite
Just a note pointing out the cmake build won't get fixed unless you tell us what failed. The OSX buildbots are building OK with it. On 5 June 2015 at 05:03, Simon Barber simon.bar...@meraki.net wrote: Thanks - deleting my entire macos-support-libs and restarting did the trick. I had tried to use the setup script a couple of months ago when it was broken, and there was probably something left behind from that. cmake didn't work but configure gets me a working wireshark-gtk. Simon On Mon, Jun 1, 2015 at 7:39 PM, Guy Harris g...@alum.mit.edu wrote: On May 29, 2015, at 11:23 PM, Simon Barber simon.bar...@meraki.net wrote: On May 29, 2015 11:20 PM, Guy Harris g...@alum.mit.edu wrote: On May 29, 2015, at 9:16 PM, Simon Barber simon.bar...@meraki.net wrote: I'm trying to build wireshark out of the git repository, master branch, on my Mac OS Yosemite machine. You've installed XQuartz, right? Yes. xlogo runs OK. What does ls -ld /usr/X11 print? If it prints ls: /usr/X11: No such file or directory then you probably installed XQuartz on a machine running a pre-Yosemite version of OS X, and then upgraded to Yosemite, and the Yosemite installer proceeded to trash your XQuartz installation. Do sudo ln -s /opt/X11 /usr/X11 to fix the XQuartz installation, and then, in your source directory, do rm -rf macosx-support-libs and re-run the macosx-setup.sh script. If ls -ld /usr/X11 doesn't print ls: /usr/X11: No such file or directory, what does ls -l /usr/X11/lib/libcairo.la print? ___ Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org Archives:https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org ?subject=unsubscribe ___ Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org Archives:https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org ?subject=unsubscribe -- Graham Bloice Software Developer Trihedral UK Limited ___ Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org Archives:https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] PVS-Studio analysis of Wireshark
I've dabbled with PVS a little bit, the output does seem to find a few things other static analyzers miss, but the reverse also applies. Unfortunately they don't seem to offer free licences for Open source projects, although they do use open source projects as demos for their software, see http://www.viva64.com/en/examples/. On 4 June 2015 at 19:09, Alexis La Goutte alexis.lagou...@gmail.com wrote: On Thu, Jun 4, 2015 at 7:21 PM, Gerald Combs ger...@wireshark.org wrote: Andrey Kalashnikov analyzed Wireshark using the PVS-Studio static analyzer and wrote up an interesting report at http://www.viva64.com/en/b/0328/ . Thanks to Andrey, It looks like we've fixed a couple of the errors independently but the rest look easy enough to fix. Yes and need also to try on master branch... ___ Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org Archives:https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org ?subject=unsubscribe ___ Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org Archives:https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org ?subject=unsubscribe -- Graham Bloice Software Developer Trihedral UK Limited ___ Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org Archives:https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] Qt version for the Wireshark Windows build
I did do a quick check when Roland asked, and got there from https://www.qt.io/download-open-source/ - Qt 5.3 and all older versions of Qt are available in the archive - http://download.qt.io/archive/qt/ and so on, but wondered if that was the version that he said actually downloaded a 32 bit copy. On 3 June 2015 at 16:39, Gerald Combs ger...@wireshark.org wrote: It looks like direct downloads are available at https://download.qt.io/official_releases/qt/ I got there by copying one of the online installer links listed at https://www.qt.io/download-open-source/ and trimming off the file and version. On 6/3/15 7:32 AM, Roland Knall wrote: Hi Is it possible to download the Qt version, with which the buildbot builds the windows version of Wireshark? Our company has switched to 5.4 and the plugin I am building uses a Qt class, which introduced flags only available with 5.4. If I load my plugin in wireshark, wireshark claims the missing flags and functions (as it runs with Qt 5.3.1 and of course has never seen those methods). So I would be able to build with 5.3.1, but the issue being, that Digia does not allow the 64bit version of older releases to be downloaded (if you do, you end up with the 32bit, although the download clearly states 64bit). So, long story short, does anyone have a 5.3.1 version with real 64bit lying around or can I download the buildbot version somewhere? anonsvn did not contain a version for msvc2013. regards, Roland p.s.: I know I can build from scratch. so far I am avoiding that, but it might be my only option left. ___ Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org Archives:https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org ?subject=unsubscribe ___ Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org Archives:https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org ?subject=unsubscribe -- Graham Bloice ___ Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org Archives:https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] Custom zlib for Windows builds
On 28 April 2015 at 15:08, Bálint Réczey bal...@balintreczey.hu wrote: Fixing zlib address. 2015-04-28 16:05 GMT+02:00 Bálint Réczey bal...@balintreczey.hu: Hi Graham, I would not create a fork before asking zlib maintainters, thus copying them now. Dear Zlib Mainainters (Mark?), Do you plan accepting some of the pull requests listed on zlib's GitHub queue? We need some of the changes in Wireshark and it would be really nice if we would not have to diverge too much from zlib's master branch. Cheers, Balint tumbleweed. I'll create a zip with the required changes. Gerald, how do I get the new zip added to the store? -- Graham Bloice ___ Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org Archives:https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] [Wireshark-commits] master e16500e: Fix check for NUL at the end of a string.
On 13 May 2015 at 07:28, Bálint Réczey bal...@balintreczey.hu wrote: 2015-05-13 0:26 GMT+02:00 Guy Harris g...@alum.mit.edu: On May 12, 2015, at 3:13 PM, Evan Huus eapa...@gmail.com wrote: Argh, one of these days I will learn to just put parentheses in rather than taking guesses at C operator precedence :( Yeah, the rule I've found works best for me is if you aren't certain, throw parentheses at it. Yes, in this case parentheses are a must. I also llike putting them when the reader may not guess the precedence correctly easily. This reader can be myself later ;-). I have a colleague who for reasons only known to himself is violently against unnecessary parentheses, so I always put in even more just for him. My rule is to parenthesise wherever multiple operators appear in an expression. Even more important where the team is working in multiple programming languages with different precedence rules. -- Graham Bloice ___ Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org Archives:https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] Gerrit upgrade tomorrow
On 9 May 2015 at 01:34, Gerald Combs ger...@wireshark.org wrote: The upgrade is complete. Logging in using your Google account, which was initially OK and then not OK is once again OK. You can now link your GitHub account as well. In either case if you have an existing account you should make sure your identities are properly linked by doing the following: - Log in using your existing OpenID provider - Go to https://code.wireshark.org/review/#/settings/web-identities - Click Link Another Identity Seems to work for me, without needing to relink my old Google identity. On the signin page the links for Google and Github were plain text rather than any icon, is that intentional? -- Graham Bloice ___ Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org Archives:https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] Custom zlib for Windows builds
On 27 April 2015 at 16:45, Pascal Quantin pascal.quan...@gmail.com wrote: 2015-04-27 17:33 GMT+02:00 Graham Bloice graham.blo...@trihedral.com: The remaining CMake warnings for Windows are caused by zlib, as newer CMake versions complain about policy settings. As the zlib maintainers seem very reluctant to incorporate changes (31 pull requests at the moment oldest from 2 years ago) to fix this we would have to roll our own zlib for download. The changes required are minimal, but we do do this we could also usefully incorporate another change on their pull requests to disable the building of the example binaries. Thoughts? Hi Graham, as we are already hosting the zblib 1.2.8 source code to compile it, I guess nothing prevents us to start customizing it a bit and putting the details in a README.wireshark (like we do for other 3rd party components). I'll have a go at producing a new one, what name do we give it zlib-1.2.8-ws? -- Graham Bloice ___ Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org Archives:https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
[Wireshark-dev] Custom zlib for Windows builds
The remaining CMake warnings for Windows are caused by zlib, as newer CMake versions complain about policy settings. As the zlib maintainers seem very reluctant to incorporate changes (31 pull requests at the moment oldest from 2 years ago) to fix this we would have to roll our own zlib for download. The changes required are minimal, but we do do this we could also usefully incorporate another change on their pull requests to disable the building of the example binaries. Thoughts? -- Graham Bloice ___ Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org Archives:https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] [Wireshark-commits] master 9b5a09a: [Automatic update for 2015-04-26]
We're really close to not worrying about that :-) On 26 April 2015 at 19:01, Alexis La Goutte alexis.lagou...@gmail.com wrote: Hi Evan, Martin have start to work for generate qm files but the problem is don't (yet) work for nmake... https://code.wireshark.org/review/#/c/7597/ Regards, On Sun, Apr 26, 2015 at 7:29 PM, Evan Huus eapa...@gmail.com wrote: Now that the translation files are being updated every week, we really need to remove the binary files from the repo. I know it's been discussed before, but anybody with a working qt-dev installation should be able to generate the .qm files from the .ts files, yes? On Sun, Apr 26, 2015 at 11:07 AM, Wireshark code review code-review-do-not-re...@wireshark.org wrote: URL: https://code.wireshark.org/review/gitweb?p=wireshark.git;a=commit;h=9b5a09aa3479b56b111439222397f239b477cda8 Submitter: Gerald Combs (ger...@wireshark.org) Changed: branch: master Repository: wireshark Commits: 9b5a09a by Gerald Combs (ger...@wireshark.org): [Automatic update for 2015-04-26] Update manuf, services enterprise-numbers, translations, and other items. Change-Id: I431063783434a6f7a9a4f4b8186316ed3f98005b Reviewed-on: https://code.wireshark.org/review/8199 Reviewed-by: Gerald Combs ger...@wireshark.org Actions performed: from 0437280 C15ch: fix o previous prototype for function [-Wmissing-prototypes] adds 9b5a09a [Automatic update for 2015-04-26] Summary of changes: epan/dissectors/usb.c| 76 ++--- epan/enterprise-numbers | 116 +++- epan/sminmpec.c | 30 - manuf| 46 +++- services | 18 +-- ui/qt/wireshark_it.qm| Bin 239430 - 239746 bytes ui/qt/wireshark_it.ts|4 +- ui/qt/wireshark_zh_CN.qm | Bin 173107 - 173233 bytes ui/qt/wireshark_zh_CN.ts | 272 +++--- 9 files changed, 398 insertions(+), 164 deletions(-) ___ Sent via:Wireshark-commits mailing list wireshark-comm...@wireshark.org Archives:https://www.wireshark.org/lists/wireshark-commits Unsubscribe: https://wireshark.org/mailman/options/wireshark-commits mailto:wireshark-commits-requ...@wireshark.org ?subject=unsubscribe ___ Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org Archives:https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org ?subject=unsubscribe ___ Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org Archives:https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org ?subject=unsubscribe -- Graham Bloice Software Developer Trihedral UK Limited ___ Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org Archives:https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
[Wireshark-dev] Test
Someone reported the mail list was down, please ignore. -- Graham Bloice ___ Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org Archives:https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] Gerrit upgrade schedule
On 16 April 2015 at 22:45, Pascal Quantin pascal.quan...@gmail.com wrote: Le 16 avr. 2015 11:29 PM, Gerald Combs ger...@wireshark.org a écrit : On 4/16/15 1:17 PM, Pascal Quantin wrote: 2015-04-02 1:06 GMT+02:00 Gerald Combs ger...@wireshark.org mailto:ger...@wireshark.org: As was discussed last month, Google's OpenID is going away on the 20th. Logins to code.wireshark.org http://code.wireshark.org using Google will break on that date. The Gerrit development team has been busy making releases recently to account for this. Unfortunately, a change which would allow both OpendID and OAuth2 logins[1] and which would be useful in our case is still under review and hasn't made it into an official release. This Friday (April 3) I plan on upgrading to Gerrit from 2.8.6.1 to 2.10.2. This will make the new change screen the default along with many other changes listed in [2] and [3]. The authentication configuration will not change for now, but we'll be in a better position to do so in the future. Sorry for the short notice. I'm trying to balance Gerrit's release schedule, the impending OpenID apocalypse, and upcoming travel. [1]https://gerrit-review.googlesource.com/#/c/66313/ [2] http://gerrit-documentation.storage.googleapis.com/ReleaseNotes/ReleaseNotes-2.9.html#_new_features [3] http://gerrit-documentation.storage.googleapis.com/ReleaseNotes/ReleaseNotes-2.9.html#_new_features Hi Gerald, Gerrit 2.10.3 just got released with the change set you were referring to merged: https://gerrit-documentation.storage.googleapis.com/ReleaseNotes/ReleaseNotes-2.10.3.html Thanks! Unfortunately I'm traveling next week so our earliest upgrade windows are either tomorrow or some time the week of the 27th. I'll tentatively plan for May 1. Too bad, I thought I could afford to avoid creating a Launchpad account ;) Me too. No worries though, I'll survive. -- Graham Bloice ___ Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org Archives:https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] Windows automated builds migrated to CMake
Woohoo. Change to delete *.nmake incoming :-) On 16 April 2015 at 04:06, Gerald Combs ger...@wireshark.org wrote: We reached a bit of a milestone today. The packages created by the 32-bit and 64-bit Windows builders at https://buildbot.wireshark.org/trunk/waterfall are now produced using CMake and MSBuild. Thanks to everyone for helping to get the Windows CMake environment up and running! ___ Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org Archives:https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org ?subject=unsubscribe -- Graham Bloice Software Developer Trihedral UK Limited ___ Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org Archives:https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] Windows automated builds migrated to CMake
On 16 April 2015 at 09:29, Roland Knall rkn...@gmail.com wrote: Also, the wiki pages do not seem to reflect the cmake build and the buildbot waterfall display only seem to run cmake, but not build using it? Would be helpful to setup a cmake enforced build on Windows, which is still a little bit tricky (even using MSVC2013 and Qt). The buildbot builds using CMake first, both x86 and x64 including packaging and tests and then repeats using nmake. The automated installers are now from the CMake build. The Windows Petri-dish buildbot also builds with CMake (and has done for some time). -- Graham Bloice ___ Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org Archives:https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] Windows automated builds migrated to CMake
On 16 April 2015 at 10:11, Roland Knall rkn...@gmail.com wrote: Hi Very cool + 1 The waterfall display was a little bit misleading, but found it now. Still waiting for the get-go in my company to install VS2013, but will try it as soon as possible. VS2015 is out soon! I suspect that the 1.99.x and 2.0.x releases will use VS2013 though as the primary compiler. I don't know of anyone using VS2012 (or 2010) with the CMake build, but it might work. It would be good to know for the docs update. As of dependencies, this leaves more or less the mac plattform with the setup script. I played around with that last week, and it seems, port is a better solution for Mac then the setup script. I am going to write a README.macosx detailing what and how things must be installed. Maybe this can be automated using cmake as well. Presumably in a similar manner to that done for the Windows build, a call out to something external from CMake to do that task. -- Graham Bloice ___ Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org Archives:https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] Windows automated builds migrated to CMake
On 16 April 2015 at 09:29, Roland Knall rkn...@gmail.com wrote: Hi Am I correct, that as for now, there is no plan to move the download of the necessary libraries for building Wireshark on Windows from the nmake system to cmake as well? The download of libraries is in CMake (excepting QT). See change 7990 ( https://code.wireshark.org/review/#/c/7990/). Also, the wiki pages do not seem to reflect the cmake build and the buildbot waterfall display only seem to run cmake, but not build using it? Would be helpful to setup a cmake enforced build on Windows, which is still a little bit tricky (even using MSVC2013 and Qt). The Developers Guide hasn't been updated yet, README.cmake is the current source of info. There are still some loose ends to tidy up, e.g. PortAudio and CMake warnings but it's usable as is. -- Graham Bloice ___ Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org Archives:https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] Windows automated builds migrated to CMake
On 16 April 2015 at 11:49, Pascal Quantin pascal.quan...@gmail.com wrote: 2015-04-16 5:06 GMT+02:00 Gerald Combs ger...@wireshark.org: We reached a bit of a milestone today. The packages created by the 32-bit and 64-bit Windows builders at https://buildbot.wireshark.org/trunk/waterfall are now produced using CMake and MSBuild. Thanks to everyone for helping to get the Windows CMake environment up and running! Hi Gerald, one thing I noticed is that the Wireshark 1.99.6-243 32 bits coming from the buildbot (and thus CMake) systematically open a console window (both with Qt and GTK GUI) whatever my console window setting. This does not happen when I compile locally the same release with nmake. I have not installed CMake yet on my machine to cross check, but it seems that we still have discrepancies between nmake and CMake. This is down to the subsystem type. The nmake builds are marked as Windows Gui and the CMake builds as Windows Console. It's a linker flag, supplied in $(guiflags) for nmake builds (or $(conflags) for command line programs e.g. tshark.exe). I think CMake requires a set_target_properties(target_name PROPERTIES LINK_FLAGS /SUBSYSTEM:WINDOWS) call for each gui target. -- Graham Bloice ___ Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org Archives:https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] nmake setup target failing for me
You should never, ever have Cywgin DLL's or executables in System 32. Source of much misery. They should all live in their own bin dir, appropriate for the Cygwin installation. You can even have multiple Cygwin installations if you're careful to keep the paths appropriate for the applications using them. On 9 April 2015 at 15:24, Martin Mathieson martin.r.mathie...@googlemail.com wrote: Hi Pascal, I am running Windows Enterprise 7.0 with service pack 1. It should be up to date with patches, but it may be a week or 2 since I rebooted it. I did have both the (later version) cygwin wget.exe and what looks like the same, older version in 4 different places. After replacing the one in C:\Windows\System32 with the Cygwin one, it grumbled about cygwin1.dll and cyggnutls-28.dll, which I'd rather not install. There was no problem with browsing to the folder with the library files, and for now I have downloaded zip128.zip manually. Martin On Thu, Apr 9, 2015 at 2:47 PM, Pascal Quantin pascal.quan...@gmail.com wrote: 2015-04-09 15:28 GMT+02:00 Martin Mathieson martin.r.mathie...@googlemail.com: I was prompted to run setup, but am getting this. Any ideas? Martin ** zlib128.zip ** No HTTP proxy specified (http_proxy and HTTP_PROXY are empty). Downloading zlib128.zip into '/cygdrive/c/Wireshark-win32-libs', installing into . --14:23:50-- https://anonsvn.wireshark.org/wireshark-win32-libs/tags/2015-04-06 /packages/zlib128.zip = `zlib128.zip' Resolving anonsvn.wireshark.org... 174.137.42.70 Connecting to anonsvn.wireshark.org|174.137.42.70|:443... connected. ERROR: Certificate verification error for anonsvn.wireshark.org: unable to get l ocal issuer certificate To connect to anonsvn.wireshark.org insecurely, use `--no-check-certificate'. Unable to establish SSL connection. ERROR: Can't download https://anonsvn.wireshark.org/wireshark-win32-libs/tags/20 15-04-06/packages/zlib128.zip Hi Martin, I do not have any issue on my side. As anonsvn is using a SHA256 certificate, it suggests that your local host does not have the intermediate certificate installed, or deoes not support SHA256. On which Windows version are you running, and is it up-to-date with the latest Windows patch applied? According to http://blogs.technet.com/b/pki/archive/2013/11/12/sha1-deprecation-policy.aspx depending on the version you run, you might require some hotfixes applied. Can you load https://anonsvn.wireshark.org/viewvc/tags/2015-04-06/?root=Wireshark-win32-libs with your web browser? As a workaround, you can edit win-setup.sh so as to add the --no-check-certificate option as suggested by the output message. Pascal. ___ Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org Archives:https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org ?subject=unsubscribe ___ Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org Archives:https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org ?subject=unsubscribe -- Graham Bloice Software Developer Trihedral UK Limited ___ Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org Archives:https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] nmake setup target failing for me
Possibly this: https://code.wireshark.org/review/#/c/7948/ On 9 April 2015 at 14:28, Martin Mathieson martin.r.mathie...@googlemail.com wrote: I was prompted to run setup, but am getting this. Any ideas? Martin ** zlib128.zip ** No HTTP proxy specified (http_proxy and HTTP_PROXY are empty). Downloading zlib128.zip into '/cygdrive/c/Wireshark-win32-libs', installing into . --14:23:50-- https://anonsvn.wireshark.org/wireshark-win32-libs/tags/2015-04-06 /packages/zlib128.zip = `zlib128.zip' Resolving anonsvn.wireshark.org... 174.137.42.70 Connecting to anonsvn.wireshark.org|174.137.42.70|:443... connected. ERROR: Certificate verification error for anonsvn.wireshark.org: unable to get l ocal issuer certificate To connect to anonsvn.wireshark.org insecurely, use `--no-check-certificate'. Unable to establish SSL connection. ERROR: Can't download https://anonsvn.wireshark.org/wireshark-win32-libs/tags/20 15-04-06/packages/zlib128.zip ___ Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org Archives:https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org ?subject=unsubscribe -- Graham Bloice Software Developer Trihedral UK Limited ___ Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org Archives:https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] nmake setup target failing for me
In my Wireshark dev VM's, I don't have Cygwin on the path at all, but then I don't use anything in Cygwin for tasks outside of the Wireshark build. nmake builds pick the path up as configured in config.nmake (there are a number of defaults that are checked, and CMake does it's own search thing. If you must have Cygwin on the path then it should be in the appropriate spot for you, i.e. should you want to use Cygwin executable rather than an identically named Windows version, then Cygwin will have to be in the path before System32. I would remove any wget from System32. Do you know how it got in there? I have come across some applications that rely on Cygwin internally (usually ports of posix tools) and some very old ones did naughtily ram things in to System32. On 9 April 2015 at 15:52, Martin Mathieson martin.r.mathie...@googlemail.com wrote: Indeed I have seen the problems with copying Cygwin DLLs to Windows folders. I don't currently have C:\cygwin\bin in my Windows PATH: - is it safe to add it ahead of C:\Windows\System32? - or would you recommend deleting the wget.exe from there so that it'll use the cygwin wget.exe instead? Thanks, Martin On Thu, Apr 9, 2015 at 3:35 PM, Graham Bloice graham.blo...@trihedral.com wrote: You should never, ever have Cywgin DLL's or executables in System 32. Source of much misery. They should all live in their own bin dir, appropriate for the Cygwin installation. You can even have multiple Cygwin installations if you're careful to keep the paths appropriate for the applications using them. On 9 April 2015 at 15:24, Martin Mathieson martin.r.mathie...@googlemail.com wrote: Hi Pascal, I am running Windows Enterprise 7.0 with service pack 1. It should be up to date with patches, but it may be a week or 2 since I rebooted it. I did have both the (later version) cygwin wget.exe and what looks like the same, older version in 4 different places. After replacing the one in C:\Windows\System32 with the Cygwin one, it grumbled about cygwin1.dll and cyggnutls-28.dll, which I'd rather not install. There was no problem with browsing to the folder with the library files, and for now I have downloaded zip128.zip manually. Martin On Thu, Apr 9, 2015 at 2:47 PM, Pascal Quantin pascal.quan...@gmail.com wrote: 2015-04-09 15:28 GMT+02:00 Martin Mathieson martin.r.mathie...@googlemail.com: I was prompted to run setup, but am getting this. Any ideas? Martin ** zlib128.zip ** No HTTP proxy specified (http_proxy and HTTP_PROXY are empty). Downloading zlib128.zip into '/cygdrive/c/Wireshark-win32-libs', installing into . --14:23:50-- https://anonsvn.wireshark.org/wireshark-win32-libs/tags/2015-04-06 /packages/zlib128.zip = `zlib128.zip' Resolving anonsvn.wireshark.org... 174.137.42.70 Connecting to anonsvn.wireshark.org|174.137.42.70|:443... connected. ERROR: Certificate verification error for anonsvn.wireshark.org: unable to get l ocal issuer certificate To connect to anonsvn.wireshark.org insecurely, use `--no-check-certificate'. Unable to establish SSL connection. ERROR: Can't download https://anonsvn.wireshark.org/wireshark-win32-libs/tags/20 15-04-06/packages/zlib128.zip Hi Martin, I do not have any issue on my side. As anonsvn is using a SHA256 certificate, it suggests that your local host does not have the intermediate certificate installed, or deoes not support SHA256. On which Windows version are you running, and is it up-to-date with the latest Windows patch applied? According to http://blogs.technet.com/b/pki/archive/2013/11/12/sha1-deprecation-policy.aspx depending on the version you run, you might require some hotfixes applied. Can you load https://anonsvn.wireshark.org/viewvc/tags/2015-04-06/?root=Wireshark-win32-libs with your web browser? As a workaround, you can edit win-setup.sh so as to add the --no-check-certificate option as suggested by the output message. Pascal. ___ Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org Archives:https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org ?subject=unsubscribe ___ Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org Archives:https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org ?subject=unsubscribe -- Graham Bloice Software Developer Trihedral UK Limited ___ Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org Archives:https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https
Re: [Wireshark-dev] CMake on Windows - Can build, but not run executable
I seem to remember earlier issues with other folks using VS2012 and wanting a 64 bit build, due to qt support problems. VS2013 CE is available for free, you might want to consider that. As for CMake build instructions did you look at README.cmake in the top level sources? When we get CMake totally sorted, I'll update the Developers Guide to use that rather than nmake. Still some things to do yet. On 26 March 2015 at 13:10, Roland Knall rkn...@gmail.com wrote: Hi I have only VStudio 2012 available here at my workplace. Using CMake 3.0.2, msvc2012_64_opengl. The error log (in german) produces the following output: = Startet die Generierung des Aktivierungskontextes. Eingabeparameter: Flags = 0 ProcessorArchitecture = AMD64 CultureFallBacks = de-DE;de ManifestPath = C:\dev\Wireshark\cmakebuild\run\wireshark-gtk.exe AssemblyDirectory = C:\dev\Wireshark\cmakebuild\run\ Application Config File = - INFORMATION: Manifestdatei C:\dev\Wireshark\cmakebuild\run\wireshark-gtk.exe wird analysiert. INFORMATION: Die Manifestsdefinitionsidentität ist (null). FEHLER: Zeile 8: Der Wert des processorArchitecture-Attributs im assemblyIdentity-Element ist ungültig. FEHLER: Bei der Generierung des Aktivierungskontextes ist ein Fehler aufgetreten. Beendet die Generierung des Aktivierungskontextes. I am trying to build with 32bit now, and will keep you updated. I've figured it may have something to do with Qt, and the fact, that the package for opensource is only supporting 64 bit with VStudio2013. Why tshark and wireshark-gtk are affected by this, I can't really figure out. Btw, should there be another page on the wiki for building with cmake on Windows? Running the setup script was one thing, but the main thing with my devenv.bat was, that I used to set WIRESHARK_BASE_DIR, but with that I never got the build running. As soon as I set WIRESHARK_LIB_DIR as environment variable, the build worked. I used the stdio information from the buildbot to figure it out, but others may well have some issues here. regards, Roland On Wed, Mar 25, 2015 at 6:32 PM, Graham Bloice graham.blo...@trihedral.com wrote: On 25 March 2015 at 08:17, Roland Knall rkn...@gmail.com wrote: Hi I can build wireshark successfully (gtk and qt interfaces) on Windows, but If I want to execute it, he complains that the side-by-side configuration is not correct. If I trace the launch with sxstrace, he complains, that the ProcessorArchitecture is wrong for the target (amd64). The build is a Windows 64bit build Using VS2013, CMake 3.1.3, QT 5.4.1 msvc2013_64_opengl. I don't normally build x64, so gave it a go using the x64 native compiler and CMake fails configure, the testing for various sizes fails as CMake is asking the linker to use both x64 and x86 modes?? If I use the cross compiler (i.e. x86 building x64) then CMake does configure and the resulting build runs for me (both qt and gtk). I usually run depends (http://www.dependencywalker.com/) to check what DLL's etc are to be loaded. -- Graham Bloice ___ Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org Archives:https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org ?subject=unsubscribe ___ Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org Archives:https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org ?subject=unsubscribe -- Graham Bloice Software Developer Trihedral UK Limited ___ Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org Archives:https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] CMake on Windows - Can build, but not run executable
On 25 March 2015 at 08:17, Roland Knall rkn...@gmail.com wrote: Hi I can build wireshark successfully (gtk and qt interfaces) on Windows, but If I want to execute it, he complains that the side-by-side configuration is not correct. If I trace the launch with sxstrace, he complains, that the ProcessorArchitecture is wrong for the target (amd64). The build is a Windows 64bit build Using VS2013, CMake 3.1.3, QT 5.4.1 msvc2013_64_opengl. I don't normally build x64, so gave it a go using the x64 native compiler and CMake fails configure, the testing for various sizes fails as CMake is asking the linker to use both x64 and x86 modes?? If I use the cross compiler (i.e. x86 building x64) then CMake does configure and the resulting build runs for me (both qt and gtk). I usually run depends (http://www.dependencywalker.com/) to check what DLL's etc are to be loaded. -- Graham Bloice ___ Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org Archives:https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] Usage of make-version.pl
For Windows, the better way is to set an environment variable WIRESHARK_VERSION_EXTRA. I'm trying to get away from folks having to make changes to config.nmake just to build. See the Developers Guide section 2.2.9. Open a Visual Studio Command Prompt ( https://www.wireshark.org/docs/wsdg_html_chunked/ChSetupWin32.html#ChSetupPrepareCommandCom ). On 23 March 2015 at 17:38, Pascal Quantin pascal.quan...@gmail.com wrote: 2015-03-23 17:49 GMT+01:00 Juan Jose Martin Carrascosa jua...@rti.com: Hi all, I am building Wireshark for Windows, Linux and Mac. I have been reading and analyzing the make-version.pl script and I have found that I am not a perl expert: I have no idea about how to use version.conf. Can anyone tell me what to put in version.conf and what arguments to use when calling make-version.pl if I want to add an extra version like -ABCD? For instance, Wireshark 1.99.1-ABCD. Sorry for the newbie question! Hi Juanjo, this is supported natively for Windows, you just need to edit config.nmake to set the VERSION_EXTRA variable. For Linux/Mac, this does not seem to be supported out of the box. What you might try (but I have not verified this myself and I'm more a Windows guy so autofoo is kind of magic for me) is to edit configure.ac and put your string in the empty square brackets of the line: m4_append([version_micro_extra], []) Other might have a better answers ;) Regards, Pascal. ___ Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org Archives:https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org ?subject=unsubscribe -- Graham Bloice Software Developer Trihedral UK Limited ___ Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org Archives:https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] Latest code broken?
As a cross check you can always look at the buildbot status: https://buildbot.wireshark.org/trunk/waterfall If the buildbots succeed in compiling the latest master and you don't, then it's likely that the problem is in your environment. On 16 March 2015 at 04:28, Anil anilkumar...@gmail.com wrote: Pascal -- Thanks for the response. I tired various things. 1) did a clean build 2) deleted the build folder (the one described in README.CMAKE) 3) downloaded the latest tarball of source and compiled in a different folder. But all of them yield the same result. I have not tried building on a different machine. I'll do it now. -- Anil On Sun, Mar 15, 2015 at 6:56 PM, Pascal Quantin pascal.quan...@gmail.com wrote: 2015-03-15 14:16 GMT+01:00 Anil anilkumar...@gmail.com: Hi -- I have been seeing this problem with the wireshark since 12 Mar 2015. I get the below error anil@anilpc:~/ws_srcpkg/build$ ./run/wireshark-gtk 18:26:50 Err Field 'Src Vm Name' (nstrace.src_vm) is an integral value (FT_INT64) but is being displayed as BASE_NONE Trace/breakpoint trap I can see that enum (enum ftenum) values are different in different files (frames) as seen from GDB. (gdb) bt #0 0x76593c13 in g_logv () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 #1 0x76593d72 in g_log () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 #2 0x7306df34 in tmp_fld_check_assert (hfinfo=0x7fffe4867698 hf+88, hfinfo@entry=0x22e3b) at /home/anil/ws_srcpkg/wireshark-1.99.3/epan/proto.c:5751 #3 proto_register_field_init (hfinfo=hfinfo@entry=0x7fffe4867698 hf+88, parent=parent@entry=142907) at /home/anil/ws_srcpkg/wireshark-1.99.3/epan/proto.c:5924 #4 0x7306e1c9 in proto_register_field_common (proto=proto@entry=0x8694a0, hfi=hfi@entry=0x7fffe4867698 hf+88, parent=parent@entry=142907) at /home/anil/ws_srcpkg/wireshark-1.99.3/epan/proto.c:5402 #5 0x730751e1 in proto_register_field_array (parent=142907, hf=hf@entry=0x7fffe4867640 hf, num_records=num_records@entry=28) at /home/anil/ws_srcpkg/wireshark-1.99.3/epan/proto.c:5431 #6 0x7fffe4666447 in proto_register_ns () at packet-nstrace.c:496 #7 0x765a96b8 in g_slist_foreach () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 #8 0x730750d2 in proto_init ( register_all_protocols_func=register_all_protocols_func@entry=0x422910 register_all_protocols@plt, register_all_handoffs_func=register_all_handoffs_func@entry=0x41f910 register_all_protocol_handoffs@plt, cb=cb@entry=0x4b3290 splash_update, client_data=client_data@entry =0x9ce360) at /home/anil/ws_srcpkg/wireshark-1.99.3/epan/proto.c:497 #9 0x730550bb in epan_init (register_all_protocols_func=0x422910 register_all_protocols@plt, register_all_handoffs_func=0x41f910 register_all_protocol_handoffs@plt, cb=0x4b3290 splash_update, client_data=client_data@entry=0x9ce360) at /home/anil/ws_srcpkg/wireshark-1.99.3/epan/epan.c:116 #10 0x00423726 in main (argc=1, argv=0x7fffdf58) at /home/anil/ws_srcpkg/wireshark-1.99.3/ui/gtk/main.c:2511 (gdb) p (int) FT_STRINGZ *$1 = 24* (gdb) frame 6 #6 0x7fffe4666447 in proto_register_ns () at packet-nstrace.c:496 496packet-nstrace.c: No such file or directory. (gdb) p (int) FT_STRINGZ *$2 = 18* Hi Anil, it's probably time for you to clean and rebuild as you have some objects that use an old ftenum (the dependency check probably get confused at some point and did not recompile all the files adter the ftypes.h update for FT_(U)INT_(40|48|56) addition). 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:https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org ?subject=unsubscribe -- Graham Bloice Software Developer Trihedral UK Limited ___ Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org Archives:https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
[Wireshark-dev] Buildbot test failures - wslua
The current test failures are in the wslua tests, in the last part of the wslua_step_dissector_test() test, where the two files differ, apparently testing old and new style tcp dissection. It seems the testin.txt file has multiple entries [PDU Size: 64] for the reassembled packets pdu's, e.g. Frame 2, but testout.txt doesn't. I'm not sure what's caused the issue though. -- Graham Bloice ___ 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 8.1 buildbot failing tests
On 12 March 2015 at 15:01, Jeff Morriss jeff.morriss...@gmail.com wrote: On 03/12/15 08:05, Graham Bloice wrote: The error seems to be running tests with a CMake out-of-tree build, I see the same issue locally. From the test output: global_config_path = 'C:\buildbot\wireshark\wireshark-master-32\windows-8. 1-x86\build\cmbuild\run\RelWithDebInfo\epan\wslua\' but the lua files (init.lua etc.) are in C:\buildbot\wireshark\wireshark-master-32\windows-8. 1-x86\build\cmbuild\run\RelWithDebInfo\lua Yes, wslua doesn't work/build well with cmake. (As mentioned recently) I fixed that with autotools (starting with https://code.wireshark.org/ review/3348). The commit message in that change suggests what (I think) needs to be changed to make it work with cmake--of course I left that for someone with the apparently-necessary cmake book to do. :-) On Windows, I think it's the layout that's wrong somewhere. When Wireshark is actually installed, the lua files are in a lua subdirectory of the Wireshark directory, e.g. C:\Program Files\Wireshark\lua. C:\Program Files\Wireshark is the global configuration directory and the lua files are one subdir down. CMake recreates the runtime environment in the appropriate run directory, e.g. ...\run\relWithDebInfo, and that is the global config directory for the build, but the tests (or something else) now expects the lua files in globalconfig\epan\wslua (as reported by the test code). So for me the question is why do the tests (or the CMake built executable) expect the lua files to be in the different place? -- Graham Bloice ___ 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 8.1 buildbot failing tests
On 12 March 2015 at 15:14, Graham Bloice graham.blo...@trihedral.com wrote: On 12 March 2015 at 15:01, Jeff Morriss jeff.morriss...@gmail.com wrote: On 03/12/15 08:05, Graham Bloice wrote: The error seems to be running tests with a CMake out-of-tree build, I see the same issue locally. From the test output: global_config_path = 'C:\buildbot\wireshark\wireshark-master-32\windows-8. 1-x86\build\cmbuild\run\RelWithDebInfo\epan\wslua\' but the lua files (init.lua etc.) are in C:\buildbot\wireshark\wireshark-master-32\windows-8. 1-x86\build\cmbuild\run\RelWithDebInfo\lua Yes, wslua doesn't work/build well with cmake. (As mentioned recently) I fixed that with autotools (starting with https://code.wireshark.org/ review/3348). The commit message in that change suggests what (I think) needs to be changed to make it work with cmake--of course I left that for someone with the apparently-necessary cmake book to do. :-) On Windows, I think it's the layout that's wrong somewhere. When Wireshark is actually installed, the lua files are in a lua subdirectory of the Wireshark directory, e.g. C:\Program Files\Wireshark\lua. C:\Program Files\Wireshark is the global configuration directory and the lua files are one subdir down. CMake recreates the runtime environment in the appropriate run directory, e.g. ...\run\relWithDebInfo, and that is the global config directory for the build, but the tests (or something else) now expects the lua files in globalconfig\epan\wslua (as reported by the test code). So for me the question is why do the tests (or the CMake built executable) expect the lua files to be in the different place? Oops, typed in haste, a Windows install puts the lua files in the main Wireshark directory. This still doesn't answer my question as to why the tests have (for the 8.1. buildbot) the global config dir as: global_config_path= 'C:\buildbot\wireshark\wireshark-master-32\windows-8.1-x86\build\cmbuild\run\RelWithDebInfo\epan\wslua\' -- Graham Bloice ___ 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 8.1 buildbot failing tests
The error seems to be running tests with a CMake out-of-tree build, I see the same issue locally. From the test output: global_config_path = 'C:\buildbot\wireshark\wireshark-master-32\windows-8.1-x86\build\cmbuild\run\RelWithDebInfo\epan\wslua\' but the lua files (init.lua etc.) are in C:\buildbot\wireshark\wireshark-master-32\windows-8.1-x86\build\cmbuild\run\RelWithDebInfo\lua -- Graham Bloice ___ 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] Make CMake reuse Makefile.common?
On 6 March 2015 at 15:17, Peter Wu pe...@lekensteyn.nl wrote: On Tue, Mar 03, 2015 at 05:50:10PM +0100, Alexis La Goutte wrote: On Mon, Mar 2, 2015 at 1:16 PM, Peter Wu pe...@lekensteyn.nl wrote: Hi, Recently there have been two issues due to separate copies between CMake and autofoo (missing ATH dissector, missing field registrations for plugins). The former could occur due to missing duplication from Makefile.common into CMakeLists.txt. The latter happens because the plugins/*/CMakeLists.txt are slightly different than the Makefiles (in terms of variable sets). Hereby I am proposing to convert Makefile.common automatically to CMakeLists.inc.txt, and then include that during the build process to set variables. The inspiration comes from cURL which too supports autoconf, and (as an experimental option) cmake. See this transformation macro[0] and its use[1] for an example. Hi Peter, Need to try... but i known CMake cURL is no perfect... and there is some plan to drop support of CMake ;-) There *was* a plan to drop CMake support if nobody cared, but since then patches have been sent to improve it (also from my side). And also if i remember the target is only have CMake for build system (and remove autofoo...) That would be great, but I would not rush this yet, there are still some cmake issues like https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=10074. (other issues I have found, but for which no bug is filled: the path to xdg-open is fully expanded by cmake). How are the windows binaries currently build? Using nmake I believe? As mentioned elsewhere Windows CMake is getting good now, still some issues to be sorted, but I'm hopeful of getting there by SF15. -- Graham Bloice ___ 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] Make CMake reuse Makefile.common?
On 6 March 2015 at 15:31, Alexis La Goutte alexis.lagou...@gmail.com wrote: On Fri, Mar 6, 2015 at 4:26 PM, Graham Bloice graham.blo...@trihedral.com wrote: On 6 March 2015 at 15:17, Peter Wu pe...@lekensteyn.nl wrote: On Tue, Mar 03, 2015 at 05:50:10PM +0100, Alexis La Goutte wrote: On Mon, Mar 2, 2015 at 1:16 PM, Peter Wu pe...@lekensteyn.nl wrote: Hi, Recently there have been two issues due to separate copies between CMake and autofoo (missing ATH dissector, missing field registrations for plugins). The former could occur due to missing duplication from Makefile.common into CMakeLists.txt. The latter happens because the plugins/*/CMakeLists.txt are slightly different than the Makefiles (in terms of variable sets). Hereby I am proposing to convert Makefile.common automatically to CMakeLists.inc.txt, and then include that during the build process to set variables. The inspiration comes from cURL which too supports autoconf, and (as an experimental option) cmake. See this transformation macro[0] and its use[1] for an example. Hi Peter, Need to try... but i known CMake cURL is no perfect... and there is some plan to drop support of CMake ;-) There *was* a plan to drop CMake support if nobody cared, but since then patches have been sent to improve it (also from my side). the drop of CMake support is for cURL and no Wireshark ;-) And also if i remember the target is only have CMake for build system (and remove autofoo...) That would be great, but I would not rush this yet, there are still some cmake issues like https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=10074. (other issues I have found, but for which no bug is filled: the path to xdg-open is fully expanded by cmake). How are the windows binaries currently build? Using nmake I believe? As mentioned elsewhere Windows CMake is getting good now, still some issues to be sorted, but I'm hopeful of getting there by SF15. Plan a session on SF15 about fixing CMake issue stuff ? ;-) 1 slide : Call Jörg https://code.wireshark.org/review/#/q/owner:%22J%25C3%25B6rg+Mayer%22+status:merged,n,z ! -- Graham Bloice ___ 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] Make CMake reuse Makefile.common?
On 4 March 2015 at 16:44, Jeff Morriss jeff.morriss...@gmail.com wrote: On 03/04/15 04:07, Michal Labedzki wrote: On 03/03/15 11:50, Alexis La Goutte wrote: And also if i remember the target is only have CMake for build system (and remove autofoo...) I hope there will be only CMake in near future (imply remove autotools). As I know cmake aka build systems working for all platforms. What about remove building part of autotools, use cmake for that and use autotools for other tasks? It may work but last I checked it didn't work too well: there's a bunch of stuff that works when running from an autotools build directory that doesn't from a cmake directory. And it doesn't appear many people have been working on that. Maybe that should be enumerated somewhere. I've only built (off Windows) on Ubuntu using CMake and it worked for me. On Windows there are a few bits left to finish off, but I think the nmake usage is coming to an end. -- Graham Bloice ___ 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] Make CMake reuse Makefile.common?
On 4 March 2015 at 19:04, Jeff Morriss jeff.morriss...@gmail.com wrote: On 03/04/15 11:55, Graham Bloice wrote: On 4 March 2015 at 16:44, Jeff Morriss jeff.morriss...@gmail.com mailto:jeff.morriss...@gmail.com wrote: On 03/04/15 04:07, Michal Labedzki wrote: On 03/03/15 11:50, Alexis La Goutte wrote: And also if i remember the target is only have CMake for build system (and remove autofoo...) I hope there will be only CMake in near future (imply remove autotools). As I know cmake aka build systems working for all platforms. What about remove building part of autotools, use cmake for that and use autotools for other tasks? It may work but last I checked it didn't work too well: there's a bunch of stuff that works when running from an autotools build directory that doesn't from a cmake directory. And it doesn't appear many people have been working on that. Maybe that should be enumerated somewhere. I've only built (off Windows) on Ubuntu using CMake and it worked for me. On Windows there are a few bits left to finish off, but I think the nmake usage is coming to an end. It generally works it's just missing features. A bunch are documented in README.cmake but not all. For example I think Evan found that the test suite--at least the Lua portion--don't work in cmake builds; I fixed that in autotools (starting with https://code.wireshark.org/review/3348) but I don't think anyone has touched the cmake part (I gave up even thinking about cmake a while ago). Must force change of Jeff's viewpoint of CMake I'l be sending the vibes over later :-) -- Graham Bloice ___ 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] Make CMake reuse Makefile.common?
On 4 March 2015 at 20:58, Jeff Morriss jeff.morriss...@gmail.com wrote: On 03/04/15 14:10, Graham Bloice wrote: On 4 March 2015 at 19:04, Jeff Morriss jeff.morriss...@gmail.com mailto:jeff.morriss...@gmail.com wrote: On 03/04/15 11:55, Graham Bloice wrote: On 4 March 2015 at 16:44, Jeff Morriss jeff.morriss...@gmail.com mailto:jeff.morriss...@gmail.com mailto:jeff.morriss.ws@gmail.__com mailto:jeff.morriss...@gmail.com wrote: On 03/04/15 04:07, Michal Labedzki wrote: On 03/03/15 11:50, Alexis La Goutte wrote: And also if i remember the target is only have CMake for build system (and remove autofoo...) I hope there will be only CMake in near future (imply remove autotools). As I know cmake aka build systems working for all platforms. What about remove building part of autotools, use cmake for that and use autotools for other tasks? It may work but last I checked it didn't work too well: there's a bunch of stuff that works when running from an autotools build directory that doesn't from a cmake directory. And it doesn't appear many people have been working on that. Maybe that should be enumerated somewhere. I've only built (off Windows) on Ubuntu using CMake and it worked for me. On Windows there are a few bits left to finish off, but I think the nmake usage is coming to an end. It generally works it's just missing features. A bunch are documented in README.cmake but not all. For example I think Evan found that the test suite--at least the Lua portion--don't work in cmake builds; I fixed that in autotools (starting with https://code.wireshark.org/__review/3348 https://code.wireshark.org/review/3348) but I don't think anyone has touched the cmake part (I gave up even thinking about cmake a while ago). Must force change of Jeff's viewpoint of CMake I'l be sending the vibes over later :-) How about a cmake book--oh, and the time and inclination to read it (the docs and answers I found online didn't help me a lot)? Ah, I guess the inclination part may be the real problem now--so maybe the vibes /would/ help. ;-) And what is an easy cross-compilation target to aim for (with Ubuntu as the host OS)? -- Graham Bloice ___ 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] Make CMake reuse Makefile.common?
On 4 March 2015 at 20:58, Jeff Morriss jeff.morriss...@gmail.com wrote: On 03/04/15 14:10, Graham Bloice wrote: On 4 March 2015 at 19:04, Jeff Morriss jeff.morriss...@gmail.com mailto:jeff.morriss...@gmail.com wrote: On 03/04/15 11:55, Graham Bloice wrote: On 4 March 2015 at 16:44, Jeff Morriss jeff.morriss...@gmail.com mailto:jeff.morriss...@gmail.com mailto:jeff.morriss.ws@gmail.__com mailto:jeff.morriss...@gmail.com wrote: On 03/04/15 04:07, Michal Labedzki wrote: On 03/03/15 11:50, Alexis La Goutte wrote: And also if i remember the target is only have CMake for build system (and remove autofoo...) I hope there will be only CMake in near future (imply remove autotools). As I know cmake aka build systems working for all platforms. What about remove building part of autotools, use cmake for that and use autotools for other tasks? It may work but last I checked it didn't work too well: there's a bunch of stuff that works when running from an autotools build directory that doesn't from a cmake directory. And it doesn't appear many people have been working on that. Maybe that should be enumerated somewhere. I've only built (off Windows) on Ubuntu using CMake and it worked for me. On Windows there are a few bits left to finish off, but I think the nmake usage is coming to an end. It generally works it's just missing features. A bunch are documented in README.cmake but not all. For example I think Evan found that the test suite--at least the Lua portion--don't work in cmake builds; I fixed that in autotools (starting with https://code.wireshark.org/__review/3348 https://code.wireshark.org/review/3348) but I don't think anyone has touched the cmake part (I gave up even thinking about cmake a while ago). Must force change of Jeff's viewpoint of CMake I'l be sending the vibes over later :-) How about a cmake book--oh, and the time and inclination to read it (the docs and answers I found online didn't help me a lot)? Ah, I guess the inclination part may be the real problem now--so maybe the vibes /would/ help. ;-) Docs seem to be a perennial complaint about CMake. There is a dead-tree book (http://www.kitware.com/products/books/CMakeBook.html) that is used to support the project. -- Graham Bloice Software Developer Trihedral UK Limited ___ 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] Make CMake reuse Makefile.common?
On 4 March 2015 at 22:09, Jeff Morriss jeff.morriss...@gmail.com wrote: On 03/04/15 16:24, Graham Bloice wrote: And what is an easy cross-compilation target to aim for (with Ubuntu as the host OS)? I'm not sure there is an easy cross-compilation target. I just know people sometimes come here asking questions or reporting problems. This page http://www.cmake.org/Wiki/CMake_Cross_Compiling seems to imply it's a matter of creating a CMAKE_TOOLCHAIN_FILE and passing it into the CMake command. Until we actually determine what cross-compilation is required, it'll just have to be a wishlist item. -- Graham Bloice ___ 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] Undissected reserved fields
On 27 February 2015 at 18:28, Jeff Morriss jeff.morriss...@gmail.com wrote: On 02/27/15 11:40, Dario Lombardo wrote: I'm playing with the undissected bytes functionality of wireshark, patching some dissectors that clearly lack some fields. But now I've found some of them that fall in a grey area and I'd lilke to discuss with other devels the best way to go on. I've found that many dissectors lack decoding of reserved/unused fields. An example of them is the ISL dissector and an example file is provabis.pcap (found it in the wiki). This field is reserved but is part of the specifications of the protocol (have a look here http://www.cisco.com/c/en/us/support/docs/lan-switching/ 8021q/17056-741-4.html). It is clearly stated that the field is 0x0 in ethernet, but can have values in token ring or FDDI. So the general question is: is it correct to leave reserved/unused fields udecoded? Or would it better to decode them as described in the actual specifications (reserved of unused)? My opinion (which I've voiced on this list many times over the past ~10 years) is that such fields SHOULD be dissected. Even better they should have an Expert Info if they are supposed to be 0 and aren't (Guy had suggested on a bug or somewhere that we should have an API with a name that includes mbz--for Must Be Zero--which would add the Expert Info automatically). Why do I have this opinion? Because most of the time the specs say must be set to 0 on transmission and ignored on receipt but I have seen *numerous* cases of senders that *don't* set the field to 0 talking to receivers that *don't* ignore it. Of course the result is an interop problem. (As a result of these I've committed changes to several dissectors to dissect spare fields; in some cases I think Expert Infos are also raised.) How do we handle the case where a protocol has many reserved fields, do they each need an hf and a name? -- Graham Bloice ___ 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] Google deprecating OpenID 2.0
On 24 February 2015 at 17:41, Gerald Combs ger...@wireshark.org wrote: On 2/24/15 1:34 AM, Graham Bloice wrote: On 23 February 2015 at 23:51, Gerald Combs ger...@wireshark.org mailto:ger...@wireshark.org wrote: On 2/22/15 6:01 AM, Graham Bloice wrote: See https://developers.google.com/accounts/docs/OpenID Does this affect our use of Gerrit if we use a Google account to authenticate? Yes. In case anyone missed the other responses you need to stop authenticating using your Google account and switch to another account before April 20. I've added a notice to the login page. In the near term we need to find a list of stable OpenID 2.0 providers that we can recommend on the login page. In the long term we need to find a more stable way of authenticating to Gerrit. And is there any possibility of Gerrit supporting Open ID 2.0 Connect which is what Google+ supports and seems to be the future for Open ID? The Gerrit issues tracker is very confusing on this. I'm not sure. The closest thing I've seen so far was a change to add GitHub OAuth support but it was abandoned: https://gerrit-review.googlesource.com/#/c/57570/ The following discussions provide a bit more background: https://groups.google.com/forum/#!topic/repo-discuss/Hjn-6BV3KBU https://groups.google.com/forum/#!topic/repo-discuss/nrtxry9SNLg From those threads it seems that the GitHub OAuth 2.0 patch was abandoned as it wasn't pluggable, and that they are going to come back with a pluggable version. It also seems that they will have to support OAuth 2.0 in general (which Google+ can be configured to work as), as that's where everyone is heading according to the list in one thread. -- Graham Bloice ___ 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] Google deprecating OpenID 2.0
See https://developers.google.com/accounts/docs/OpenID Does this affect our use of Gerrit if we use a Google account to authenticate? -- Graham Bloice ___ 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] Problem with connecting to Gerrit-Server by use of SSH-Connection
On 13 February 2015 at 10:54, FIXED-TERM Scholz Tobias (DC-IA/EAM6) fixed-term.tobias.sch...@boschrexroth.de wrote: Hello, I’ve improved an existing Wireshark dissector. The code is ready for an upload to the Wireshark Gerrit-Server. Due to that I used those two guides ( *http://wiki.wireshark.org/Development/SubmittingPatches/GitForWindows* http://wiki.wireshark.org/Development/SubmittingPatches/GitForWindows and *https://code.wireshark.org/review/Documentation/user-upload.html* https://code.wireshark.org/review/Documentation/user-upload.html ) to create a SSH-Connection to upload my changes. I have already installed the tools successfully on my computer, as in the “GitForWindows” guide described. Furthermore my Gerrit account already has a linked SSH public key with my PC. The Last step in the “GitForWindows” guide is to check the connection with the server with “ssh –p 29418 *yourgerritusern...@code.wireshark.org* yourgerritusern...@code.wireshark.org”. But right at this point a Problem appears. Right now I am not able to create an SSH-Connection, because it is not allowed. Therefore I’ve searched for another solution to create a different connection to the Gerrit-Server, but without any success. My Question therefore is: Is it possible to upload my changes to the Gerrit-Server without a SSH-Connection (HTTP / HTTPS) or is this connection type coercive necessary? I'm not sure if HTTPS can be used, but you can add a -v argument onto the ssh command to get verbose output that might let you see where things have gone wrong. Further -v arguments generates even more debug output. -- Graham Bloice ___ 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] Fatal Error U1077: cl.exe return code 0x2 compiling usb.c on Windows
On 8 February 2015 at 15:41, Richard Sharpe realrichardsha...@gmail.com wrote: On Sun, Feb 8, 2015 at 7:19 AM, Richard Sharpe realrichardsha...@gmail.com wrote: According to this: http://stackoverflow.com/questions/23831911/nmake-fatal-error-u1077-cd-return-code-0x2-cl-exe The problem is empty arrays. Further examination shows that usb.c was not the problem, as usb.obj exists. How do I get it to tell me what file it failed on? Should be in the output, but might be back aways a fair bit. Redirect to a txt file for leisurely examination: nmake -f Makefile.nmake out.txt 21 -- Graham Bloice ___ 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 initializing git review
On 5 February 2015 at 18:02, Ed Beroset bero...@mindspring.com wrote: Graham Bloice wrote: On 5 February 2015 at 17:48, Ed Beroset bero...@mindspring.com wrote: Problems encountered installing commit-msg hook The following command failed with exit code 104 GET https://bero...@code.wireshark.org/tools/hooks/commit-msg; --- [...] I don't really know how to go about troubleshooting this since I haven't ever used it and don't know what it's supposed to do. If it's relevant, I'm behind a corporate firewall that forces me to use https: instead of ssh: Any clues? Is the URL correct? I have no idea. What do you get with those URL's in a browser, or with wget? Shouldn't it be https://bero...@code.wireshark.org/wireshark/tools/hooks/commit-msg What does git remote -v show? origin https://bero...@code.wireshark.org/review/wireshark (fetch) origin https://bero...@code.wireshark.org/review/wireshark (push) Ed git review as a verbose option, `-v`, you could try that to see if there's more info. git review isn't compulsory, it just makes life easier. -- Graham Bloice ___ 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 initializing git review
On 5 February 2015 at 17:48, Ed Beroset bero...@mindspring.com wrote:
I've followed the steps here:
https://www.wireshark.org/docs/wsdg_html_chunked/ChSrcObtain.html
And I've successfully gotten to the step where it says to run git review
-s but then it fails. The full error dump is:
Traceback (most recent call last):
File /usr/bin/git-review, line 10, in module
sys.exit(main())
File /usr/lib/python2.7/site-packages/git_review/cmd.py, line 1202, in
main
set_hooks_commit_msg(remote, hook_file)
File /usr/lib/python2.7/site-packages/git_review/cmd.py, line 264, in
set_hooks_commit_msg
res = run_http_exc(CannotInstallHook, hook_url, stream=True)
File /usr/lib/python2.7/site-packages/git_review/cmd.py, line 175, in
run_http_exc
raise klazz(255, str(err), ('GET', url), env)
git_review.cmd.CannotInstallHook: Problems encountered installing
commit-msg hook
The following command failed with exit code 255
GET https://bero...@code.wireshark.org/tools/hooks/commit-msg;
---
Problems encountered installing commit-msg hook
The following command failed with exit code 104
GET https://bero...@code.wireshark.org/tools/hooks/commit-msg;
---
!DOCTYPE HTML PUBLIC -//IETF//DTD HTML 2.0//EN
htmlhead
title404 Not Found/title
/headbody
h1Not Found/h1
pThe requested URL /tools/hooks/commit-msg was not found on this
server./p
/body/html
---
---
I don't really know how to go about troubleshooting this since I haven't
ever used it and don't know what it's supposed to do. If it's relevant,
I'm behind a corporate firewall that forces me to use https: instead of
ssh: Any clues?
Ed
Is the URL correct? Shouldn't it be
https://bero...@code.wireshark.org/wireshark/tools/hooks/commit-msg
What does git remote -v show?
--
Graham Bloice
___
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 wireshark on Win7 gives me the error about win32.mak not found
On 31 January 2015 at 20:50, Richard Sharpe realrichardsha...@gmail.com wrote: On Sat, Jan 31, 2015 at 12:18 PM, Graham Bloice graham.blo...@trihedral.com wrote: On 31 January 2015 at 19:27, Richard Sharpe realrichardsha...@gmail.com wrote: Hi folks, I am following the steps at this website: https://www.wireshark.org/docs/wsdg_html_chunked/ChSetupWin32.html and I get this error: c:\Users\blah-blah\Wiresharknmake -f Makefile.nmake verify_tools Microsoft (R) Program Maintenance Utility Version 12.00.21005.1 Copyright (C) Microsoft Corporation. All rights reserved. Makefile.nmake(8) : fatal error U1052: file 'win32.mak' not found Stop. These appear to be in the environment: CYGWIN=nodosfilewarning QT5_BASE_DIR=C:\Qt\5.4\msvc2013_64_opengl VisualStudioVersion=12.0 WIRESHARK_BASE_DIR=c:\Users\rjsharpe\Wireshark WIRESHARK_TARGET_PLATFORM=win64 WIRESHARK_VERSION_EXTRA=-RJS What else do I need to do? See this thread (https://www.wireshark.org/lists/wireshark-dev/201501/msg00026.html) about windows build instructions. MS has dropped the file from the SDK for 8.x, so you have to copy the file from a 7.x SDK which should have been installed along with VS2013. I seem to have not completed the task of updating the build instructions. OK, but copy it to where? To the 8.x SDK? As I mentioned in my email, to the relevant place in the 8.x SDK: C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\include -- Graham Bloice ___ 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] Windows build problems now seem solved ... but a small update to the build doc might help
On 31 January 2015 at 22:31, Richard Sharpe realrichardsha...@gmail.com wrote: Hi folks, It seems that my real problem was that I had not paid careful attention to this statement in the guide: From the Start Menu (or Start Screen), navigate to the Visual Studio 2013 → Visual Studio Tools directory and choose the Command Prompt appropriate for the build you wish to make, e.g. VS2013 x86 Native Tools Command Prompt for a 32 bit version. There are several command prompts with VS2013, and the one I wanted was the VS2013 x64 Native Tools Command Prompt. Perhaps that statement above could be modified to add another entry after the eg and in clude:, VS2013 x64 Native Tools Command Prompt for an x64 version. I thought it was somewhat obvious, but feel free to amend. -- Graham Bloice ___ 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] Now problems packaging ...
On 31 January 2015 at 22:55, Richard Sharpe realrichardsha...@gmail.com wrote: On Sat, Jan 31, 2015 at 2:39 PM, Richard Sharpe realrichardsha...@gmail.com wrote: Hi folks, So, my build completed OK. However, when I attempted the packaging step I got: -- Processing config: c:\Program Files (x86)\NSIS\nsisconf.nsh Processing script file: wireshark.nsi (ACP) File: c:\Users\rjsharpe\Wireshark\Wireshark-win64-libs\vcredist_x64.exe - no files found. Usage: File [/nonfatal] [/a] ([/r] [/x filespec [...]] filespec [...] | /oname=outfile one_file_only) Error in script wireshark.nsi on line 349 -- aborting creation process NMAKE : fatal error U1077: '\Program Files (x86)\NSIS\makensis.exe' : return c ode '0x1' Stop. NMAKE : fatal error U1077: 'C:\Program Files (x86)\Microsoft Visual Studio 12.0 \VC\BIN\amd64\nmake.exe' : return code '0x2' Stop. Any hints here? A quick application of the vcredist_x64 tonic seems to have fixed this problem. The doc needs another update. Which VS edition are you using? -- Graham Bloice ___ 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] Now problems packaging ...
On 1 February 2015 at 21:56, Richard Sharpe realrichardsha...@gmail.com wrote: On Sun, Feb 1, 2015 at 12:12 PM, Graham Bloice graham.blo...@trihedral.com wrote: On 1 February 2015 at 14:38, Richard Sharpe realrichardsha...@gmail.com wrote: On Sun, Feb 1, 2015 at 2:37 AM, Graham Bloice graham.blo...@trihedral.com wrote: On 31 January 2015 at 22:55, Richard Sharpe realrichardsha...@gmail.com wrote: On Sat, Jan 31, 2015 at 2:39 PM, Richard Sharpe realrichardsha...@gmail.com wrote: Hi folks, So, my build completed OK. However, when I attempted the packaging step I got: -- Processing config: c:\Program Files (x86)\NSIS\nsisconf.nsh Processing script file: wireshark.nsi (ACP) File: c:\Users\rjsharpe\Wireshark\Wireshark-win64-libs\vcredist_x64.exe - no files found. Usage: File [/nonfatal] [/a] ([/r] [/x filespec [...]] filespec [...] | /oname=outfile one_file_only) Error in script wireshark.nsi on line 349 -- aborting creation process NMAKE : fatal error U1077: '\Program Files (x86)\NSIS\makensis.exe' : return c ode '0x1' Stop. NMAKE : fatal error U1077: 'C:\Program Files (x86)\Microsoft Visual Studio 12.0 \VC\BIN\amd64\nmake.exe' : return code '0x2' Stop. Any hints here? A quick application of the vcredist_x64 tonic seems to have fixed this problem. The doc needs another update. Which VS edition are you using? VS2013 ... Odd, is that VS2013 Express, VS2013 Community Edition or some other version? I believe all versions except the Express, which has now been withdrawn by MS in favour of the Community edition, include the vcredist files so no download is needed. When I start up Visual Studio 2013 it calls itself Professional 2013 and the About Dialog box says Microsoft Visual Studio Professional 2013. That version should have the vcredist files in the above mentioned location. I've never needed to manually download the files when using that version. There's something in the build system that should manage that but I can't quite see it yet. What flavour of VS2013, and what do you have in C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\redist\1033? There is already a note in the docs (Sect 4.6.1) about other VS variants that discusses the vcredist files for VS2010 Express, but as there is no conceivable reason I can think of to not use VS2013 CE, then it's all rather historical. -- Graham Bloice ___ 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] Now problems packaging ...
On 1 February 2015 at 22:08, Richard Sharpe realrichardsha...@gmail.com wrote: On Sun, Feb 1, 2015 at 2:02 PM, Graham Bloice graham.blo...@trihedral.com wrote: Odd, is that VS2013 Express, VS2013 Community Edition or some other version? I believe all versions except the Express, which has now been withdrawn by MS in favour of the Community edition, include the vcredist files so no download is needed. When I start up Visual Studio 2013 it calls itself Professional 2013 and the About Dialog box says Microsoft Visual Studio Professional 2013. That version should have the vcredist files in the above mentioned location. I've never needed to manually download the files when using that version. There's something in the build system that should manage that but I can't quite see it yet. Actually, I just searched for it and it is indeed in C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\redist\1033. For some reason it was not being found. I think that's a bug in the build for x64. For x86 builds with VS versions other than Express the build packages the mcvrxxx.dll directly to avoid having to run the redist installer for portable packages. For x64, as no portable packages are built, it looks for the redist installer. The build system should be able to locate the redist installers in the same manner as it does for the msvcxxx.dll and not require a separate download except for the Express editions. Some changes need in config.nmake to define the VCREDIST_DIR. What flavour of VS2013, and what do you have in C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\redist\1033? There is already a note in the docs (Sect 4.6.1) about other VS variants that discusses the vcredist files for VS2010 Express, but as there is no conceivable reason I can think of to not use VS2013 CE, then it's all rather historical. -- Graham Bloice ___ 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] Now problems packaging ...
On 1 February 2015 at 14:38, Richard Sharpe realrichardsha...@gmail.com wrote: On Sun, Feb 1, 2015 at 2:37 AM, Graham Bloice graham.blo...@trihedral.com wrote: On 31 January 2015 at 22:55, Richard Sharpe realrichardsha...@gmail.com wrote: On Sat, Jan 31, 2015 at 2:39 PM, Richard Sharpe realrichardsha...@gmail.com wrote: Hi folks, So, my build completed OK. However, when I attempted the packaging step I got: -- Processing config: c:\Program Files (x86)\NSIS\nsisconf.nsh Processing script file: wireshark.nsi (ACP) File: c:\Users\rjsharpe\Wireshark\Wireshark-win64-libs\vcredist_x64.exe - no files found. Usage: File [/nonfatal] [/a] ([/r] [/x filespec [...]] filespec [...] | /oname=outfile one_file_only) Error in script wireshark.nsi on line 349 -- aborting creation process NMAKE : fatal error U1077: '\Program Files (x86)\NSIS\makensis.exe' : return c ode '0x1' Stop. NMAKE : fatal error U1077: 'C:\Program Files (x86)\Microsoft Visual Studio 12.0 \VC\BIN\amd64\nmake.exe' : return code '0x2' Stop. Any hints here? A quick application of the vcredist_x64 tonic seems to have fixed this problem. The doc needs another update. Which VS edition are you using? VS2013 ... Odd, is that VS2013 Express, VS2013 Community Edition or some other version? I believe all versions except the Express, which has now been withdrawn by MS in favour of the Community edition, include the vcredist files so no download is needed. What flavour of VS2013, and what do you have in C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\redist\1033? There is already a note in the docs (Sect 4.6.1) about other VS variants that discusses the vcredist files for VS2010 Express, but as there is no conceivable reason I can think of to not use VS2013 CE, then it's all rather historical. -- Graham Bloice ___ 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 wireshark on Win7 gives me the error about win32.mak not found
On 31 January 2015 at 19:27, Richard Sharpe realrichardsha...@gmail.com wrote: Hi folks, I am following the steps at this website: https://www.wireshark.org/docs/wsdg_html_chunked/ChSetupWin32.html and I get this error: c:\Users\blah-blah\Wiresharknmake -f Makefile.nmake verify_tools Microsoft (R) Program Maintenance Utility Version 12.00.21005.1 Copyright (C) Microsoft Corporation. All rights reserved. Makefile.nmake(8) : fatal error U1052: file 'win32.mak' not found Stop. These appear to be in the environment: CYGWIN=nodosfilewarning QT5_BASE_DIR=C:\Qt\5.4\msvc2013_64_opengl VisualStudioVersion=12.0 WIRESHARK_BASE_DIR=c:\Users\rjsharpe\Wireshark WIRESHARK_TARGET_PLATFORM=win64 WIRESHARK_VERSION_EXTRA=-RJS What else do I need to do? See this thread ( https://www.wireshark.org/lists/wireshark-dev/201501/msg00026.html) about windows build instructions. MS has dropped the file from the SDK for 8.x, so you have to copy the file from a 7.x SDK which should have been installed along with VS2013. I seem to have not completed the task of updating the build instructions. -- Graham Bloice ___ 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] Bluetooth and Miscellaneous menus
On 28 January 2015 at 10:59, Michal Labedzki michal.labed...@tieto.com wrote: In menu entries meaning: yes (cross-platform), it based on capture file. So if you load Bluetooth logs then new dialogues will works for you on Win or Mac. Other meaning: LIve capturing is supported only on Linux, partially Windows (via USB). [support for Win/Mac is hard while I do not have them at all, but I sometimes looking on that] Great. This is good time to ask about platform-dependant options... what if some functionality can be done only on Linux? Show only on Linux, hide on other? (disable?) Or maybe Wireshark does not like stuff like that at all? I think AirPCap is Windows only, I'm not sure if it disables or disappears on other platforms. At least replicating what it does is likely to be a good start. -- Graham Bloice ___ 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] Bluetooth and Miscellaneous menus
Is the Bluetooth support cross-platform, or only on certain platforms? On 28 January 2015 at 09:53, Michal Orynicz michal.oryn...@tieto.com wrote: Hi, I think that's a good idea. It would be nice to make it for GTK too, but QT should be enough. On 28 January 2015 at 09:05, Michal Labedzki michal.labed...@tieto.com wrote: Hello, I want to add new menu in Wireshark for Bluetooth (in February). It will be menu on the right of Telephony in main menu. It will be named Bluetooth. For now I have prepared only one entry for this menu, but I have ideas for another 3 new windows (3 summary dialogs and 1 graph), so I prefer to add Bluetooth menu now, then I will add new entries/dialogues next month(s). Of course there are ideas for another features, but those 4 will be done soon. What do you think? I think only about Qt UI, should I also do that for GTK? If so... there is another question: what about create shortcut to other... menu entries? For example: In file menu there is Export Objects - ... so some of ... can be put also in Bluetooth menu. Or there is RTP Player in telephony, so it also works for Bluetooth (in case that is not related to telephony at all so Bluetooth user may do not know about this functionality). Also I think about Miscellaneous menu for everything that is not Telephony, Bluetooth or Statistics. I have idea to implement ADB (Android Debug Bridge) Framebuffer Player. It will play or show frame of framebuffer found in logs. ADB is currently supported over USB and TCP layer. This is the feature for future (but not so far; near; this year?) but let discuss it now may be good idea. -- Pozdrawiam / Best regards - Michał Łabędzki, Software Engineer Tieto Corporation Product Development Services http://www.tieto.com / http://www.tieto.pl --- ASCII: Michal Labedzki location: Swobodna 1 Street, 50-088 Wrocław, Poland room: 5.01 (desk next to 5.08) --- Please note: The information contained in this message may be legally privileged and confidential and protected from disclosure. If the reader of this message is not the intended recipient, you are hereby notified that any unauthorised use, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by replying to the message and deleting it from your computer. Thank You. --- Please consider the environment before printing this e-mail. --- Tieto Poland spółka z ograniczoną odpowiedzialnością z siedzibą w Szczecinie, ul. Malczewskiego 26. Zarejestrowana w Sądzie Rejonowym Szczecin-Centrum w Szczecinie, XIII Wydział Gospodarczy Krajowego Rejestru Sądowego pod numerem 124858. NIP: 8542085557. REGON: 812023656. Kapitał zakładowy: 4 271500 PLN ___ 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 -- Pozdrawiam / Best regards Michał Orynicz, Software Engineer Tieto Corporation Product Development Services http://www.tieto.com / http://www.tieto.pl --- ASCII: Michal Orynicz location: Swobodna 1 Street, 50-088 Wrocław, Poland room: 5.01 (desk next to 5.08) --- Please note: The information contained in this message may be legally privileged and confidential and protected from disclosure. If the reader of this message is not the intended recipient, you are hereby notified that any unauthorised use, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by replying to the message and deleting it from your computer. Thank You. --- Please consider the environment before printing this e-mail. --- Tieto Poland spółka z ograniczoną odpowiedzialnością z siedzibą w Szczecinie, ul. Malczewskiego 26. Zarejestrowana w Sądzie Rejonowym Szczecin-Centrum w Szczecinie, XIII Wydział Gospodarczy Krajowego Rejestru Sądowego pod numerem 124858. NIP: 8542085557. REGON: 812023656. Kapitał zakładowy: 4 271500 PLN ___ 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 -- Graham Bloice ___ Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https
Re: [Wireshark-dev] Retrieve data from lower layer dissector
On 22 January 2015 at 11:45, yannick omnes yom...@aviwest.com wrote: Hi list, i'm working on a plugin to dissect a private protocol that use link aggregation. I have to produce stats for each link used. The problem is that the protocol doesn't provide any information about which link were used to send one packet. So I have to work with the source ip/port. Is there a way to retrieve those values from the UDP dissector ? Have a look at the packet_info struct in epan/packet_info.h which is passed into every dissector. The struct holds various source and destination addresses. -- Graham Bloice ___ 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] Patch being stuck
On 8 January 2015 at 10:38, Dario Lombardo dario.lombardo...@gmail.com wrote: Hi list I pushed a patch a couple of days ago https://code.wireshark.org/review/#/c/6350/ I think it's getting stuck for some reason (not even the petri dish buildbot has processed it). Other patches submitted later (eg. https://code.wireshark.org/review/6394 or https://code.wireshark.org/review/6367) have been or are being processed. Is there any reason for that? I'm not pushing anyone... just wondering if for some reason it is blocked. No blockage reason, just no-one on the core team has gotten around to having a look at it yet. Submission to the Petri-Dish isn't (yet) automatic, it requires a manual flag (from a core team member). -- Graham Bloice ___ 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] Packaging failure on Win7 with Qt 5.2.1 in top-of-trunk
On 8 January 2015 at 14:12, Anders Broman anders.bro...@ericsson.com
wrote:
:
File: Wireshark.exe 7732736 bytes
!include: qt-dll-manifest.nsh
File: Qt5Core.dll 4824064 bytes
File: Qt5Gui.dll 3819008 bytes
File: Qt5Widgets.dll 5273600 bytes
File: Qt5PrintSupport.dll 280064 bytes
File: Descending to: ..\..\wireshark-qt-release\platforms\
File: qwindows.dll 1071104 bytes
File: Returning to: ..\..\wireshark-qt-release
!include: closed: qt-dll-manifest.nsh
File: ..\..\wireshark-qt-release\*.qm - no files found.
Usage: File [/nonfatal] [/a] ([/r] [/x filespec [...]] filespec [...] |
/oname=outfile one_file_only)
Error in script wireshark.nsi on line 874 -- aborting creation process
NMAKE : fatal error U1077: 'C:\Program Files (x86)\NSIS\makensis.exe' :
return
code '0x1'
Stop.
NMAKE : fatal error U1077: 'C:\Program Files (x86)\Microsoft Visual
Studio 11.0
\VC\BIN\nmake.exe' : return code '0x2'
Stop.
It seems like windeployqt-to-nsis.ps1 ought to copy the *.qm files from
(in my case) C:\Qt\Qt5.2.1\5.2.1\msvc2012_64\translations
I’m not sure how to do that in PS so I can’t try if it works…
I think the error is a bit different from what you describe.
windeployqt-to-nsis.ps1 creates the nsis include file
(qt-dll-manifest.nsh) for the qt dll components to be bundled into the
installer. For qt 5.3, the qt tool windeployqt is used, for all other
versions a manual write is done. qt-dll-manifest.nsh does not list any
*.qm files on qt 5.3.2, even though when called to copy the qt components
into wireshark-qt-release it does copy some *.qm files.
I think the issue is maybe that wireshark.nsis always expects some *.qm
files and they just aren't there for qt 5.3. Check the history of
wireshark.nsis to find when the line File ${QT_DIR}\*.qm went in.
--
Graham Bloice
___
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] CMake status
On 5 January 2015 at 23:54, Guy Harris g...@alum.mit.edu wrote: On Jan 5, 2015, at 3:11 PM, Graham Bloice graham.blo...@trihedral.com wrote: FWIW my current Windows CMake list of tasks to do (in no particular order): • Add zlib to build. What remains to be done there? The buildbot Win32 and Win64 builds both appear to be picking up zlib. Or do you mean build zlib as part of the build process? Yes build zlib as part of the build process. Currently CMake will pick up an already compiled zlib (from nmake), but due to VC runtime compatibility issues (which hopefully may be going away) we need to build zlib with the same tooolchain as the rest of the build. • Fix compile warnings. Are there compile warnings we're getting from the CMake build that we're not getting from the nmake build? Yes, See the end of the last successful buildbot Cmake build (it appears to be broken again) http://buildbot.wireshark.org/trunk/builders/Windows%207%20x64/builds/11848/steps/shell_2/logs/stdio One warning about dup messages in the Italian translation and two warnings about dup definitions when compiling packet-kerberos. These may be artefacts of the CMake build rather than actual warnings to be fixed in code. • Fix CMake warnings. • Fix WinPcap version number for compile. That information isn't available from WinPcap itself. But it's not available from libpcap itself, either, and we don't report it with libpcap; should we just stop reporting it with WinPcap as well? (The version of *pcap with which we're *running* is available with newer versions of libpcap and WinPcap, because I added pcap_lib_version() to libpcap a while ago.) The nmake build uses the (hard-coded) value from config.nmake and passes it in as a compiler definition. It seems that it's also used by NSIS installer. Hard-coding isn't great but I'm not sure what we can do here. -- Graham Bloice ___ 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] CMake status
On 6 January 2015 at 11:26, Graham Bloice graham.blo...@trihedral.com wrote: On 5 January 2015 at 23:54, Guy Harris g...@alum.mit.edu wrote: On Jan 5, 2015, at 3:11 PM, Graham Bloice graham.blo...@trihedral.com wrote: FWIW my current Windows CMake list of tasks to do (in no particular order): • Add zlib to build. What remains to be done there? The buildbot Win32 and Win64 builds both appear to be picking up zlib. Or do you mean build zlib as part of the build process? Yes build zlib as part of the build process. Currently CMake will pick up an already compiled zlib (from nmake), but due to VC runtime compatibility issues (which hopefully may be going away) we need to build zlib with the same tooolchain as the rest of the build. • Fix compile warnings. Are there compile warnings we're getting from the CMake build that we're not getting from the nmake build? Yes, See the end of the last successful buildbot Cmake build (it appears to be broken again) http://buildbot.wireshark.org/trunk/builders/Windows%207%20x64/builds/11848/steps/shell_2/logs/stdio One warning about dup messages in the Italian translation and two warnings about dup definitions when compiling packet-kerberos. These may be artefacts of the CMake build rather than actual warnings to be fixed in code. The x64 Cmake build also picked up another one that is likely to be genuine: C:/buildbot/wireshark/wireshark-master-64/win7x64/build/cmbuild/epan/uat_load.c(1351): warning C4267: '+=' : conversion from 'size_t' to 'guint', possible loss of data • Fix CMake warnings. • Fix WinPcap version number for compile. That information isn't available from WinPcap itself. But it's not available from libpcap itself, either, and we don't report it with libpcap; should we just stop reporting it with WinPcap as well? (The version of *pcap with which we're *running* is available with newer versions of libpcap and WinPcap, because I added pcap_lib_version() to libpcap a while ago.) The nmake build uses the (hard-coded) value from config.nmake and passes it in as a compiler definition. It seems that it's also used by NSIS installer. Hard-coding isn't great but I'm not sure what we can do here. -- Graham Bloice -- Graham Bloice ___ 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] Add guard for out-of-tree builds
With the issue of out-of-tree builds picking up the -in-tree copy of config.h due to the use of #include config.h, I wondered if we should put a guard in config.h such that if it is used by an out-of-tree build an immediate warning is issued, e.g. #ifndef IN_TREE_BUILD #error Using __FILE__ in an out-of-tree build #endif And ensuring that in-tree builds define IN_TREE_BUILD. Is there any value in this, are there other files that should also be guarded and is this possible with autconf\automake? -- Graham Bloice ___ 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] Update Windows Build Instructions
On 4 January 2015 at 21:05, Stephen Fisher sfis...@sdf.org wrote: On Sun, Jan 04, 2015 at 10:08:53AM +, Graham Bloice wrote: Maybe your Win7 SDK came from an earlier install of the Platform SDK? My Win8 32-bit machine at home is a fresh install, so VC 2013 CE is the only VC I've ever installed. The Win7 64-bit install at work install may have had something left over from an older VC install hough. So the Win 8 machine has Win32.Mak in the SDK\7.1A\include dir? If so, it would seem that CE does install the older SDK. I'll try to confirm this later. However, if I ever (or someone else assists) get the Windows CMake build fully operational, all this will go away as we can drop the nmake support. CMake on Windows would still use the Microsot compiler tools, just without the nmake part? CMake can still generate nmake files if you wish, but IMHO the normal route would be to generate VS solution files and then build from the command line with msbuild, or fire up the IDE and build from there. -- Graham Bloice ___ 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] Update Windows Build Instructions
On 5 January 2015 at 08:26, Graham Bloice graham.blo...@trihedral.com wrote: On 4 January 2015 at 21:05, Stephen Fisher sfis...@sdf.org wrote: On Sun, Jan 04, 2015 at 10:08:53AM +, Graham Bloice wrote: Maybe your Win7 SDK came from an earlier install of the Platform SDK? My Win8 32-bit machine at home is a fresh install, so VC 2013 CE is the only VC I've ever installed. The Win7 64-bit install at work install may have had something left over from an older VC install hough. So the Win 8 machine has Win32.Mak in the SDK\7.1A\include dir? If so, it would seem that CE does install the older SDK. I'll try to confirm this later. I can confirm that it does. My preferred solution is to copy it into the C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\include directory, I'll try to update the guide this evening. -- Graham Bloice ___ 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] Update Windows Build Instructions
On 5 January 2015 at 17:03, Stephen Fisher sfis...@sdf.org wrote: On Mon, Jan 05, 2015 at 08:26:23AM +, Graham Bloice wrote: CMake can still generate nmake files if you wish, but IMHO the normal route would be to generate VS solution files and then build from the command line with msbuild, or fire up the IDE and build from there. I've always liked the idea of using native build environments on each platform, such as the IDE in VC for Windows. I assume we use nmake files now so we can include makefile.common easily. Is there a straightforward way to (perhaps through a script) build solution files for VC and keep them up-to-date from Makefile.common (or similar file)? Yes, use CMake :-) There are other cross-platform build solutions such as SCons, but it's just as bad as CMake (or maybe worse, I haven't tried anything other than a toy project). Adding a dissector to CMake is as simple as it is for nmake with the bonus that it works for both Windows and Linux (and wherever else CMake is used). Doing anything else with the CMake build system requires a lot of head scratching as getting the required output from the arcane language of CMake files can be a battle. I guess nmake was used in the past as a) it's nearly make, and b) the Visual Studio solution files at the time were horrible undocumented blobs that could only be read by the IDE. Nowadays they're somewhat documented bloated XML blobs that can be built using msbuild (which is quite nice to use). msbuild will also use multiple threads to build so is can be much quicker. The other big advantage of VS solution files is that it should make it easier for folks to use the IDE debugger. I would fire up a CMake build (hint, README.cmake) and try opening the solution in the VS IDE before getting too excited. The IDE still struggles a lot when given lots of projects and files, although when it gets going it's OK for editing. Note that adding source files or making build changes in the IDE will only be temporary as CMake will overwrite them. i.e. CMakeLists.txt (and friends) should be modified for permanent changes. -- Graham Bloice ___ 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] Update Windows Build Instructions
On 5 January 2015 at 23:20, Stephen Fisher sfis...@sdf.org wrote: On Mon, Jan 05, 2015 at 03:34:16PM -0500, Ed Beroset wrote: Having been around this particular block a couple of times, yes, CMake at times is a battle, but it's also better than the alternative of producing (and maintaining) multiple mutually incompatible and inevitably arbitrarily different build systems in parallel. The beauty of autoconf/automake on Unix is that it spits out standard MakefileS so that normal users don't have to install a special program just to build the software. I haven't tried Wireshark with CMake yet, but doesn't every user have to install it to build the software? Or can cmake's output be included in source distributions so only developers need it? The devastating failure of autoconf\automake (ac\am) is that it isn't cross platform. CMake does the same job as ac\am but cross platform, and in the same way as ac\am you can't really ship the outputs (makefile or VS solution\vcproj) for use on other systems as they might be configured differently. CMake should be at least as easy to install as ac\am on all platforms and considerably easier on Windows (plus it works on Windows with normal Windows build tools). -- Graham Bloice ___ 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] CMake status
On 5 January 2015 at 20:17, Gerald Combs ger...@wireshark.org wrote: Our CMake environment has been coming along nicely. However, it's still missing several major build targets that are present in the Autotools and Nmake+QMake makefiles: dist. Balint created a script (tools/git-export-release.sh) which runs git archive. I'm not sure how complete it is compared to the current dist output. distcheck. Google turned up a couple of distcheck CMake modules but I'm not sure how applicable they would be to our environment. Having working dist and distcheck targets implies that they would be usable on Windows, which would be nice. packaging (Windows NSIS). If we convert the pile-of-defines in packaging/nsis/Makefile.nmake to a proper NSIS include file it looks like we could migrate the remaining targets pretty easily. Ultimately we might want to use CPack. packaging_papps (PortableApps). Same as the NSIS package. osx-package (.dmg). We need to add support for out-of-tree builds to packaging/macosx/osx-dmg.sh.in. rpm-package (Linux). *Should* be trivial to add. wsug, wsdg, release_notes (Windows). We need to figure out how to migrate the current a2x command (which is an inlined shell script) to something more suitable for CMake. pdb_zip (Windows PDB archive). *Should* be trivial to add. ENABLE_CODE_ANALYSIS (Windows build option). Same. As platforms go, OS X is the closest to completion. If we had a working osx-package target the OS X buildbots could use CMake exclusively. FWIW my current Windows CMake list of tasks to do (in no particular order): 1. Add zlib to build. 2. Add PortAudio to build. 3. Resolve running from build (run) directory. Currently it uses a batch file to modify the path so that all the 3rd party libs (glib etc.) are on the path. I think we need to do the same as the nmaek build and copy the files into the build dir using a script (PowerShell?) to do that work for the CMake build. This will also help when using CMake to create the NSIS package. 4. Fix compile warnings. 5. Fix CMake warnings. 6. Fix WinPcap version number for compile. 7. Get the intermediate build items out of the build dir, e.g. *.lib, *.exp. 8. Get the plugins into the correct subdirectory of the build dir. 9. Get the test executables out of the build dir. 10. Investigate CTest for running the tests. 11. Other stuff I've forgotten. -- Graham Bloice ___ 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] Update Windows Build Instructions
On 5 January 2015 at 23:39, Stephen Fisher sfis...@sdf.org wrote: On Tue, Jan 06, 2015 at 09:35:32AM +1000, David Arnold wrote: In my experience, shipping the configure(.sh) and Makefile(s) will work on any Unix system: you don?t need the configure.ac, Makefile.am or autoconf/automake installed in order to configure and build. Right, that's the best part of of autoconf: it generates a shell script called configure that will run on any system without having autoconf installed. Including Windows? -- Graham Bloice Software Developer Trihedral UK Limited ___ 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] Update Windows Build Instructions
On 5 January 2015 at 17:35, Stephen Fisher sfis...@sdf.org wrote: On Mon, Jan 05, 2015 at 05:20:27PM +, Graham Bloice wrote: Yes, use CMake :-) There are other cross-platform build solutions such as SCons, but it's just as bad as CMake (or maybe worse, I haven't tried anything other than a toy project). Adding a dissector to CMake is as simple as it is for nmake with the bonus that it works for both Windows and Linux (and wherever else CMake is used). Doing anything else with the CMake build system requires a lot of head scratching as getting the required output from the arcane language of CMake files can be a battle. With such a glowing review as that.. I'm not sure I want to try CMake :) Perhaps it would be better to handle the different platform build methods ourselves. It's the least worst option. It is actively used elsewhere though. We've handled the platform differences in the past by using make and nmake and autofoo and other piles of configuration grief. For Makefile.common, now think of CMakeLists.txt, that bit is very simple. Arguably CMake could be persuaded to read Makefile.common as it's just a list of files. I guess nmake was used in the past as a) it's nearly make, and b) the Visual Studio solution files at the time were horrible undocumented blobs that could only be read by the IDE. Nowadays they're somewhat documented bloated XML blobs that can be built using msbuild (which is quite nice to use) Yuck, XML. Fortunately using CMake means that unless you're modifying the build system you'll never have to look at them. msbuild will also use multiple threads to build so is can be much quicker. The other big advantage of VS solution files is that it should make it easier for folks to use the IDE debugger. Indeed. So what about making a script to read in Makefile.common and spitting out those XML files for msbuild? Or update the msbuild so IDE things in those files (if any) aren't reset every time its rebuilt. Good luck with that, you're just reinventing CMake and Scons and ... . I don't think you're really aware of the scale of the problem. Currently CMake produces 1 solution file and 310 vcxproj files. Sure, some of those .vcxproj files are how CMake checks itself for a rebuild when invoked by msbuild, but a lot of them are necessary. I don't get your last comment. Unless you're modifying the build system or adding new files, CMake doesn't come into it after the initial solution generation. The solution files automagically rebuild themselves if something in the CMakeLists has changed (i.e. a new file has been added). The path is CMakeLists.txt - Wireshark.sln I don't know of any cross platform build system that will then round trip back the way. While not the greatest tool to work with, CMake does do a good job. The dependencies etc. are much better handled than in nmake (minimal rebuilds), it's faster (given more cores), clean is 2 secs, and folks only need to manage one build system on all CMake platforms. Have you tried using CMake for Wireshark on bsd? -- Graham Bloice ___ 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] Update Windows Build Instructions
On 4 January 2015 at 03:58, Stephen Fisher sfis...@sdf.org wrote: On Sat, Jan 03, 2015 at 06:52:56PM +, Graham Bloice wrote: OK, it seems that even after all the complaints MS still haven't updated VS 201x to provide it. IIRC it went missing in VS2010. See here for at least one complaint about it: https://connect.microsoft.com/VisualStudio/feedback/details/771247/win32-mak-is-missing-from-vs-2012-win-8-sdk-install Which installs don't have it? I just installed VC 2013 Community Edition at home (the Win7 machine was at work), this time a32-bit Win8 and it also has the file, but I again needed to update the INCLUDE path: SET INCLUDE=%INCLUDE%;C:\Program Files\Microsoft SDKs\Windows\v7.1A\Include Maybe your Win7 SDK came from an earlier install of the Platform SDK? I think mine did, I do have a separate entry for it in the Add\Remove Programs list. I don't think VS2013 installs that SDK, only the Win 8 ones which are missing the file. I really should try removing VS2013, removing the Win 7 SDK, checking for detritus and re-installing VS2013 CE again. I wish we could distribute it ourselves, but it has an MS copyright notice on it. Can we ask someone about it? Do we really need it? It says on the top: # Win32.Mak - Win32 application master NMAKE definitions file for the # Microsoft Windows SDK programming samples Which makes it sound like its intended for the programming samples and just setups up a bunch of variables/options. I think we do need some of the vars. I suppose we could replicate the bits we need in our own makefile. However, if I ever (or someone else assists) get the Windows CMake build fully operational, all this will go away as we can drop the nmake support. -- Graham Bloice ___ 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] Update Windows Build Instructions
I believed this was no longer needed with VS2013 Community Edition, however ... In my dev VM, I uninstalled copies of VS2010 Pro, and VS2013 Pro (but didn't inspect for detritus) and then installed VS2013 CE and didn't need to copy the file thus I removed that section. However, looking at my dev VM, I have two copies of the file in: C:\Program Files (x86)\Microsoft SDKs\Windows\v7.1A\Include C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\include the latter of which is the same directory for both VS2013 Pro and CE, and they both have the same datestamp; 1/10/2012 10:14 What version of VS are you using? On 2 January 2015 at 23:04, Stephen Fisher sfis...@sdf.org wrote: One more thing I ran into: https://ask.wireshark.org/questions/4725/file-win32mak-not-found-stop Using Gerald's suggestion worked to get past verify_tools and setup so far: SET INCLUDE=%INCLUDE%;c:\Program Files (x86)\Microsoft SDKs\Windows\v7.1A\Include Should this be included in the dev guide? I found the answer by searching the Internet. I'm running this setup on Win7 64-bit. ___ 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 -- Graham Bloice Software Developer Trihedral UK Limited ___ 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] Update Windows Build Instructions
OK, it seems that even after all the complaints MS still haven't updated VS 201x to provide it. IIRC it went missing in VS2010. See here for at least one complaint about it: https://connect.microsoft.com/VisualStudio/feedback/details/771247/win32-mak-is-missing-from-vs-2012-win-8-sdk-install It's a really awkward file to obtain if you don't have it, i.e. you need the whole of the Win 7 Platform SDK. I wish we could distribute it ourselves, but it has an MS copyright notice on it. Can we ask someone about it? I'll try to update the Guide to put it back in. On 3 January 2015 at 17:26, Stephen Fisher sfis...@sdf.org wrote: On Sat, Jan 03, 2015 at 03:39:42PM +, Graham Bloice wrote: What version of VS are you using? VS 2013 Community Edition (on 64-bit Win7) ___ 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 -- Graham Bloice Software Developer Trihedral UK Limited ___ 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] Update Windows Build Instructions
I have mostly got the rework to the Developers Guide ready to update it to use VS2013 Community Edition. The question is how far do I go in removing old stuff? I've already removed anything from earlier than VS2010, but I'm thinking we should also drop that, although as the 12.x builds are produced using 2010 there may be some point to leaving it in. I'm also inclined to drop the verbiage about the legality of using MSVC to build Wireshark, i.e. vs GPL. IMHO this was all nonsense in the first place. Any thoughts? My changes will be posted to Gerrit shortly for your perusal. -- Graham Bloice ___ 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] Update Windows Build Instructions
On 22 December 2014 at 16:48, Stephen Fisher sfis...@sdf.org wrote: On Mon, Dec 22, 2014 at 12:01:58PM +, Graham Bloice wrote: I have mostly got the rework to the Developers Guide ready to update it to use VS2013 Community Edition. The question is how far do I go in removing old stuff? I've already removed anything from earlier than VS2010, but I'm thinking we should also drop that, although as the 12.x builds are produced using 2010 there may be some point to leaving it in. Is 2010 the version prevoius to 2013? It would probably be a good idea to keep at least one old version's instructions especially for those who haven't upgraded yet due to corporate policies for example. 2012 is actually the previous version but Wireshark hasn't used that in official builds so there have never been instructions using 2012. -- Graham Bloice ___ 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] Update Windows Build Instructions
On 22 December 2014 at 13:49, Alexis La Goutte alexis.lagou...@gmail.com wrote: On Mon, Dec 22, 2014 at 1:01 PM, Graham Bloice graham.blo...@trihedral.com wrote: I have mostly got the rework to the Developers Guide ready to update it to use VS2013 Community Edition. The question is how far do I go in removing old stuff? Nice ! Do you have add some stuff about Chocolate ? Yes, chocolatey installs for all relevant parts. -- Graham Bloice ___ 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] master f412c9a: Use ENC_BIG_ENDIAN when fetching FT_U?INT8 fields ...
On 15 December 2014 at 07:52, Alexis La Goutte alexis.lagou...@gmail.com wrote: Yes, Petri-dish/pre-commit is guard but need all people use it... +1 -- Graham Bloice ___ 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] What Wireshark base version to use for customization
And as you'll have to make the source of your customizations available, you might as well submit them to the core project where they'll be maintained and packages for all your required platforms will be automatically built. On 10 December 2014 at 15:13, Anders Broman anders.bro...@ericsson.com wrote: Hi, Note that under GPL you are obliged to supply the source code of your modifications if you distribute binaries to your customers. I would use the development version to get the bleeding edge stuff or the latest stable if stability is more of an issue. Regards Anders *From:* wireshark-dev-boun...@wireshark.org [mailto: wireshark-dev-boun...@wireshark.org] *On Behalf Of *Juan Jose Martin Carrascosa *Sent:* den 10 december 2014 14:39 *To:* Developer support list for Wireshark *Subject:* [Wireshark-dev] What Wireshark base version to use for customization Hi all, I have the task to customize and package a custom Wireshark version, so we can provide that to our customers. I wonder what Wireshark version should I use as base. The latest stable release or the development release? Also, I have been looking for the information to package binaries. So far, I have found the README files, and the Development webpage http://wiki.wireshark.org/Development. Any other source of information I can take a look at? My plan is to provide binaries for some Linux distributions, Solaris, MacOS and Windows. Thanks, Juanjo Martin -- Graham Bloice ___ 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] What Wireshark base version to use for customization
Hi Juan, We have a Solaris 10 buildbot ( http://buildbot.wireshark.org/trunk/builders/Solaris%2010%20SPARC) but nothing for Solaris 9. On 10 December 2014 at 17:17, Juan Jose Martin Carrascosa jua...@rti.com wrote: Many thanks for the detailed info to everyone. I already pushed some of my changes (already accepted) to the repository, and I will keep doing that in the future. I have a last question (technical one this time). Do you build Wireshark for Solaris (9 and 10)? I am facing issues doing it and I want to know if it is supposed to work and the problems are on my side. Anyone here has done that before manually? Any recommendation on where to get the missing packages? Thanks! Juanjo Martin On Wed, Dec 10, 2014 at 5:17 PM, Graham Bloice graham.blo...@trihedral.com wrote: Hi Juan, The GPL FAQ has answers for this type of question ( http://www.gnu.org/licenses/gpl-faq.html, see the section Distribution of programs released under the GNU licenses) but note that Wireshark is GPL 2.0. On 10 December 2014 at 15:21, Juan Jose Martin Carrascosa jua...@rti.com wrote: Hi Anders, Yes! I was aware of the licensing terms. Is it mandatory to provide the source in the same bundle as the binary or on the other hand. I can mention in our documentation that the source code is available, and if they ask for it, provide it? Thanks for the advice regarding the development version. Juanjo Martin On Wed, Dec 10, 2014 at 4:13 PM, Anders Broman anders.bro...@ericsson.com wrote: Hi, Note that under GPL you are obliged to supply the source code of your modifications if you distribute binaries to your customers. I would use the development version to get the bleeding edge stuff or the latest stable if stability is more of an issue. Regards Anders *From:* wireshark-dev-boun...@wireshark.org [mailto: wireshark-dev-boun...@wireshark.org] *On Behalf Of *Juan Jose Martin Carrascosa *Sent:* den 10 december 2014 14:39 *To:* Developer support list for Wireshark *Subject:* [Wireshark-dev] What Wireshark base version to use for customization Hi all, I have the task to customize and package a custom Wireshark version, so we can provide that to our customers. I wonder what Wireshark version should I use as base. The latest stable release or the development release? Also, I have been looking for the information to package binaries. So far, I have found the README files, and the Development webpage http://wiki.wireshark.org/Development. Any other source of information I can take a look at? My plan is to provide binaries for some Linux distributions, Solaris, MacOS and Windows. Thanks, Juanjo Martin ___ 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 -- Graham Bloice Software Developer Trihedral UK Limited ___ 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 -- Graham Bloice Software Developer Trihedral UK Limited ___ 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] What Wireshark base version to use for customization
On 10 December 2014 at 18:53, John Dill john.d...@greenfieldeng.com wrote: Message: 3 Date: Wed, 10 Dec 2014 11:08:25 -0700 From: Stephen Fisher sfis...@sdf.org To: Developer support list for Wireshark wireshark-dev@wireshark.org Subject: Re: [Wireshark-dev] What Wireshark base version to use for customization Message-ID: 20141210180825.ga29...@sdf.org Content-Type: text/plain; charset=us-ascii On Wed, Dec 10, 2014 at 12:51:23PM -0500, John Dill wrote: So what restrictions are there when you have a Wireshark plugin that contains proprietary information (which can be of the do not export variety) from the govt or customer and they do *not* want that information released to the public, since Wireshark can be used as a tool to visualize and analyze these private kinds of protocols? If some of that implementation leaks into the Wireshark application (like hiding all of the unnecessary protocol cruft to make it simpler for user to use), what are the implications? Is the proprietary information short, such as encryption keys? A preference can be used for things like that and then only if the user's preferences file is shared will it get out. If that's a high-risk, you could even have the dissector/plug-in do something non-stndard like reading a file for the information (but we probably wouldn't want that kind of dissector in the base source). The entire packet stream generated is a proprietary system on top of TCP and UDP that consists of avionics data, all of which is considered proprietary. There are several hundred different packet messages that contain one to several hundred data elements. I was curious how the license Wireshark uses applies to this scenario, since I've created a DLL to process data that is also distributed to a govt entity, but I'm using an open source project with a GPL license to translate this data, but the source code that translates the content they want to keep private. Regardless, there's no way I would be allowed to submit this plugin to the public Wireshark repository (not without serious legal/employment consequences), so maybe its a moot point to discuss. Best regards, John D. IMHO you're contravening the licence. When distributing you must abide by the licence that permits you to distribute and which requires you to make the source code available. A Wireshark plugin links with the main body of the program and thus is covered by the licence of the main program. -- Graham Bloice ___ 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] Qt not found
On 9 December 2014 at 10:47, Vishnu Bhatt vishnu.bh...@aricent.com wrote: Hello, I am trying to build 1.12.2 on windows 7 machine (both 32-bit and 64-bit). I am getting the following warning: nmake -f Makefile.nmake verify_tools Can't find Qt. This will become a problem at some point. What should be the solution to it? You have two options: - modify config.nmake such that the QT version isn't built, not a great idea going forward as the QT version will be the default version and the GTK version deprecated. - Install the appropriate QT build parts as per the Developers Guide Section 2.2.2 Install QT ( https://www.wireshark.org/docs/wsdg_html_chunked/ChSetupWin32.html#ChSetupQt ). -- Graham Bloice ___ 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] removed functions fast way to find substitutes?
On 21 November 2014 08:48, Semjon se...@web.de wrote:
Hello,
I maintain a dissector for a proprietary protocol of my employer and now
and then I grab me some current wireshark-sources and check if my
dissector code is still compatible which - in recent times-
unfortunately often it is not due to changes in the wireshark lib / API.
So everytime my code fails to compile/link I have to check which
functions were removed and which new functions do I have to use now.
One of my current problems is with
tvb_get_faked_unicode(...)
which isn't available anymore.
In my Protocol I have some Ascii-encoded String but which comes as two
bytes per character. Example:
{0x0031, 0x0032, 0x0033, 0x0034, 0x} in tvb should display in
GUI/Tree/PacketList as 1234
I used to call:
tvb_get_faked_unicode(NULL,tvb, 20,
((tvb_length(tvb)-20)/2),ENC_BIG_ENDIAN)
and display result as %s in col_append_fstr() or as FT_STRING in
proto_tree_add_string().
So could anyone give me a hint, is there a function still available for
this type of encoding or do I have to write something.
In general is there a fast/convenient way - other than manually looking
through the sources after functions that might do what i want - to check
if this function X is now replaced by function Y.
No changelog as such, but there is the git log that details all committed
changes, and the Wireshark Gerrit that has all changes often with some
discussion about them.
You can also use git blame at the place where the old function was to find
the change that removed it.
Finally, it sounds as though you're tracking trunk which is truly living on
the bleeding edge. You may be better off tracking the stable branch,
currently 1.12.x, as there's much less change in the API there, although
when that branch is replaced by the new release you'll get all the API
changes, but they should mostly be in one big hit.
--
Graham Bloice
___
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] Petri Dish update
On 19 November 2014 21:40, mman...@netscape.net wrote: So for the Windows build is there nmake + cmake or cmake only? I thought I saw some Petri-Dish runs with failed (cmake) Windows builds, but then some others with successful (cmake?) builds. So is cmake fully functional for Windows now? It compiles :-) It doesn't include PortAudio yet, and relies on zlib.dll being built by the nmake process, and doesn't produce an installer. The libs setup (if you want to do this at home) still runs from nmake as well, and the result of a cmake compile isn't runnable from the build directory without extensive path fiddling (the cmake build produces a setpath.bat that appropriately mangles your path), and the pe flags aren't set on the 3rd party DLL's. Apart from that it's good. Progress to the desired end state is slow, anyone else who wants to help would be greatly appreciated. -- Graham Bloice ___ 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] CMake support out of source plugin compilation
On 20 November 2014 08:53, Maarten Bezemer maarten.beze...@gmail.com wrote: On Thursday 13 November 2014 15:15:26 you wrote: On Thursday 13 November 2014 13:56:26 Graham Bloice wrote: While I'm all for making life easier for devs, if no-one else has identified this as a need, i.e. only you find it worthwhile, then we will end up with stuff not generally used in the repo and then who will be maintaining these bits of CMake? [1] is an attempt I found to have out of source builds. But it never got fed back to Wireshark and consists (eventually) outdated scripts. By integrating such functionality, keeps the development scripts up-to-date. I am also willing to write a (wiki) document explaining the out of source builds (when my patches get accepted) to help out others as well. As the current information about this subject on the Internet is very minimal. The maintenance of my patches is not too hard I think. I mainly use (cmake) scripts that are already available. The changes I made are to make them more generic, e.g. by getting rid of hard-coded paths. All scripts are also/already used when Wireshark itself gets build. Is there anything left for me to do or to explain? I would like gain some momentum either direction (approved or abandoned), so I know whether my current (out of source) plug-in implementation can be used at work or not. I was hoping to get a comment from Joerg Mayer (our resident CMake dev) but he's been a bit quiet lately. I'm really struggling for time at the moment to test and comment on it myself. -- Graham Bloice ___ 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] CMake support out of source plugin compilation
On 20 November 2014 10:51, Alexis La Goutte alexis.lagou...@gmail.com wrote: On Thu, Nov 20, 2014 at 10:01 AM, Graham Bloice graham.blo...@trihedral.com wrote: On 20 November 2014 08:53, Maarten Bezemer maarten.beze...@gmail.com wrote: On Thursday 13 November 2014 15:15:26 you wrote: On Thursday 13 November 2014 13:56:26 Graham Bloice wrote: While I'm all for making life easier for devs, if no-one else has identified this as a need, i.e. only you find it worthwhile, then we will end up with stuff not generally used in the repo and then who will be maintaining these bits of CMake? [1] is an attempt I found to have out of source builds. But it never got fed back to Wireshark and consists (eventually) outdated scripts. By integrating such functionality, keeps the development scripts up-to-date. I am also willing to write a (wiki) document explaining the out of source builds (when my patches get accepted) to help out others as well. As the current information about this subject on the Internet is very minimal. The maintenance of my patches is not too hard I think. I mainly use (cmake) scripts that are already available. The changes I made are to make them more generic, e.g. by getting rid of hard-coded paths. All scripts are also/already used when Wireshark itself gets build. Is there anything left for me to do or to explain? I would like gain some momentum either direction (approved or abandoned), so I know whether my current (out of source) plug-in implementation can be used at work or not. I was hoping to get a comment from Joerg Mayer (our resident CMake dev) but he's been a bit quiet lately. May be also with Balint, Debian Package use cmake for build... I'm really struggling for time at the moment to test and comment on it myself. And now Petri Dish can build on Windows with cmake for see if there is some regression ;-) Does the Ubuntu Petri-dish have a cmake build step? -- Graham Bloice ___ 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] Adding Dissector Help
On 20 November 2014 18:34, Chris Brandson chris.brand...@gmail.com wrote: Hi, I’m working on a number of bug fixes and improvements to the ZigBee dissector. One of the things I would like to add is help for the preferences pane. The call to uat_new has a help parameter which adds a url fragment to https://www.wireshark.org/docs/wsug_html_chunked”. I can write the help, but where do I submit it? Regards, + Chris Brandson It's in the source repo under docbook/wsug_src in asciidoc format. -- Graham Bloice ___ 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] QT graphics version for Windows
I just noticed that the buildbots (and presumably the releases) are using the opengl version of QT, whereas I've always used the angle version in my local builds. The QT page on the choice ( http://qt-project.org/wiki/Qt-5-on-Windows-ANGLE-and-OpenGL) implies that the angle version is more general purpose and required if you want to use RDP or QTMultimedia video. Has there been an explicit discussion on the QT version that I've missed, or should we discuss this now? -- Graham Bloice ___ 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 may get ISN wrong
Hi Matt, Thanks for your input, there's information about reporting bugs[1] and submitting patches[2] on the wiki. [1]: http://wiki.wireshark.org/ReportingBugs [2]: http://wiki.wireshark.org/Development/SubmittingPatches On 18 November 2014 16:37, Matt matta...@gmail.com wrote: Find enclosed a fix for HEAD. % git diff --stat epan/dissectors/packet-tcp.c | 8 +--- epan/dissectors/packet-tcp.h | 5 ++--- 2 files changed, 7 insertions(+), 6 deletions(-) 2014-11-18 15:54 GMT+01:00 Matt matta...@gmail.com: Thanks for the suggestion but relative seq nb is a really nice feature I use for plotting and analyzing data. If the TCP ISN can be 0 (I believe it can ?) then my report qualifies as a bug. The fix should be a ~10 lines patch with the expense of a boolean in tcp_analysis. I am willing to send a patch for it. 2014-11-17 18:41 GMT+01:00 ronnie sahlberg ronniesahlb...@gmail.com: You can just disable relative sequence numbers in the preferences for tcp. On Mon, Nov 17, 2014 at 9:38 AM, Matt matta...@gmail.com wrote: Hi, I use wireshark to examinate some traces generated by a network simulator (ns3 www.nsnam.org) which set the ISN to 0 (no randomization yet). As wireshark assumes base_seq == 0 to be an unitialized value, it triggers some error as wireshark tries to set again and again the base seq. Here is the output of a single 3WHS (custom printf), in peculiar in the 4th line, which is the ACK of the 3WHS, wiresharks sets base_seq =seq-1, ie 0-1 and it wraps the seq number (ugly). Setting base seq to : 0 Setting base seq to : 0 Setting rev base seq to : 0 Setting base seq to : 4294967295 Setting rev base seq to : 0 Setting rev base seq to : 0 Setting base seq to : 0 Setting base seq to : 0 Setting rev base seq to : 0 Setting base seq to : 0 Setting rev base seq to : 0 Setting base seq to : 1 I understand it seems a corner case but I don't believe have an ISN equal to 0 is forbidden by the RFC ?! I was wondering if I could add some boolean such as base_seq_set in mptcp_info_t to prevent such a behavior. Regards Matt -- Graham Bloice ___ 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] QT graphics version for Windows
On 18 November 2014 17:35, Pascal Quantin pascal.quan...@gmail.com wrote: Le 18 nov. 2014 18:28, Gerald Combs ger...@wireshark.org a écrit : On 11/18/14 4:54 AM, Pascal Quantin wrote: 2014-11-18 13:35 GMT+01:00 Graham Bloice graham.blo...@trihedral.com: I just noticed that the buildbots (and presumably the releases) are using the opengl version of QT, whereas I've always used the angle version in my local builds. The QT page on the choice ( http://qt-project.org/wiki/Qt-5-on-Windows-ANGLE-and-OpenGL) implies that the angle version is more general purpose and required if you want to use RDP or QTMultimedia video. Has there been an explicit discussion on the QT version that I've missed, or should we discuss this now? Hi Graham, I don't think this was ever discussed. As RDP is a quite common usage on Windows (as seen with the GTK2 specific memory bug reports we got), ANGLE would seem to be the best choice. The drawback of dropping Windows XP support is not an issue as we already decided to stop supporting it officially. We fall under the Your application does not use OpenGL at all case described in the page linked above, so I followed their recommendations and installed the OpenGL packages. If anyone plans on adding an RTP video player or using QGLWidget I can switch to the ANGLE packages. Are there issues with using our current packages over RDP? It's been working fine here, even at low color depths. I did not check it myself and just assumed that what was written on the Qt page was right. If it works with OpenGL and RDP, that's fine! (and I will change my local configuration). I didn't check either, just read the page and thought the angle version was best for us. -- Graham Bloice ___ 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] QT graphics version for Windows
On 18 November 2014 17:27, Gerald Combs ger...@wireshark.org wrote: BTW, there are unofficial Chocolatey packages for the Qt SDK and Creator: https://chocolatey.org/packages?q=qt-sdk, although 64-bit VS2013 support seems to be missing. It might be feasible to create a wireshark-build-essentials metapackage at some point. That was on my long list, but might move it up so that it could be invoked by CMake. I'm likely to change my Windows build approach in CMake a bit for the final step as well where we copy all the third party libs into the run directory, by wrapping all that up in a PowerShell script and invoking that from CMake as a custom build task. -- Graham Bloice Software Developer Trihedral UK Limited ___ 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] Visual Studio 2013 Community Edition
Info for Windows devs, Microsoft have released this ( http://www.visualstudio.com/products/visual-studio-community-vs, essentially VS 2013 Pro) and it's free to use for open source projects. The relevance to Wireshark is that it makes the Pro tools available for free, e.g. Code Analysis and it will replace the free Express editions. -- Graham Bloice ___ 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
