Re: [Wireshark-dev] Is it possible to update the version of gcrypt?
Hi, 2014-04-01 9:58 GMT+07:00 Gerald Combs ger...@wireshark.org: On 3/31/14, 6:35 PM, Pascal Quantin wrote: 2014-03-31 20:02 GMT+02:00 Gerald Combs ger...@wireshark.org mailto:ger...@wireshark.org: On 3/30/14 10:00 AM, Pascal Quantin wrote: 2014-01-08 0:25 GMT+01:00 Pascal Quantin pascal.quan...@gmail.com mailto:pascal.quan...@gmail.com mailto:pascal.quan...@gmail.com mailto:pascal.quan...@gmail.com: Gerald, according to the README.Wireshark file found in gnutls-2.12.18-1.2-win32ws archive, you manually modified the OpenSUSE packages: - Definition files were created using pexports. - Import libraries were created using the MSVC++ lib utility using the make-lib.sh script. I do not know where to find those utilities neither how to use them. pexports is its own package in OpenSUSE, although it looks like gendef (or even libtool itself) might be the preferred way to generate .def files nowadays. make-lib.sh is in the bin directory in gnutls-2.12.18-1.2-win32ws.zip. It's just a series of lib commands, e.g. lib /machine:x86 /def:libgcrypt-11.def /name:libgcrypt-11.dll \ /out:libgcrypt-11.lib Maybe those missing steps on my side can explain my issue. Would you be OK if we to try to upgrade those libraries? If yes, could you help? 2 small things I noted: - libgcrypt-11.dll/lib is now renamed libgcrypt-20.dll/lib. It impacts config.nmake, Makefile.nmake, cmake\modules\FindGCRYPT.cmake, packaging\nsis\wireshark.nsi and ui\qt\QtShark.pro - the openSUSE libraries require an extra libgcc_s_sjlj-1.dll file found in mingw32-libgcc-4.8.2-1.2.noarch.rpm archive (my own compiled libraries did not need it but I failed to compile a win64 variant so far). It looks like that's an exception handling library which can be linked statically: http://stackoverflow.com/questions/12921911/mingw-libgcc-s-sjlj-1-dll-is-missing Hi all, I restarted playing with the libraries provided by OpenSUSE this weekend and was able to get libgcrypt 1.6.0 working on my Windows machine. The remaining problem is that we should either recompile GnuTLS 2.12.18 with this newer libgcrypt (Im' not willing to do so), or upgrade GnuTLS to the version 3.1.22 provided by OpenSUSE. We deactivated the use of GnuTLS 3.X in the past due to their move to GPL3.0. But according to their website and the header files, the core library is still LGPL 2.1+. Would it make it usable for us? GnuTLS switched to LGPLv3+ in version 3.0, then back to LGPLv2.1+ in version 3.1.10. We need switch to a newer 3.x release at some point since the 2.12 branch is no longer maintained as far as I know. However, we need to be careful with the version of GMP that we ship since it switched to LGPLv3+: https://gmplib.org/list-archives/gmp-devel/2013-August/003357.html OK, here is where I stand. I have a patch allowing to build win32 and win64 (presumably, I do not have access to my win64 machine for a few days) Wireshark against GnuTLS 3.1.22 and Grrypt 1.6.0 (thanks to the pre built packages provided by OpenSUSE). The newer GnuTLS 3.1.22 package creates new dependencies on the following packages: libgmp-5.0.5, libnettle-2.7-3, libhogweed-2.7-3, libp11-kit0-0.20.1 and libffi-3.0.13. Nettle is LGPL, p11-kit and ffi license does not seem problematic, and GMP 5.0.5, as you stated, is LGPLv3+ (only release 4.2.1 seems usable). So this is definitely a blocker. There is also an issue with the libp11-kit0-0.20.1 library provided by OpenSUSE folks. It uses the function strerror_s from MSVCRT.dll, but this symbol is not exported by the Windows XP MSVCRT (it is running fine on Windows 7). I was about to try to recompile the p11-kit library myself to avoid this dependency but the GMP licensing issue is depressing (I did not check yet how difficult it was to recompile the 4.2.1 version and hope that it would work with the GnuTLS pre compiled library). It looks like GMP has been relicensed to GPLv2+ / LGPLv3+ as of 6.0.0 (released a few days ago). Hopefully the OBS packages will be updated soon. I have just switched the wireshark package in Debian to use GnuTLS 3 with the appropriate GMP: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=747578 Cheers, Balint ___ Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] Is it possible to update the version of gcrypt?
2014-05-27 12:41 GMT+02:00 Bálint Réczey bal...@balintreczey.hu: Hi, 2014-04-01 9:58 GMT+07:00 Gerald Combs ger...@wireshark.org: On 3/31/14, 6:35 PM, Pascal Quantin wrote: 2014-03-31 20:02 GMT+02:00 Gerald Combs ger...@wireshark.org mailto:ger...@wireshark.org: On 3/30/14 10:00 AM, Pascal Quantin wrote: 2014-01-08 0:25 GMT+01:00 Pascal Quantin pascal.quan...@gmail.com mailto:pascal.quan...@gmail.com mailto:pascal.quan...@gmail.com mailto:pascal.quan...@gmail.com : Gerald, according to the README.Wireshark file found in gnutls-2.12.18-1.2-win32ws archive, you manually modified the OpenSUSE packages: - Definition files were created using pexports. - Import libraries were created using the MSVC++ lib utility using the make-lib.sh script. I do not know where to find those utilities neither how to use them. pexports is its own package in OpenSUSE, although it looks like gendef (or even libtool itself) might be the preferred way to generate .def files nowadays. make-lib.sh is in the bin directory in gnutls-2.12.18-1.2-win32ws.zip. It's just a series of lib commands, e.g. lib /machine:x86 /def:libgcrypt-11.def /name:libgcrypt-11.dll \ /out:libgcrypt-11.lib Maybe those missing steps on my side can explain my issue. Would you be OK if we to try to upgrade those libraries? If yes, could you help? 2 small things I noted: - libgcrypt-11.dll/lib is now renamed libgcrypt-20.dll/lib. It impacts config.nmake, Makefile.nmake, cmake\modules\FindGCRYPT.cmake, packaging\nsis\wireshark.nsi and ui\qt\QtShark.pro - the openSUSE libraries require an extra libgcc_s_sjlj-1.dll file found in mingw32-libgcc-4.8.2-1.2.noarch.rpm archive (my own compiled libraries did not need it but I failed to compile a win64 variant so far). It looks like that's an exception handling library which can be linked statically: http://stackoverflow.com/questions/12921911/mingw-libgcc-s-sjlj-1-dll-is-missing Hi all, I restarted playing with the libraries provided by OpenSUSE this weekend and was able to get libgcrypt 1.6.0 working on my Windows machine. The remaining problem is that we should either recompile GnuTLS 2.12.18 with this newer libgcrypt (Im' not willing to do so), or upgrade GnuTLS to the version 3.1.22 provided by OpenSUSE. We deactivated the use of GnuTLS 3.X in the past due to their move to GPL3.0. But according to their website and the header files, the core library is still LGPL 2.1+. Would it make it usable for us? GnuTLS switched to LGPLv3+ in version 3.0, then back to LGPLv2.1+ in version 3.1.10. We need switch to a newer 3.x release at some point since the 2.12 branch is no longer maintained as far as I know. However, we need to be careful with the version of GMP that we ship since it switched to LGPLv3+: https://gmplib.org/list-archives/gmp-devel/2013-August/003357.html OK, here is where I stand. I have a patch allowing to build win32 and win64 (presumably, I do not have access to my win64 machine for a few days) Wireshark against GnuTLS 3.1.22 and Grrypt 1.6.0 (thanks to the pre built packages provided by OpenSUSE). The newer GnuTLS 3.1.22 package creates new dependencies on the following packages: libgmp-5.0.5, libnettle-2.7-3, libhogweed-2.7-3, libp11-kit0-0.20.1 and libffi-3.0.13. Nettle is LGPL, p11-kit and ffi license does not seem problematic, and GMP 5.0.5, as you stated, is LGPLv3+ (only release 4.2.1 seems usable). So this is definitely a blocker. There is also an issue with the libp11-kit0-0.20.1 library provided by OpenSUSE folks. It uses the function strerror_s from MSVCRT.dll, but this symbol is not exported by the Windows XP MSVCRT (it is running fine on Windows 7). I was about to try to recompile the p11-kit library myself to avoid this dependency but the GMP licensing issue is depressing (I did not check yet how difficult it was to recompile the 4.2.1 version and hope that it would work with the GnuTLS pre compiled library). It looks like GMP has been relicensed to GPLv2+ / LGPLv3+ as of 6.0.0 (released a few days ago). Hopefully the OBS packages will be updated soon. I have just switched the wireshark package in Debian to use GnuTLS 3 with the appropriate GMP: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=747578 And OpenSUSE now provides x64 Windows binary of GMP 6.0.0a but is still stuck to GMP 5.0.5 for win32. Pascal. ___ Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org
Re: [Wireshark-dev] wireshark-only capture format
+1 for independence from libpcap. Libpcap team does not approve anything that is not protocol, so anything like events/logs/file format is a problem. I am agree, there is a great lag in communication in libpcap (but sometimes new DLT can be add immediately) DLT_ is for .pcap files, I am do not know how about pcap-ng. What about using UserDLT or Exported/UpperPDU? Or maybe is solution extcap + wiretap (WTAP_ENCAP_ and WTAP_FILE_TYPE_SUBTYPE_)? On 26 May 2014 16:45, Dmitry Bazhenov dim...@pigeonpoint.com wrote: Hello, all, Recently, the tcpdump-workers mailing list has stopped working for me. None of my replies posted into the list over the last week have got to the subscribers. None of my mails sent directly to the person who previously interacted with me have been answered. This makes the situation around the DLT_ value reservation and my patch for the IPMI-Trace dissector hanged in air. And I wonder why is it needed requesting for DLT_/LINKTYPE_ values from PCAP library maintainers for captures which are intended only to be analyzed in Wireshark/tshark? Is there a chance that for that kind of captures there will be a separate Wireshark format which does not do anything with libPCAP? Or probably there is already such format and I can skip the DLT_ value reservation? Regards, Dmitry ___ 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ł Ł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
Re: [Wireshark-dev] Byte matching
On 05/26/14 04:07, Matteo Pelliccia wrote: Hi to all, maybe it's a silly question. Is it possibile to know what byte match in display filter expression? For example if I have a pcap file with some packet and I run tshark with -Y option I would like to know which bytes match that expression, is it possibile? Unfortunately no, not today. There's been some discussion of highlighting the field (if not the bytes) in the GUI (there's probably a bug requesting that) but this is the first time I've heard of it for tshark. ___ 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
