Re: [Wireshark-dev] PCAP-over-IP in Wireshark?
On Tue, Feb 01, 2022 at 09:24:28AM -0600, chuck c wrote: > "Replacing 127.0.0.1 with localhost didn't work for some reason though." > > dumpcap ( > https://gitlab.com/wireshark/wireshark/-/blob/master/dumpcap.c#L1366) calls > ws_socket_ptoa ( > https://gitlab.com/wireshark/wireshark/-/blob/master/wsutil/socket.h#L72) > which expects an IP address. > > * Convert the strings ipv4_address:port or [ipv6_address]:port to a > * sockaddr object. > > That matches the description on the wiki entry: > https://wiki.wireshark.org/CaptureSetup/Pipes.md#tcp-socket > "... using the -i TCP@[:port] option." > > I'm not sure it's worth making a name resolution call. Maybe better to > update the docs and usage to " instead of ""? It probably makes sense: Using a resolver-call will handle ipv4 vs. ipv6 vs. name. Kind regards Jörg ___ Sent via:Wireshark-dev mailing list Archives:https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] ISO-8601 date support
Hello Jaap,
On Fri, Dec 03, 2021 at 12:28:23PM +0100, Jaap Keuter wrote:
> With commit a0173cd7 you’ve added ISO-8601 date support to text2pcap.
> The “Import from Hex dump...” feature of Wireshark is supposed to be equally
> capable.
> Would you be able to add this capability there as well?
While I agree that this would make sense, the C++ code looks so different, that
I don't
know where to add this code (and it doesn't help that I don't understand C++
beyond simple
C).
In order for this to really behave the same, the acutual parsing funtionality
should
probably be in code used by both text2pcap and the GUI and be put into the ui/
folder,
where we keep code common to CLI and QT. Also, it would be nice if the Regular
Expression
feature from 8c1b29a597764cd3e4 could be ported back to the CLI as well.
So if anyone feels like refactoring these things into common code, that would
make sense
from my point of view, but there is really not much I can achieve while only
spending a
sensible amount of time.
Kind regards
Jörg
--
Joerg Mayer
We are stuck with technology when what we really want is just stuff that
works. Some say that should read Microsoft instead of technology.
___
Sent via:Wireshark-dev mailing list
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
[Wireshark-dev] Gitlab missing feature compared to Github
Hello, there is one very valuable feature of github that was lost in the transition to giblab: The commit message does no longer reference the merge request, making it way harder to look at the discussion leading to a merge. Can this feature please be readded? Thanks! Jörg -- Joerg Mayer We are stuck with technology when what we really want is just stuff that works. Some say that should read Microsoft instead of technology. ___ Sent via:Wireshark-dev mailing list Archives:https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] How to test legacy (glib-compat) code
On Wed, Oct 27, 2021 at 09:53:43AM -0700, Gerald Combs wrote: > The oldest version of GLib that we build with is 2.56.1 on the CentOS 7 > builder: > > CentOS 7 2.56.1 ... > Is there any reason we shouldn't increase the minimum GLib version to 2.56 in > the master and 3.6 branches? That would mean that we no longer support RHEL > 6, but it's currently in "extended life cycle support": > https://access.redhat.com/support/policy/updates/errata OK, that would be my preferred solution ;-) While we are at it: Would it make sense to increase some other requirements? In the meantime I will increase the compat test to something like 2.58 and see whether it compiles. Thanks! Jörg -- Joerg Mayer We are stuck with technology when what we really want is just stuff that works. Some say that should read Microsoft instead of technology. ___ Sent via:Wireshark-dev mailing list Archives:https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
[Wireshark-dev] How to test legacy (glib-compat) code
Hello, I've created a merge request (https://gitlab.com/wireshark/wireshark/-/merge_requests/4820) that requires a newer version (2.56) of glib than the minimum we require in cmake (2.38), so I created a glib-compat entry to emulate the required functionality via an older function that has been deprecated (2.62) Two questions: 1) Is any of our buildbots running on such an old version of glib so I know that it compiles? 2) Is there a way to test whether the compat code (text2pcap) actually works? I have no problem to provide/commit a testfile. Thanks! Jörg -- Joerg Mayer We are stuck with technology when what we really want is just stuff that works. Some say that should read Microsoft instead of technology. ___ Sent via:Wireshark-dev mailing list Archives:https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] ___asan_version_mismatch_check_apple_902
Hello, On Thu, Nov 15, 2018 at 12:07:01PM +0100, Joerg Mayer wrote: > after updating to XCode 10.1 (but not Mojave) I'm getting the following on > program start: ... > dyld: lazy symbol binding failed: Symbol not found: > ___asan_version_mismatch_check_apple_902 > Referenced from: /usr/local/lib/libpcap.A.dylib > Expected in: > /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/clang/10.0.0/lib/darwin/libclang_rt.asan_osx_dynamic.dylib Actually reading that libpcap was the culprit would have saved me from bothering the list... Ciao Jörg -- Joerg Mayer We are stuck with technology when what we really want is just stuff that works. Some say that should read Microsoft instead of technology. ___ Sent via:Wireshark-dev mailing list Archives:https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
[Wireshark-dev] ___asan_version_mismatch_check_apple_902
Hello, after updating to XCode 10.1 (but not Mojave) I'm getting the following on program start: + export G_MESSAGES_DEBUG=all + G_MESSAGES_DEBUG=all + export G_DEBUG=fatal-criticals + G_DEBUG=fatal-criticals + ./run/Wireshark.app/Contents/MacOS/Wireshark -v + tee logs/run.log dyld: lazy symbol binding failed: Symbol not found: ___asan_version_mismatch_check_apple_902 Referenced from: /usr/local/lib/libpcap.A.dylib Expected in: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/clang/10.0.0/lib/darwin/libclang_rt.asan_osx_dynamic.dylib dyld: Symbol not found: ___asan_version_mismatch_check_apple_902 Referenced from: /usr/local/lib/libpcap.A.dylib Expected in: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/clang/10.0.0/lib/darwin/libclang_rt.asan_osx_dynamic.dylib Any idea how to fix that? I reran macos-setup.sh and completely cleaned the build directory. Thanks Jörg -- Joerg Mayer We are stuck with technology when what we really want is just stuff that works. Some say that should read Microsoft instead of technology. ___ Sent via:Wireshark-dev mailing list Archives:https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] dumpcap broken on mac?
On Mon, May 14, 2018 at 03:09:39AM -0700, Guy Harris wrote: > On May 14, 2018, at 3:04 AM, Guy Harris <g...@alum.mit.edu> wrote: > > > But what's XHC20? > > Oh, USB: > > https://lists.apple.com/archives/usb/2017/Jun/msg4.html I wanted to play with it after discovering it post-update but had too many other things going on and promptly forgot it again. > I guess I'll have to decide to trust High Sierra at some point and upgrade Yes, at least with only two non-Apple HW devices requiring drivers and almost no closed source software (except from Apple) it was an easy choice for me. Jörg -- Joerg Mayer <jma...@loplof.de> We are stuck with technology when what we really want is just stuff that works. Some say that should read Microsoft instead of technology. ___ Sent via:Wireshark-dev mailing list <wireshark-dev@wireshark.org> Archives:https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] dumpcap broken on mac?
On Mon, May 14, 2018 at 03:04:06AM -0700, Guy Harris wrote: > On May 14, 2018, at 2:55 AM, Joerg Mayer <jma...@loplof.de> wrote: > > jmayer@newegg:~/worktmp/wireshark/build/master/logs$ dumpcap -L > > dumpcap: Can't get list of interfaces: SIOCGIFMEDIA on XHC20 failed: > > Operation not supported by device > > Try the current libpcap master branch. To quote the most recent commit: Fixed. Many thanks! Jörg -- Joerg Mayer <jma...@loplof.de> We are stuck with technology when what we really want is just stuff that works. Some say that should read Microsoft instead of technology. ___ Sent via:Wireshark-dev mailing list <wireshark-dev@wireshark.org> Archives:https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
[Wireshark-dev] dumpcap broken on mac?
Hi, since I recompiled libpcap and wireshark this weekend, capture doesn't work any more on my Mac (current macOS): jmayer@newegg:~/worktmp/wireshark/build/master/logs$ dumpcap -L dumpcap: Can't get list of interfaces: SIOCGIFMEDIA on XHC20 failed: Operation not supported by device Anyone else hit by this? Ciao Jörg -- Joerg Mayer <jma...@loplof.de> We are stuck with technology when what we really want is just stuff that works. Some say that should read Microsoft instead of technology. ___ Sent via:Wireshark-dev mailing list <wireshark-dev@wireshark.org> Archives:https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] Question about pcap_create and HAVE_REMOTE
On Wed, Mar 29, 2017 at 04:28:24PM -0700, Guy Harris wrote: > On Mar 29, 2017, at 2:04 PM, Joerg Mayer <jma...@loplof.de> wrote: > > > does HAVE_REMOTE imply that libpcap supports pcap_create nowadays? If so, > > it would > > allow some nice cleanups ;) > > On Windows, where we do checks at run time (as we load WinPcap dynamically) > as well as compile time, older versions of WinPcap had pcap_open(), with > remote support, but not pcap_create(); current versions have both. Our code > is built with support for both; if the version of WinPcap we've loaded > doesn't have pcap_create(), we fall back on pcap_open_live(). > > On macOS, if we were to do run-time checking (so that we can support new > features if, as, and when Apple picks them up), the oldest OS we support with > our binary packages is Snow Leopard, which has pcap_create(). > > On UN*X without run-time checking, the only releases from tcpdump.org that > offer remote capture support will also have pcap_create(); you'd only have to > worry about people who add remote capture to a pre-1.0 libpcap and build it > and install it themselves, and I'm not sure worrying about them is worth it. So it might be worth waiting for libpcap to unconditionally enable rpcap support before getting rid of all the pcap_create #defines inside have_remote. Thanks! Jörg -- Joerg Mayer <jma...@loplof.de> We are stuck with technology when what we really want is just stuff that works. Some say that should read Microsoft instead of technology. ___ Sent via:Wireshark-dev mailing list <wireshark-dev@wireshark.org> Archives:https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
[Wireshark-dev] Question about pcap_create and HAVE_REMOTE
[Tried to ask this on tcpdump-workers first, but the mails silently dissappeared] Hello, does HAVE_REMOTE imply that libpcap supports pcap_create nowadays? If so, it would allow some nice cleanups ;) Thanks Jörg -- Joerg Mayer <jma...@loplof.de> We are stuck with technology when what we really want is just stuff that works. Some say that should read Microsoft instead of technology. ~ ___ Sent via:Wireshark-dev mailing list <wireshark-dev@wireshark.org> Archives:https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
[Wireshark-dev] Capture code in GUIs replicated
Hello, is anyone who understand both GUIs willing to unify the capture code common to ui/gtk/capture_dlg.c:insert_new_rows() and ui/qt/manage_interfaces_dialog.cpp:addRemoteInterfaces()? Found this while playing with bug 13448. Thanks Jörg -- Joerg Mayer <jma...@loplof.de> We are stuck with technology when what we really want is just stuff that works. Some say that should read Microsoft instead of technology. ___ Sent via:Wireshark-dev mailing list <wireshark-dev@wireshark.org> Archives:https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
[Wireshark-dev] tshark with -R less than stellar
Hello, I stmbled on https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=2234 and the situation looks less than stellar (also documented in comment 25): tshark -i utun2 -R "ip.addr==10.122.4.12" tshark: -R without -2 is deprecated. For single-pass filtering use -Y. tshark -i utun2 -Y "ip.addr==10.122.4.12" Capturing on 'utun2' ... ^C4 packets captured tshark -w test.pcapng -i utun2 -Y "ip.addr==10.122.4.12" tshark: Display filters aren't supported when capturing and saving the captured packets. tshark -w test.pcapng -i utun2 -R "ip.addr==10.122.4.12" tshark: -R without -2 is deprecated. For single-pass filtering use -Y. tshark -w test.pcapng -i utun2 -R "ip.addr==10.122.4.12" -2 tshark: Live captures do not support two-pass analysis. IMO we need a solution that doesn't violate the principle of least surprise quite as much as the current situation. Ideas? Thanks! Jörg -- Joerg Mayer <jma...@loplof.de> We are stuck with technology when what we really want is just stuff that works. Some say that should read Microsoft instead of technology. ___ Sent via:Wireshark-dev mailing list <wireshark-dev@wireshark.org> Archives:https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] Kasumi algorithm implementation
On Mon, Feb 27, 2017 at 10:12:00PM +0100, Pascal Quantin wrote: > Nothing has changed since that time (except the fact that the link is > http://www.3gpp.org/specifications/60-confidentiality-algorithms). > As you said this was raised in the past so far not integrated to avoid > being potentially sued (like for AMR codecs, SNOW3G and ZUC ciphers,...). > None of us has paid a lawyer to verify whether we could safely add it or > not. What has changed is, that there seems to be a useable (from a copyright point of view) source code implementation available where it wasn't before. I still think that a pure source implementation is unproblematic. But out of curiosity: Is there a link to the patent, so we may have a look? Thanks Jörg -- Joerg Mayer <jma...@loplof.de> We are stuck with technology when what we really want is just stuff that works. Some say that should read Microsoft instead of technology. ___ Sent via:Wireshark-dev mailing list <wireshark-dev@wireshark.org> Archives:https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
[Wireshark-dev] Communication between dumpcap and wireshark partially broken when using rpcap
Hello, can someone with some understanding of the communication between dumpcap and wireshark please take a look at bug 13418 (13102 might be a duplicate but I'm not totally sure)? It looks like dumpcap when talking to a rpcap interface is returning strange stuff to Wireshark. Thanks Jörg -- Joerg Mayer <jma...@loplof.de> We are stuck with technology when what we really want is just stuff that works. Some say that should read Microsoft instead of technology. ___ Sent via:Wireshark-dev mailing list <wireshark-dev@wireshark.org> Archives:https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] Conditional compiles
Hello, On Tue, Feb 14, 2017 at 10:01:06AM +0100, Roland Knall wrote: > HAVE_LIBPCAP not only serves as a check for having libpcap in the first > place, but also for changing the UI if it is not there. Which would mean, > that putting a small non-functional header-only satisfying version within > the repository would lead to versions of Wireshark being build, acting very > differently then they are supposed to. For instance, remote capture > capabilities are only enabled, if the corresponding function actually > exists. Which leads to reduced code and binaries if the function does not. > Now putting a small reduced function which only serves to satisfy some > header functionality within the repository would bloat up the general > binary. Actually I personally don't like to have a software to sometimes have an item and sometimes not - an item being greyed out is OK, but missing is not nice, especially for users trying to follow instructions they found on the internet. But that is (mostly) a matter of taste. Wrt the size bloat: I don't buy this argument, as we have many features that are rarely used - and a stub libpcap wouldn't have to be big, the current fullblown 64-bit libpcap on my system is 310k. And a version that basically does not have any Interface access could be much smaller. In case we wanted to we could stub out the bpf-compiler and other stuff as well, but personally I think a version that doesn't provide any local capture code would be fine. Wrt using a full libpcap wherever possible: Sure, but there seem to be some environments where this isn't possible (e.g. iOS - OK, I'm not aware someone built Wireshark for it anyway) although I'm not sure whether there exists a libpcap for iOS or if it just wouldn't manage to enable capturing or whatever. As far as "security" concerns in companies are concerned: Providing someone with Admin/root permissions and then providing a crippled version of Wireshark is corporate lawyer logic - something to be avoided by normal mortals ;-> Ciao Jörg -- Joerg Mayer <jma...@loplof.de> We are stuck with technology when what we really want is just stuff that works. Some say that should read Microsoft instead of technology. ___ Sent via:Wireshark-dev mailing list <wireshark-dev@wireshark.org> Archives:https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
[Wireshark-dev] Conditional compiles
Hallo, inspired by the way too late demise of HAVE_LIBGCRPYT I've done a rough count of other variables. I include everything with 9+ occurrences below: 9 AIRPDCAP_DEBUG 9 DEBUG_FRAGMENTS 9 HAVE_IGE_MAC_INTEGRATION 9 HAVE_LIBCAP 9 WIMAX_16D_2004 10 ALG_USERETRY 10 HAVE_BPF_IMAGE 10 HAVE_NETINET_IN_H 10 HAVE_SYS_SOCKET_H 10 SHOW_BUFFER_COLUMN 10 __linux__ 12 HAVE_GEOIP_V6 12 HAVE_LIBGCRYPT_AEAD 13 PACKAGE 13 VERSION 14 DEBUG_CHILD 14 DEBUG_CONVERSATION 14 FIXED_POINT 14 HAVE_GTKOSXAPPLICATION 15 DEBUG_HASHING 15 HAVE_GETOPT_LONG 15 QT_MULTIMEDIA_LIB 15 SIGINFO 15 USE_WIN32_FILE_DIALOGS 15 _NL_CURRENT 16 HAVE_GETOPT_H 16 HAVE_SYS_TYPES_H 17 NDEBUG 18 DEBUG_BER 18 HAVE_C_ARES 20 HAVE_NGHTTP2 21 HAVE_LIBPORTAUDIO 21 HAVE_LIBSMI 21 Q_OS_WIN 22 __APPLE__ 23 HAVE_UNISTD_H 24 HAVE_HEIMDAL_KERBEROS 24 HAVE_LUA 24 WANT_PACKET_EDITOR 25 HAVE_PCAP_OPEN_DEAD 25 HAVE_SOFTWARE_UPDATE 30 _DEBUG 31 Q_OS_MAC 32 HAVE_LIBGNUTLS 34 HAVE_HFI_SECTION_INIT 35 HAVE_PCAP_SETSAMPLING 40 HAVE_KERBEROS 40 _AVP_DEBUGGING 43 HAVE_GDK_GRESOURCE 45 TVBPARSE_DEBUG 47 HAVE_AIRPCAP 48 __SUNPRO_C 56 HAVE_ZLIB 59 _MSC_VER 59 __GNUC__ 62 DEBUG_CAMELSRT 65 HAVE_GEOIP 68 HAVE_PLUGINS 70 CAN_SET_CAPTURE_BUFFER_SIZE 86 DEBUG 92 HAVE_PCAP_CREATE 96 HAVE_PCAP_REMOTE 122 HAVE_EXTCAP 182 DEBUG_TCAPSRT 293 HAVE_LIBPCAP 506 _WIN32 506 __cplusplus To me it looks like HAVE_LIBPCAP would be a candidate to solve somehow, as it is regularly involved when compiles break without this define. Would it maybe make sense so include a dummy version inside Wireshark that basically does (mostly) nothing? Thanks Jörg -- Joerg Mayer <jma...@loplof.de> We are stuck with technology when what we really want is just stuff that works. Some say that should read Microsoft instead of technology. ___ Sent via:Wireshark-dev mailing list <wireshark-dev@wireshark.org> Archives:https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] GUI Change for Wireshark Remote Interfaces
On Thu, Oct 27, 2016 at 09:36:47PM -0700, Guy Harris wrote: > On Oct 27, 2016, at 8:54 PM, Guy Harris <g...@alum.mit.edu> wrote: > > > On Oct 27, 2016, at 4:18 PM, Joerg Mayer <jma...@loplof.de> wrote: > > > >> (the policy 42 stuff fixes > >> the symptom instead of the root cause). > > > > ...the policy 42 stuff. Apple doesn't build libpcap with an @rpath > > install_name, and we don't do so with autotools, so I'm not sure whether we > > want to do that. > > Actually, for that reason, we *do* want to set that policy to "OLD", so we > don't get an @rpath install name and don't get suggestions from CMake that we > should want it, so I checked that one in as well. OK, after building libpcap with autotools to have an install target and fixing two warnings turning errors in Wireshark I now have a "working" version with rpcap compiled in (at least config.h has both HAVE_REMOTE and HAVE_PCAP_REMOTE) - it just fails to pick up the newly compiled and installed version of libpcap and uses the system version instead: jmayer@newegg:~/worktmp/wireshark$ otool -L /usr/local/bin/Wireshark.app/Contents/MacOS/Wireshark /usr/local/bin/Wireshark.app/Contents/MacOS/Wireshark: ... /usr/lib/libpcap.A.dylib (compatibility version 1.0.0, current version 1.0.0) ... Wireshark itself was built using cmake. Ideas how to fix this? Thanks Jörg -- Joerg Mayer <jma...@loplof.de> We are stuck with technology when what we really want is just stuff that works. Some say that should read Microsoft instead of technology. ___ Sent via:Wireshark-dev mailing list <wireshark-dev@wireshark.org> Archives:https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] GUI Change for Wireshark Remote Interfaces
On Thu, Oct 27, 2016 at 12:09:20PM -0700, Guy Harris wrote:
> On Oct 27, 2016, at 11:28 AM, Roland Knall <rkn...@gmail.com> wrote:
>
> > Guy, is the version on github for libpcap already equipped with pcap_open
> > on Mac?
>
> The current version on github has pcap_open() in pcap-new.c; *however*:
>
> 1) it's not in Makefile.in, so it doesn't show up if you do autotools
> builds;
>
> 2) it's only in CMake builds if HAVE_REMOTE is defined, which is done
> by default only on Windows;
>
> 3) I have not tested whether it builds and is useful on any UN*X
> platform - it might not work.
1) SEP ;-)
2) Easy to fix
3) It will neither compile nor link.
The attached patch will make it compile and link - nothing else was tested
mkdir build; cd build; cmake -DHAVE_REMOTE=ON ..; make
Feel free to ignore, modify or apply the patch (the policy 42 stuff fixes
the symptom instead of the root cause).
Jörg
--
Joerg Mayer <jma...@loplof.de>
We are stuck with technology when what we really want is just stuff that
works. Some say that should read Microsoft instead of technology.
diff --git a/CMakeLists.txt b/CMakeLists.txt
index 0ed8b61..d4cdc7d 100644
--- a/CMakeLists.txt
+++ b/CMakeLists.txt
@@ -1,4 +1,8 @@
cmake_minimum_required( VERSION 2.8.8 )
+# MACOSX_RPATH: Requires at least 2.8.12
+if (POLICY CMP0042)
+cmake_policy(SET CMP0042 OLD)
+endif()
project( pcap )
#
@@ -23,13 +27,11 @@ if( WIN32 )
set(PACKET_DLL_DIR "" CACHE PATH "Path to directory with include and lib
subdirectories for packet.dll")
endif( WIN32 )
-#
-# XXX - this should be an option, defaulting to "yes" for Windows and to
-# "no", for now, on UN*X.
-#
if( WIN32 )
-set( HAVE_REMOTE 1 )
-endif( WIN32 )
+option (HAVE_REMOTE "Enable remote capture" ON)
+else()
+option (HAVE_REMOTE "Enable remote capture" OFF)
+endif()
##
# Project settings
diff --git a/cmakeconfig.h.in b/cmakeconfig.h.in
index 94edb5f..7a09d73 100644
--- a/cmakeconfig.h.in
+++ b/cmakeconfig.h.in
@@ -166,6 +166,9 @@
/* Define to 1 if you have the `strlcpy' function. */
#cmakedefine HAVE_STRLCPY 1
+/* Define to 1 if you have the `strtok_r' function. */
+#cmakedefine HAVE_STRTOK_R 1
+
/* Define to 1 if the system has the type `struct BPF_TIMEVAL'. */
#cmakedefine HAVE_STRUCT_BPF_TIMEVAL 1
diff --git a/pcap/pcap.h b/pcap/pcap.h
index 7f92a37..c15bd1c 100644
--- a/pcap/pcap.h
+++ b/pcap/pcap.h
@@ -172,11 +172,11 @@ struct pcap_stat {
u_int ps_recv; /* number of packets received */
u_int ps_drop; /* number of packets dropped */
u_int ps_ifdrop;/* drops by interface -- only supported on some
platforms */
-#if defined(_WIN32) && defined(HAVE_REMOTE)
+#if defined(HAVE_REMOTE)
u_int ps_capt; /* number of packets that reach the application
*/
u_int ps_sent; /* number of packets sent by the server on the
network */
u_int ps_netdrop; /* number of packets lost on the network */
-#endif /* _WIN32 && HAVE_REMOTE */
+#endif /* HAVE_REMOTE */
};
#ifdef MSDOS
___
Sent via:Wireshark-dev mailing list <wireshark-dev@wireshark.org>
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
[Wireshark-dev] Why is building with libpcap optional?
Hello, I tried to recall why building with libpcap is optional and failed. libpcap usage is deeply embedded into Wireshark and the resulting #ifdef/#ifndef HAVE_LIBPCAP shows: grep -r -E '#\s*if.*HAVE_LIBPCAP' . | wc -l 288 I'd really like to get rid of that and the "simplest" solution would be to require libpcap to be installed. I have some fallback ideas but would really like to use as simple a solution as possible. Thanks! Jörg -- Joerg Mayer <jma...@loplof.de> We are stuck with technology when what we really want is just stuff that works. Some say that should read Microsoft instead of technology. ___ Sent via:Wireshark-dev mailing list <wireshark-dev@wireshark.org> Archives:https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] [Wireshark-commits] buildbot failure in Wireshark (development) on OSX 10.6 x64
On Sun, Jun 26, 2016 at 05:30:56PM +, buildbot-no-re...@wireshark.org wrote: > The Buildbot has detected a new failure on builder OSX 10.6 x64 while > building wireshark. Full details are available at: > > http://buildbot.wireshark.org/wireshark-master/builders/OSX%2010.6%20x64/builds/11328 > > Buildbot URL: http://buildbot.wireshark.org/wireshark-master/ > > Buildslave for this Build: osx-10.6-x64 > > Build Reason: The SingleBranchScheduler scheduler named 'Gerrit' triggered > this build > Build Source Stamp: [branch master] b84637b4f6a1f3f910b97c21264ff6132a9c19c4 > Blamelist: Jörg Mayer <jma...@loplof.de> > > BUILD FAILED: failed compile_1 Not me :-) [ 39%] Building CXX object ui/qt/CMakeFiles/qtui.dir/file_set_dialog.cpp.o cc1plus: warnings being treated as errors /Users/buildslave/Documents/wireshark-trunk/osx106x64/build/ui/qt/endpoint_dialog.cpp: In member function 'QVariant EndpointTreeWidgetItem::colData(int, bool, bool) const': /Users/buildslave/Documents/wireshark-trunk/osx106x64/build/ui/qt/endpoint_dialog.cpp:350: warning: control reaches end of non-void function make[2]: *** [ui/qt/CMakeFiles/qtui.dir/endpoint_dialog.cpp.o] Error 1 make[2]: *** Waiting for unfinished jobs -- Joerg Mayer <jma...@loplof.de> We are stuck with technology when what we really want is just stuff that works. Some say that should read Microsoft instead of technology. ___ Sent via:Wireshark-dev mailing list <wireshark-dev@wireshark.org> Archives: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] Some planned cleanups of the 802.11 dissector
Hello, I plan to do some cleanups to - somewhat improve the readability of the code 1) Get rid of reduntant author entries and code comments, see https://code.wireshark.org/review/16154 2) Get rid of those fixed field functions that only add one of two items. Call the remaining functions directly (without the indirection of add_fixed_field()). - make the use of filters more straight forward: We currently register the following top level filters within the file: wlan_aggregate wlan wlan_mgt wlan_rsna_eapol I'd like to merge at least wlan_mgt into wlan. I don't see the gain in the separation and it definitely confuses me: a) wlan_mgt is not only managemnt frames but also control frames while data frames are just wlan. b) The addresses inside wlan_mgt frames are addressed via wlan.xxx Let me know what you think about these things. Thanks Jörg -- Joerg Mayer <jma...@loplof.de> We are stuck with technology when what we really want is just stuff that works. Some say that should read Microsoft instead of technology. ___ Sent via:Wireshark-dev mailing list <wireshark-dev@wireshark.org> Archives: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, linker flags, whitespace, cmp0004
Hello Martin, is this problem still open? Thanks Jörg On Sun, Apr 17, 2016 at 03:14:32PM +0200, Martin Kaiser wrote: > I'm getting strange cmake errors on Debian Wheezy (cmake 2.8.9). > > -- Performing Test WS_LD_FLAG_VALID0 > CMake Error at CMakeLists.txt:11 (ADD_EXECUTABLE): > Target "cmTryCompileExec701976172" links to item " -Wl,--as-needed" which > has leading or trailing whitespace. This is now an error according to > policy CMP0004. > > > CMake Error: Internal CMake error, TryCompile generation of cmake failed > -- Performing Test WS_LD_FLAG_VALID0 - Failed > statuscheck linker flag - test linker flags: -pie > -- Performing Test WS_LD_FLAG_VALID1 > CMake Error at CMakeLists.txt:11 (ADD_EXECUTABLE): > Target "cmTryCompileExec2930916065" links to item " -pie" which has leading > or trailing whitespace. This is now an error according to policy > CMP0004. > > CMake Error: Internal CMake error, TryCompile generation of cmake failed > > > > Apparently, cmake doesn't like leading whitespace in linker options. I > tried setting the CMP0004 policy to the old behaviour which is not > ignore the whitespace. > > cmake_policy(SET CMP0004 OLD) > > This doesn't fix things. Google results show that this is in fact a bug > in cmake's parsing. > > KDE discovered the bug in their build > http://comments.gmane.org/gmane.comp.kde.devel.buildsystem/7858 > > Cmake fixed it here > https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=e65ef08b > > > I tried to work around this by removing whitespace from the linker flags > or applying a regexp replace on the final list of linker flags. > None of this produced a clean and readable solution. > > Does anyone more familiar with cmake have a recommendation how to fix > this properly? -- Joerg Mayer <jma...@loplof.de> We are stuck with technology when what we really want is just stuff that works. Some say that should read Microsoft instead of technology. ___ Sent via:Wireshark-dev mailing list <wireshark-dev@wireshark.org> Archives: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] [tcpdump-workers] What's the difference between NdisMediumBare80211 (DLT_IEEE802_11) and NdisMediumRadio80211 (DLT_IEEE802_11_RADIO)
On Sat, Apr 09, 2016 at 12:32:34AM -0700, Guy Harris wrote: > -100 dBm is 1/10,000,000,000 milliwatts, which is .1 picowatt; I'm not a > radio expert, but I suspect there might not be any radios capable of > detecting that low a power level except in specialized physics or radio > astronomy cases. (It's 1/10th the power consumption of an average human cell: > > > https://en.wikipedia.org/wiki/Orders_of_magnitude_(power)#Picowatt_.2810.E2.88.9212_watt.29 > > so it's not much power.) The minimum sensitivity of wireless radios is -96dBm, i.e. standards compliant radios must be able to differentiate signals better than -96 dBm from noise. Some years ago I looked at the datasheet of an Atheros base Wifiadapter that claimed -106 dBm sensitivity. Ciao Jörg -- Joerg Mayer <jma...@loplof.de> We are stuck with technology when what we really want is just stuff that works. Some say that should read Microsoft instead of technology. ___ Sent via:Wireshark-dev mailing list <wireshark-dev@wireshark.org> Archives: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] #ifdef mess
On Tue, Mar 29, 2016 at 03:34:38PM +0100, João Valverde wrote:
> On 28-03-2016 23:30, Joerg Mayer wrote:
> >I've been meaning to write this mail for some years now but finally got
> >around to it.
> >
> >Earlier today I committed 30900b443b85a7e760d703ca3d6efe61df4fe623, which I'm
> >incredibly unproud of because of readablity:
> >
> > static void
> >-get_reordercap_runtime_info(GString *str _U_)
> >+get_reordercap_runtime_info(
> >+#if defined(HAVE_LIBZ) && !defined(_WIN32)
> >+GString *str)
> >+#else
> >+ GString *str _U_)
> >+#endif
> > {
> >
> >It fixes the error at hand, but that is about all the good I can say about
> >it.
>
> It's only an error because -Werror=used-but-marked-unused was
> enabled. Since the semantics of _U_ are *possibly* unused variable,
> neither the warning nor the #ifdef should exist IMO.
I don't follow your logic here. Couldn't we by the same logic just remove the
_U_
and then blame the resulting warning turning erro on the unused warning? The
idea
or turning on many warnings is to find coding/logic bugs. Blaming the problem on
turning on the warning is like shooting the messenger, i.e. plain wrong.
IMO the root cause isn't this or that warning - it's that we have many #ifdef
paths
in our normal code. I won't have the time to really look into this until the end
of April, but it looks like either nobody cares about this or I didn't manage to
get the idea what really bugs me across, so I probably have to demonstrate the
idea with a specific patch.
Thanks!
Jörg
--
Joerg Mayer <jma...@loplof.de>
We are stuck with technology when what we really want is just stuff that
works. Some say that should read Microsoft instead of technology.
___
Sent via:Wireshark-dev mailing list <wireshark-dev@wireshark.org>
Archives: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] #ifdef mess
Hello list,
I've been meaning to write this mail for some years now but finally got around
to it.
Earlier today I committed 30900b443b85a7e760d703ca3d6efe61df4fe623, which I'm
incredibly unproud of because of readablity:
static void
-get_reordercap_runtime_info(GString *str _U_)
+get_reordercap_runtime_info(
+#if defined(HAVE_LIBZ) && !defined(_WIN32)
+GString *str)
+#else
+ GString *str _U_)
+#endif
{
It fixes the error at hand, but that is about all the good I can say about it.
Oh, and it matches the elegance of the code above and below it.
If someone has a better readable solution to that, please go ahead. But apart
from the ugliness of the code, it's the #ifdef mess in our "normal" code. It
makes
development on our different platforms a lot more error prone, code validation
along all compile paths basically impossible - in short, we have a configuration
management problem - with our different customers the diffent environments in
which our users build their own Wireshark.
What I would like to see is a drastic reduction of #if HAVE_something_or_other
in the code. Typical methods to reduce that kind of stuff are compile time
variables in those cases where we don't access #included structures directly.
Another method is to have a wrapper library that hides the availability and
structures from the normal code. E.g. it might be a good idea to put the zlib
stuff into a (static) wrapper lib that provides the zlib compile time and run
time version strings as well as a (const) variable that indicates the presence
of zlib at all. There are quite a lot more things that do not need a #ifdef
solution, that way making sure that the preprocessor and compiler get to see
the source and commplain if something is broken even for the non-use case.
Wrt. zlib: Do we really still want to support a case when a build environment
does not provide one?
Done rambling, time to go to bed.
Good night
Jörg
--
Joerg Mayer <jma...@loplof.de>
We are stuck with technology when what we really want is just stuff that
works. Some say that should read Microsoft instead of technology.
___
Sent via:Wireshark-dev mailing list <wireshark-dev@wireshark.org>
Archives: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] buildbot failure in Wireshark (development) on Ubuntu 14.04 x64
OK I take back my remark that packet-actrace.h works properly. The const line is not in the taps_wslua.c file. No idea what I saw previously. So maybe make-taps.pl shoudl print a warning/error when it drops an element? Thanks Jörg -- Joerg Mayer <jma...@loplof.de> We are stuck with technology when what we really want is just stuff that works. Some say that should read Microsoft instead of technology. ___ Sent via:Wireshark-dev mailing list <wireshark-dev@wireshark.org> Archives: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] buildbot failure in Wireshark (development) on Ubuntu 14.04 x64
On Mon, Mar 28, 2016 at 04:04:48PM +0100, João Valverde wrote: > The variable is set but not used. Nothing strange about the warning. Pascal seems to have understood what I meant: The variable is indeed unused and the compiler should complain about this no matter whether it is declared unused or not. Anyway: From my analysis it seems there was a bug hidden somewhere (the struct elements were not added) either in epan/wslua/make-taps.pl or packet-bacapp.[hc] that was now exposed by actually receiving the warning and Pascal is working on a fix. Thanks! Jörg -- Joerg Mayer <jma...@loplof.de> We are stuck with technology when what we really want is just stuff that works. Some say that should read Microsoft instead of technology. ___ Sent via:Wireshark-dev mailing list <wireshark-dev@wireshark.org> Archives: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] buildbot failure in Wireshark (development) on Ubuntu 14.04 x64
On Mon, Mar 28, 2016 at 02:26:41PM +, buildbot-no-re...@wireshark.org wrote:
> The Buildbot has detected a new failure on builder Ubuntu 14.04 x64 while
> building wireshark. Full details are available at:
>
> http://buildbot.wireshark.org/wireshark-master/builders/Ubuntu%2014.04%20x64/builds/5897
../../../epan/wslua/taps_wslua.c: In function 'wslua_bacapp_to_table':
../../../epan/wslua/taps_wslua.c:43:93: error: variable 'v' set but not used
[-Werror=unused-but-set-variable]
static void wslua_bacapp_to_table(lua_State* L, const void* p) { const
bacapp_info_value_t* v; v = (const bacapp_info_value_t*)p; lua_newtable(L);
> Buildbot URL: http://buildbot.wireshark.org/wireshark-master/
>
> Buildslave for this Build: ubuntu-14.04-x64
>
> Build Reason: The SingleBranchScheduler scheduler named 'Gerrit' triggered
> this build
> Build Source Stamp: [branch master] 7e5dae90d65ed062f2d01c63174cc1c94850a19a
> Blamelist: Jörg Mayer <jma...@loplof.de>
>
> BUILD FAILED: failed make distcheck
OK, this is strange: I changed epan/wslua/make-taps.pl to not declare v as _U_
(which
is obviously isn't: it's used in the next statement) and now we get a "set but
not used"
warning but not before? Btw, on my Clang (XCode) system I do not get this
warning/error.
Ideas what is going on here (compiler bug?)?
Thanks
Jörg
--
Joerg Mayer <jma...@loplof.de>
We are stuck with technology when what we really want is just stuff that
works. Some say that should read Microsoft instead of technology.
___
Sent via:Wireshark-dev mailing list <wireshark-dev@wireshark.org>
Archives: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] Why are we linking with --as-needed?
[Less than 6000 mails in my Wireshark backlog mailbox] On Thu, Jan 21, 2016 at 10:36:41PM -0500, Jeff Morriss wrote: > On 01/21/2016 10:17 PM, Guy Harris wrote: > >The GNU linker documentation says of the --as-needed flag > > > >--as-needed > >--no-as-needed ... > >About all I could find for a reason were bugs such as > > > > https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=1677 > > > >complaining that Wireshark didn't build with --as-needed. > > > >So why is it useful that it be built - or, at least, buildable - with > >--as-needed? (It's obviously not *necessary* as not all platform support > >that capability.) > > I thought I remembered seeing (back around the time of bug 1677) a > web page explaining why it was a Good Idea. About all I can find at > the moment is this one: > > https://wiki.gentoo.org/wiki/Project:Quality_Assurance/As-needed IIRC, the link sums it up pretty well - with this option we specify all dependencies explicitely. Ciao Jörg -- Joerg Mayer <jma...@loplof.de> We are stuck with technology when what we really want is just stuff that works. Some say that should read Microsoft instead of technology. ___ Sent via:Wireshark-dev mailing list <wireshark-dev@wireshark.org> Archives: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] Change LIB and Executable names using CMake?
Hello, a litte late, but I have too many unread mails in my Wireshark inbox... On Fri, Jan 15, 2016 at 02:36:12PM +, Alex Lindberg wrote: > I am using CMake to build a customized version of Wireshark that needs to be > installed beside the default Wireshark libraries and run-time files. What does "beside" mean? Wouldn't it be easiest to install it to its own folder, e.g. /opy/mycompany/ instead of /usr/ and then just put a script "/usr/bin/mywsname" into the normal path? That way no extra source patching would be necessary. Ciao Jörg -- Joerg Mayer <jma...@loplof.de> We are stuck with technology when what we really want is just stuff that works. Some say that should read Microsoft instead of technology. ___ Sent via:Wireshark-dev mailing list <wireshark-dev@wireshark.org> Archives:https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] Can't build GTK only using CMake on Windows7
Hello, On Fri, Mar 25, 2016 at 02:46:35AM +, Robert Cragie wrote: > Following the announcement about deprecating nmake (which I have been using > successfully for years), I thought I would try using CMake. I deliberately > only want to build the GTK version so I use the following options with > CMake: > > cmake -DENABLE_CHM_GUIDES=on -DBUILD_wireshark=off -G "Visual Studio 12" > ..\wireshark > > CMake runs but there are some errors at the end: > > CMake Error at packaging/nsis/CMakeLists.txt:199 (add_custom_command): > Error evaluating generator expression: > > $ > > No target "wireshark" ... > Any ideas here? Which version of wireshark? And why do you want to build the GTK-Only version? Jörg -- Joerg Mayer <jma...@loplof.de> We are stuck with technology when what we really want is just stuff that works. Some say that should read Microsoft instead of technology. ___ Sent via:Wireshark-dev mailing list <wireshark-dev@wireshark.org> Archives: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] Compiling Wireshark with gcc-6: Lots of new warnings
Hello, I just compiled current source with gcc-6 and warnings as errors. Attached is the error log with the 351 files that error out. Ciao Jörg -- Joerg Mayer <jma...@loplof.de> We are stuck with technology when what we really want is just stuff that works. Some say that should read Microsoft instead of technology. errors.log.bz2 Description: BZip2 compressed data ___ 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] Removing echld/ directory
Hello, the echld/ directory is not compiled by default, has a IMO lousy code quality, no users in the current code base and will most likely not build with MSVC anyway (variable length array). I intend to remove it soon'ish if there are no convincing reasons to keep it (convincing likely to mean intention to clean it up, compiling it by default on all platforms ;-) Ciao Jörg -- Joerg Mayer <jma...@loplof.de> We are stuck with technology when what we really want is just stuff that works. Some say that should read Microsoft instead of technology. ___ Sent via:Wireshark-dev mailing list <wireshark-dev@wireshark.org> Archives: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: Disable building with QT ?
On Sat, Nov 14, 2015 at 03:58:13PM -0800, Guy Harris wrote: > > On Nov 14, 2015, at 11:13 AM, Bálint Réczey <bal...@balintreczey.hu> wrote: > > > To enable completion you also need the bash-completion package > > installed and sourced in your bash session. > > I.e., this isn't a feature of CMake, it's a feature of the combination of > > 1) a version of bash with programmable completion > > and > > 2) a version of CMake that supplies completion rules > > so you won't have that feature unless > > 1) your shell is a version of bash with support for programmable > completion > > and > > 2) your CMake has completion rules and those rules are installed for > use by bash. And 3) it actually works, which it doesn't for me: OS X 10.11, CMake 3.4.1, GNU bash, version 3.2.57(1)-release (x86_64-apple-darwin15) dies with "cmake -D-bash: compopt: command not found" Ciao Jörg -- Joerg Mayer <jma...@loplof.de> We are stuck with technology when what we really want is just stuff that works. Some say that should read Microsoft instead of technology. ___ Sent via:Wireshark-dev mailing list <wireshark-dev@wireshark.org> Archives: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] Various problems with tshark
Hello Pascal, thanks for the quick response - solved my immediate problem ;-) On Mon, Aug 31, 2015 at 08:17:44AM +0200, Pascal Quantin wrote: > 2015-08-31 5:34 GMT+02:00 Joerg Mayer <jma...@loplof.de>: > > > When using tshark from head I have a bunch of problems right now: > > > > 1) stderr is getting spammed with > > (process:9870): Capture-WARNING **: Dissector stp incomplete in frame > > 41915: undecoded byte number 57 (0x0030+9) > > > > You seem to have activated the prefs.enable_incomplete_dissectors_check. > Simply go to Preferences -> Protocols and uncheck "Look for incomplete > dissectors". Yes, I do, but I really expected that to be (similar to) expert items, not some "spam" taht (optically) interfers with the normal output of tshark. > > 2) -T fields -e _ws.col.info isn't working (empty column), both with and > > without -V > The right field name is _ws.col.Info Sigh. Is _ws.* documented in one of the manpages? I couldn't find it. And the only mention I could find (the tshark manpage) used a small 'i'. Could we plese agree to either *always* use small letters or to make the filter names case insensitive? Also: = $ tshark -T fields -e asdf ** (process:13516): WARNING **: 'asdf' isn't a valid field! tshark: Some fields aren't valid $ tshark -T fields -e _ws.col.info Capturing on 'Wi-Fi' ^C 21 packets captured jmayer@newegg:~/firmatmp/salalah/WIP/tests/radius$ tshark -T fields -e _ws.col.asdf Capturing on 'Wi-Fi' = Should we try for a bit more consistency here? Thanks again Jörg -- Joerg Mayer <jma...@loplof.de> We are stuck with technology when what we really want is just stuff that works. Some say that should read Microsoft instead of technology. ___ Sent via:Wireshark-dev mailing list <wireshark-dev@wireshark.org> Archives: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] Various problems with tshark
On Mon, Aug 31, 2015 at 09:47:11PM +0200, Pascal Quantin wrote: > > On Mon, Aug 31, 2015 at 08:17:44AM +0200, Pascal Quantin wrote: > > > 2015-08-31 5:34 GMT+02:00 Joerg Mayer <jma...@loplof.de>: > > > > > > > When using tshark from head I have a bunch of problems right now: > > > > > > > > 1) stderr is getting spammed with > > > > (process:9870): Capture-WARNING **: Dissector stp incomplete in frame > > > > 41915: undecoded byte number 57 (0x0030+9) ... > My understanding is that it is not intended to be activated by default, but > only in "development mode" (at least according to the comments in the > Gerrit patch if I remember correctly). I don't really want to switch stuff on and off all the time. Many "interesting" things are noted during normal work. > > > > 2) -T fields -e _ws.col.info isn't working (empty column), both with ... > tshark.pod needs to be fixed, but tshark -h gives you _ws.col.Info. Which you now fixed. > Could we plese agree to either *always* use small letters or to make the > > filter names case insensitive? Also: > > = > > $ tshark -T fields -e asdf > > ** (process:13516): WARNING **: 'asdf' isn't a valid field! > > tshark: Some fields aren't valid > > $ tshark -T fields -e _ws.col.info > > Capturing on 'Wi-Fi' ... > Right now it's the column title as you configured it. Maybe it should be > made case insensitive, but there is a real logic (and not inconsistency). I > do not ceck this code part and whether _ws.col.XXX could (should?) trigger > an error if the syntax is wrong. Sorry, that was easy to misunderstand: The inconsistency remark was only about how non-existent field names are handled, not about the spelling. Thanks Jörg -- Joerg Mayer <jma...@loplof.de> We are stuck with technology when what we really want is just stuff that works. Some say that should read Microsoft instead of technology. ___ Sent via:Wireshark-dev mailing list <wireshark-dev@wireshark.org> Archives: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] Problem writing a file dissector for vwr capture files
Hello,
I'm trying to write a file dissector for the IxVeriWave (.vwr) capture files
(without loosing the ability to open said capture files normally of course)
and am failing:
Running tshark -X 'read_format:MIME Files Format' -V -r testfile.vwr (or
the equivalent steps in wireshark) results in
tshark: The file testfile.vwr isn't a capture file in a format TShark
understands.
Trying to just take over the complete capture file was also unsuccessful.
I've attached the current source of the dissector. Simple question: What am
I missing ;-)
In case you want to test, use the capture attached to bug 11464.
Thanks
Jörg
--
Joerg Mayer jma...@loplof.de
We are stuck with technology when what we really want is just stuff that
works. Some say that should read Microsoft instead of technology.
/* file-vwr.c
* Routines for IxVeriWave (.vwr) dissection
* Documentation only available in form of source code
*
* Copyright 2015, Joerg Mayer (see AUTHORS file)
*
* Wireshark - Network traffic analyzer
* By Gerald Combs ger...@wireshark.org
* Copyright 1998 Gerald Combs
*
* This program is free software; you can redistribute it and/or
* modify it under the terms of the GNU General Public License
* as published by the Free Software Foundation; either version 2
* of the License, or (at your option) any later version.
*
* This program is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
* GNU General Public License for more details.
*
* You should have received a copy of the GNU General Public License
* along with this program; if not, write to the Free Software
* Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA.
*/
#include config.h
#include epan/packet.h
#include epan/expert.h
#include wiretap/wtap.h
void proto_register_vwr(void);
void proto_reg_handoff_vwr(void);
static int proto_vwr = -1;
static dissector_handle_t vwr_handle;
static int hf_vwr_record = -1;
static int hf_vwr_record_header = -1;
static int hf_vwr_record_data = -1;
static int hf_vwr_record_cmd = -1;
static int hf_vwr_header_unknown1 = -1;
static int hf_vwr_header_word1 = -1;
static int hf_vwr_header_word2 = -1;
static int hf_vwr_header_word3 = -1;
static int hf_vwr_data_unknown1 = -1;
static expert_field ei_invalid_header_length = EI_INIT;
static expert_field ei_invalid_data_length = EI_INIT;
static gint ett_vwr_record = -1;
static gint ett_vwr_record_header = -1;
static gint ett_vwr_record_data = -1;
#define VWR_HEADER_LENGTH 20
/*
* Fetch a 64-bit value in Corey-endian form.
*/
#define pcoreytohll(p) ((guint64)*((const guint8 *)(p)+4)56| \
(guint64)*((const guint8 *)(p)+5)48| \
(guint64)*((const guint8 *)(p)+6)40| \
(guint64)*((const guint8 *)(p)+7)32| \
(guint64)*((const guint8 *)(p)+0)24| \
(guint64)*((const guint8 *)(p)+1)16| \
(guint64)*((const guint8 *)(p)+2)8| \
(guint64)*((const guint8 *)(p)+3)0)
struct record_data {
guint32 data_length;
};
static const value_string record_cmd_vals[] = {
{ 0, NULL }
};
static void
pre_dissect_header(tvbuff_t *tvb, struct record_data *record_data)
{
guint8 record_cmd;
guint32 word2;
guint32 word3;
guint32 data_size;
record_cmd = tvb_get_guint8(tvb, 0);
word2 = tvb_get_guint32(tvb, 8, ENC_BIG_ENDIAN);
word3 = tvb_get_guint32(tvb, 12, ENC_BIG_ENDIAN);
switch (record_cmd) {
case 0x21:
case 0x31:
case 0x8B:
case 0xC1:
data_size = word2 0x;
break;
case 0xFE:
data_size = word3 0x;
break;
default:
data_size = 0;
break;
}
record_data-data_length = data_size;
}
static gint
dissect_header(proto_tree *tree, tvbuff_t *tvb)
{
proto_tree *header_tree;
proto_item *header_item;
gint offset = 0;
header_item = proto_tree_add_item(tree, hf_vwr_record_header, tvb, offset, VWR_HEADER_LENGTH, ENC_NA);
header_tree = proto_item_add_subtree(header_item, ett_vwr_record_header);
proto_tree_add_item(header_tree, hf_vwr_record_cmd, tvb, offset, 1, ENC_NA);
offset +=1;
proto_tree_add_item(header_tree, hf_vwr_header_unknown1, tvb, offset, 3, ENC_NA);
offset +=3;
proto_tree_add_item(header_tree, hf_vwr_header_word1, tvb, offset, 4, ENC_BIG_ENDIAN);
offset +=4;
proto_tree_add_item(header_tree, hf_vwr_header_word2, tvb, offset, 4, ENC_BIG_ENDIAN);
offset +=4;
proto_tree_add_item(header_tree, hf_vwr_header_word3, tvb, offset, 4, ENC_BIG_ENDIAN);
offset +=4;
return offset;
}
static gint
dissect_data(proto_tree *tree, tvbuff_t *tvb, struct record_data *record_data)
{
proto_tree *data_tree
Re: [Wireshark-dev] Problem writing a file dissector for vwr capture files
On Sun, Aug 30, 2015 at 07:53:09AM -0400, Hadriel Kaplan wrote: Did you add the magic info into the magic_files array in wiretap/mime_file.c? It looks like it's necessary. Ah, that was the part I was missing. Thanks! Of course now that I did look at it, it doesn't help me because the file format doesn't really have a magic value. So how do I go about it properly? Thanks Jörg On Sun, Aug 30, 2015 at 4:22 AM, Joerg Mayer jma...@loplof.de wrote: I'm trying to write a file dissector for the IxVeriWave (.vwr) capture files (without loosing the ability to open said capture files normally of course) and am failing: Running tshark -X 'read_format:MIME Files Format' -V -r testfile.vwr (or the equivalent steps in wireshark) results in tshark: The file testfile.vwr isn't a capture file in a format TShark understands. Trying to just take over the complete capture file was also unsuccessful. I've attached the current source of the dissector. Simple question: What am I missing ;-) In case you want to test, use the capture attached to bug 11464. -- Joerg Mayer jma...@loplof.de We are stuck with technology when what we really want is just stuff that works. Some say that should read Microsoft instead of technology. ___ Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org Archives: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] Various problems with tshark
When using tshark from head I have a bunch of problems right now: 1) stderr is getting spammed with (process:9870): Capture-WARNING **: Dissector stp incomplete in frame 41915: undecoded byte number 57 (0x0030+9) 2) -T fields -e _ws.col.info isn't working (empty column), both with and without -V 3) Some of my .vwr captures seem to only decode in tshark (with and without -V) but don't decode with -2 or in wireshark (I'll open a proper bug for this once I have more info). Btw, how can I convert .vwr files to pcapng? Both Save and Save As are greyed out. Thanks Jörg -- Joerg Mayer jma...@loplof.de We are stuck with technology when what we really want is just stuff that works. Some say that should read Microsoft instead of technology. ___ Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org Archives: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 0af048b: Remove calls of tvb_ensure_length_remaining.
On Thu, Aug 27, 2015 at 04:34:16AM +, Wireshark code review wrote: 0af048b by Michael Mann (mman...@netscape.net): Remove calls of tvb_ensure_length_remaining. Nice! Another legacy API gone. Thanks everyone who worked on this :) Jörg -- Joerg Mayer jma...@loplof.de We are stuck with technology when what we really want is just stuff that works. Some say that should read Microsoft instead of technology. ___ Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org Archives:https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] [Bug 11461] Additional (bogus) expert items with Wireshark compared to tshark
On Sat, Aug 22, 2015 at 09:53:49AM +, bugzilla-dae...@wireshark.org wrote: https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=11461 --- Comment #4 from Alexis La Goutte alexis.lagou...@gmail.com --- the expert info is on if(tree) check ? OK, this showed me that I have yet to understand the main disection loops. I always assumed that running tshark with -2 would make the dissection behaviour of tshark and wireshark the same. This obviously isn't the case. Would someone be willing to explain the differences between wireshark, tshark and tshark -2? In case we want to be able to use tshark for regression testing, would it make sense to add a mode where it uses the same mode as wireshark? Thanks Jörg -- Joerg Mayer jma...@loplof.de We are stuck with technology when what we really want is just stuff that works. Some say that should read Microsoft instead of technology. ___ Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org Archives: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] Changing the default for ieee802.11 decryption
Hello, I just wasted some time when trying to decode ieee 802.11 wpa2 traffic: It wouldn't decode even after entering the keys. In the end it turned out that decryption is off by default and needs to be turned on seperately. IMO this violates the principle of least surprise. It should be turned on by default to make things easier for normal users and power users may still change this for their needs. Objections to me changing this? Thanks Jörg -- Joerg Mayer jma...@loplof.de We are stuck with technology when what we really want is just stuff that works. Some say that should read Microsoft instead of technology. ___ Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org Archives: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 messages I don't want to see
On Tue, Jul 14, 2015 at 11:52:18AM -0700, Guy Harris wrote:
Line 1558 of epan/crypt/airpdcap.c is
if (ctx-sa[ctx-first_free_index].used) {
in AirPDcapStoreSa(). It was assuming that ctx-first_free_index would be
within the bounds of the array, which isn't guaranteed (what if there *are*
no free indices?); I've added a bounds check in
4f1b8d74338ca2a6ded8498e9d87cbc3294454c0.
This was on Linux (which has AIRPCAP disabled) and with only 2 entries total
(1x wpa, 1x wpa2)
Thanks!
Jörg
--
Joerg Mayer jma...@loplof.de
We are stuck with technology when what we really want is just stuff that
works. Some say that should read Microsoft instead of technology.
___
Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org
Archives: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 messages I don't want to see
On Tue, Jul 14, 2015 at 09:13:49PM +0200, Joerg Mayer wrote:
On Tue, Jul 14, 2015 at 11:52:18AM -0700, Guy Harris wrote:
Line 1558 of epan/crypt/airpdcap.c is
if (ctx-sa[ctx-first_free_index].used) {
in AirPDcapStoreSa(). It was assuming that ctx-first_free_index would be
within the bounds of the array, which isn't guaranteed (what if there *are*
no free indices?); I've added a bounds check in
4f1b8d74338ca2a6ded8498e9d87cbc3294454c0.
This was on Linux (which has AIRPCAP disabled) and with only 2 entries total
(1x wpa, 1x wpa2)
With current git head all the messages are gone.
Many thanks!
Jörg
--
Joerg Mayer jma...@loplof.de
We are stuck with technology when what we really want is just stuff that
works. Some say that should read Microsoft instead of technology.
___
Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org
Archives: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] Wireshark messages I don't want to see
... but have no idea how to find or fix: jmayer@egg privat$ wireshark -r 6.pcap.gz /home/jmayer/work/wireshark/git/epan/address.h:158:5: runtime error: null pointer passed as argument 1, which is declared to never be null /home/jmayer/work/wireshark/git/epan/address.h:158:5: runtime error: null pointer passed as argument 2, which is declared to never be null /home/jmayer/work/wireshark/git/epan/crypt/airpdcap.c:1558:16: runtime error: index 256 out of bounds for type 'AIRPDCAP_SEC_ASSOCIATION [256]' FIX: Auto-size each preference pane. FIX Add drag reordering to UAT dialog FIX: Auto-size each preference pane. FIX Add drag reordering to UAT dialog FIX: Auto-size each preference pane. FIX Add drag reordering to UAT dialog git head as of 6-7 hours ago, qt only. I loaded an 802.11 trace, added a wpa2 key and looked at the result. The trace is probably confidential (will need to ask). Please let me know what information is needed to get rid of the first 3 messages in particular. Thanks Jörg -- Joerg Mayer jma...@loplof.de We are stuck with technology when what we really want is just stuff that works. Some say that should read Microsoft instead of technology. ___ Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org Archives: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] Put back closing } accidentally removed in previous commit.
On Wed, Jul 08, 2015 at 05:18:06AM +, Wireshark code review wrote: URL: https://code.wireshark.org/review/gitweb?p=wireshark.git;a=commit;h=d7f0118a74d540d3c8b07296c2c7b248ed13b464 Commits: d7f0118 by Guy Harris (g...@alum.mit.edu): Put back closing } accidentally removed in previous commit. Thanks Guy! The strange thing is, that I definitely compiled before committing (last time and this time). In this particular case, I even did a complete recompile (delete build directory, create build dir, run cmake etc) for some other reasons. Thanks Joerg -- Joerg Mayer jma...@loplof.de We are stuck with technology when what we really want is just stuff that works. Some say that should read Microsoft instead of technology. ___ Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org Archives: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 Sat, Jul 04, 2015 at 10:26:13AM +0800, Yang Luo wrote: 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:) If I remember correctly (and I may easily be mistaken here), Winpcap doesn't provide a mechanism to determine the library version at runtime. We need to make sure we know which version of wpcap we are using (wireshark/tshark -v). Thanks Joerg -- Joerg Mayer jma...@loplof.de We are stuck with technology when what we really want is just stuff that works. Some say that should read Microsoft instead of technology. ___ Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org Archives: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 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.
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.
Ciao
Joerg
--
Joerg Mayer jma...@loplof.de
We are stuck with technology when what we really want is just stuff that
works. Some say that should read Microsoft instead of technology.
___
Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org
Archives: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 Tue, Jul 07, 2015 at 09:56:24AM -0700, Guy Harris wrote: On Jul 7, 2015, at 8:56 AM, Joerg Mayer jma...@loplof.de wrote: 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? I would hope that the long term plan is to incorporate NPcap's capabilities into WinPcap, now that the WinPcap development process is being opened up. That would presumably mean that, in the long term, there's only one library, with one API. As long as that *is* the long term plan, then yes, this agrument is invalid and my objections should be ignored. Ciao Joerg -- Joerg Mayer jma...@loplof.de We are stuck with technology when what we really want is just stuff that works. Some say that should read Microsoft instead of technology. ___ Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org Archives: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] macosx-setup: XQuartz autmatic install and version
Hello (mostly) Guy, is there a reason why cmake and qt are automatically downloaded and get their installers called but not XQuartz? Also, it looks to me that the version currently configured is full of security holes, the only fixed version seems to be 2.7.8_rc1 are there known problems that cause use to use 2.7.5 instead? Thanks Joerg -- Joerg Mayer jma...@loplof.de We are stuck with technology when what we really want is just stuff that works. Some say that should read Microsoft instead of technology. ___ Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org Archives: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] asn2wrs problem
Hello, after running make in the asn1 directory, I found the generated credssp dissector changed: index d418e17..03eea46 100644 --- a/epan/dissectors/packet-credssp.c +++ b/epan/dissectors/packet-credssp.c @@ -387,7 +387,7 @@ dissect_credssp_heur(tvbuff_t *tvb, packet_info *pinfo, proto_tree *parent_tree, tags_bit_field = EXP_PDU_TAG_IP_SRC_BIT + EXP_PDU_TAG_IP_DST_BIT + EXP_PDU_TAG_SRC_PORT_BIT+ EXP_PDU_TAG_DST_PORT_BIT + EXP_PDU_TAG_ORIG_FNO_BIT; - exp_pdu_data = load_export_pdu_tags(pinfo, EXP_PDU_TAG_PROTO_NAME, credssp, tags_bit_field, 1); + exp_pdu_data = load_export_pdu_tags(pinfo, credssp, -1, tags_bit_field, 1); exp_pdu_data-tvb_captured_length = tvb_captured_length(tvb); exp_pdu_data-tvb_reported_length = tvb_reported_length(tvb); Trying to compile that version fails: [ 13%] Building C object epan/CMakeFiles/epan.dir/dissectors/packet-credssp.c.o ../../asn1/credssp/packet-credssp-template.c:115:58: error: incompatible pointer to integer conversion passing 'const char [8]' to parameter of type 'guint' (aka 'unsigned int') [-Werror,-Wint-conversion] exp_pdu_data = load_export_pdu_tags(pinfo, credssp, -1, tags_bit_field, 1); ^ /Users/jmayer/tmpwork/wireshark/git/epan/exported_pdu.h:161:78: note: passing argument to parameter 'tag_type' here WS_DLL_PUBLIC exp_pdu_data_t *load_export_pdu_tags(packet_info *pinfo, guint tag_type, const char... ^ ../../asn1/credssp/packet-credssp-template.c:115:69: error: incompatible integer to pointer conversion passing 'int' to parameter of type 'const char *' [-Werror,-Wint-conversion] exp_pdu_data = load_export_pdu_tags(pinfo, credssp, -1, tags_bit_field, 1); ^~ /Users/jmayer/tmpwork/wireshark/git/epan/exported_pdu.h:161:100: note: passing argument to parameter 'proto_name' here ...exp_pdu_data_t *load_export_pdu_tags(packet_info *pinfo, guint tag_type, const char* proto_name, ^ 2 errors generated. Any ideas what is going on here? Thanks Jörg -- Joerg Mayer jma...@loplof.de We are stuck with technology when what we really want is just stuff that works. Some say that should read Microsoft instead of technology. ___ Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org Archives: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] Autogenerated files in source tree [Was: asn2wrs problem]
On Thu, Jun 25, 2015 at 02:24:05PM -0700, Pascal Quantin wrote: Yeah that's my fault: I did some API change yesterday and did not realize that CREDSSP was an autogenerated dissector. I will fix this in a few minutes. OK, which brings me back to the topic that we should have as few autogenerated dissectors in our source tree as possible. I don't think the additional compile time qualifies as a counter argument, and phython is required to build Wireshark as well. So why keep doing that? If it's OK, I'd like to do a PoC patch for asn1. For those instances where we want to keep the generated dissectors in the source tree: Is there a way to prevent accidental changes (i.e. opening the file not at the top but at a given line or automated search/replace scripts? Does setting these files to read only look like a possible solution? Sorry about that, No problem - I was just testing the new old cmake asn1 generation and it gave me the opportunity to once again start this discussion ;-) -- Joerg Mayer jma...@loplof.de We are stuck with technology when what we really want is just stuff that works. Some say that should read Microsoft instead of technology. ___ Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org Archives: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] QT Hexpane initially grey
Hello, on my systemi(*), the hex pane is not shown, instead just the grey background is visible. The first incoming packet will cause the hex pane to show. The two other panes are fine. * Git head, Layout 2 Ciao Jörg PS: It's nice to have reached a stage where it's worth reporting this type of problems :-) -- Joerg Mayer jma...@loplof.de We are stuck with technology when what we really want is just stuff that works. Some say that should read Microsoft instead of technology. ___ Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org Archives: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] RfD: How to handle libnghttp2 [Was: libnghttp2 checkin broken]
On Sun, May 03, 2015 at 12:03:48PM +0200, Alexis La Goutte wrote: While we are at the (sub-)topic of libnghttp: Now that the protocol is finalized, should we still import the source into our source or treat it like we treat (most) other external libs: Just check for its availability and use iot if present? Yes, the protocol is finalized but the lib is not available on all distribution... and specially on Windows and Mac OS X... (no packages available) Well, that is likely to change at least at the Linux side. On OS X and Windows we do provide setup scripts for that kind of stuff already - and that way we do not need to care about maintaining the code in tree. Ciao Jörg -- Joerg Mayer jma...@loplof.de We are stuck with technology when what we really want is just stuff that works. Some say that should read Microsoft instead of technology. ___ Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org Archives: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] RfD: How to handle libnghttp2 [Was: libnghttp2 checkin broken]
On Sat, May 02, 2015 at 10:01:25AM +0200, Alexis La Goutte wrote: The fundamental problem (at least with the checkAPIs portion of the hook) is that some files/directories have different rules than others. Currently that intelligence is built into the Makefiles which isn't really available to the hook. A Better Way would be to build that intelligence into checkAPIs, maybe with a configuration file in each directory. Patches are welcome :-) OK, I see your point. If nobody beats me to it, I will look into this after my holidy. Btw.: Many of the things that checkAPI (without extra options) Errors about should be fixed in any case. While we are at the (sub-)topic of libnghttp: Now that the protocol is finalized, should we still import the source into our source or treat it like we treat (most) other external libs: Just check for its availability and use it if present? Ciao Jörg -- Joerg Mayer jma...@loplof.de We are stuck with technology when what we really want is just stuff that works. Some say that should read Microsoft instead of technology. ___ Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org Archives: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 libnghttp2 checkin broken
Hello Alexis, On Fri, May 01, 2015 at 03:23:37PM +0200, Alexis La Goutte wrote: On Fri, May 1, 2015 at 2:17 PM, Joerg Mayer jma...@loplof.de wrote: On Fri, May 01, 2015 at 10:42:01AM +0200, Alexis La Goutte wrote: On Fri, May 1, 2015 at 1:46 AM, Joerg Mayer jma...@loplof.de wrote: The latest checkin to libnghttp2 should not have happend: a) it breaks compilation on my system /home/jmayer/work/wireshark/git/epan/nghttp2/nghttp2_hd.c: In function ‘hd_inflate_remove_bufs_with_name’: /home/jmayer/work/wireshark/git/epan/nghttp2/nghttp2_hd.c:1736:10: error: variable ‘rv’ set but not used [-Werror=unused-but-set-variable] size_t rv; ^ What compile and release do you using ? I have found and fixed the problem: I did a non-debug build (see commit f708c5cb56135515b6b777f144e90d488870c470) So we would probably need at least one buildbot to build with NDEBUG set to catch this. What is a NDEGUG build ? Because, i will push the patch to the upstream A build without debugging code, i.e. assert(stuff) evaluates to nothing. Call it a release build if you want. b) it can only have been committed with --no-verify as it contains deprecated functions (checkAPI.pl). I hit this during conflict resolution (git commit). pre-commit tools is no perfect... it is for help when commit code and there is some false postive... Please verify on your system and let me know the results. Here's the result on mine: jmayer@egg nghttp2(master)$ ../../tools/checkAPIs.pl * Error: Found prohibited APIs in nghttp2_helper.c: ntohl,ntohs,htonl,htons Error: Found prohibited APIs in nghttp2_mem.c: malloc,calloc,realloc,free Error: Found prohibited APIs in nghttp2_net.h: ntohl,ntohs,htonl,htons For me checkAPIs is only for dissectors file You have the same type of warning on wiretap folder : wireshark/wiretap$ ../tools/checkAPIs.pl * Error: Found prohibited APIs in ascend.c: malloc,free Error: Found prohibited APIs in ascend_scanner.c: malloc,realloc,free Error: Found prohibited APIs in k12text.c: malloc,realloc,free No, I don't, because I do out of tree builds and all of these are generated file ;-) What I don't understand is, that if you have the pre-commit hook installed, you should never have been able to commit these files. I hit the problem when I did a git commit -a during merge conflict resolution. We currently have one file that I know of that validly fails the pre-commit script, and that is doc/packet-PROTOABBREV.c. I'm not aware of any other file (that gets checked into the repo) that should be allowed to fail the pre-commit hook. Ciao Jörg -- Joerg Mayer jma...@loplof.de We are stuck with technology when what we really want is just stuff that works. Some say that should read Microsoft instead of technology. ___ Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org Archives: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] Removing ADNS
On Mon, Mar 02, 2015 at 11:16:00AM -0800, Gerald Combs wrote: Does anyone link Wireshark with GNU ADNS? If not I'd like to drop support for it in master. The current version (1.5.0) switched licenses from GPLv2+ to GPLv3+ and prior versions don't support IPv6. IIRC c-ares has been the preferred lib for doing this for a long time now, so I don't mind killing off adns completely. Less #ifdef stuff in the source as well :-) +1 Ciao Jörg -- Joerg Mayer jma...@loplof.de We are stuck with technology when what we really want is just stuff that works. Some say that should read Microsoft instead of technology. ___ Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org Archives: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] Use Transifex for manage Translations
On Thu, Mar 05, 2015 at 10:15:14AM +0100, Alexis La Goutte wrote: On Thu, Mar 5, 2015 at 10:06 AM, Dario Lombardo dario.lombardo...@gmail.com wrote: How does the transfer into gerrit works? Is there a dummy account that commits and merges automatically? What about credits for contributions? Are they trasferred in some way from tx to git? Yes Dummy account... (for the moment, it is my account...) No yet found how add credit for translation contributions... Please find a way to fix this at least for the AUTHORS file before the official release. If necessary it needs to be done manually. Adding it to the git commits would be a very nice to have. Ciao Jörg -- Joerg Mayer jma...@loplof.de We are stuck with technology when what we really want is just stuff that works. Some say that should read Microsoft instead of technology. ___ Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org Archives: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] Make CMake reuse Makefile.common?
On Fri, Mar 06, 2015 at 03:43:04PM +, Graham Bloice wrote: 1 slide : Call Jörg https://code.wireshark.org/review/#/q/owner:%22J%25C3%25B6rg+Mayer%22+status:merged,n,z Lol I noticed many cmake commits that don't do things in what I consider the clean or proper cmake way, but I was too worn out to really care. That is very likely to change once I'm back from my holiday (two weeks, starting this Sunday ;) Ciao Jörg -- Joerg Mayer jma...@loplof.de We are stuck with technology when what we really want is just stuff that works. Some say that should read Microsoft instead of technology. ___ Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org Archives: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] Use Transifex for manage Translations
On Fri, May 01, 2015 at 12:56:38PM +0200, Alexis La Goutte wrote: I have a plan to remove AUTHORS and generate by git (Search on list or Gerrit for more detail...) Yeah, I remember reading that. I'm not completely happy with that, but only for ego reasons (it's nice to find your name in the list without scrolling ;- Adding it to the git commits would be a very nice to have. It is no possible to get info about author with Transifex You can only add a link to Wireshark Team Transifex page https://www.transifex.com/organization/wireshark/team/36457/ When I call that page, I only get: Page not found Also: While unfortunate, then you (or whoever does the import) would probably need to update the stuff manually - I regard this (no proper attibution) as a showstopper for using transifex. Ciao Jörg -- Joerg Mayer jma...@loplof.de We are stuck with technology when what we really want is just stuff that works. Some say that should read Microsoft instead of technology. ___ Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org Archives: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 libnghttp2 checkin broken
On Fri, May 01, 2015 at 10:42:01AM +0200, Alexis La Goutte wrote: On Fri, May 1, 2015 at 1:46 AM, Joerg Mayer jma...@loplof.de wrote: The latest checkin to libnghttp2 should not have happend: a) it breaks compilation on my system /home/jmayer/work/wireshark/git/epan/nghttp2/nghttp2_hd.c: In function ‘hd_inflate_remove_bufs_with_name’: /home/jmayer/work/wireshark/git/epan/nghttp2/nghttp2_hd.c:1736:10: error: variable ‘rv’ set but not used [-Werror=unused-but-set-variable] size_t rv; ^ What compile and release do you using ? I have found and fixed the problem: I did a non-debug build (see commit f708c5cb56135515b6b777f144e90d488870c470) So we would probably need at least one buildbot to build with NDEBUG set to catch this. b) it can only have been committed with --no-verify as it contains deprecated functions (checkAPI.pl). I hit this during conflict resolution (git commit). pre-commit tools is no perfect... it is for help when commit code and there is some false postive... Please verify on your system and let me know the results. Here's the result on mine: jmayer@egg nghttp2(master)$ ../../tools/checkAPIs.pl * Error: Found prohibited APIs in nghttp2_helper.c: ntohl,ntohs,htonl,htons Error: Found prohibited APIs in nghttp2_mem.c: malloc,calloc,realloc,free Error: Found prohibited APIs in nghttp2_net.h: ntohl,ntohs,htonl,htons Ciao Jörg -- Joerg Mayer jma...@loplof.de We are stuck with technology when what we really want is just stuff that works. Some say that should read Microsoft instead of technology. ___ Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org Archives: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] Wireshark runtime messages we don't want to see
jmayer@egg epan$ wireshark QMetaObject::connectSlotsByName: No matching signal for on_actionExternalMenuItem_triggered() ../../asn1/c1222/packet-c1222-template.c:1427:3: runtime error: null pointer passed as argument 1, which is declared to never be null ../../asn1/c1222/packet-c1222-template.c:1427:3: runtime error: null pointer passed as argument 2, which is declared to never be null 18:37:43 Dbg plugin_dir: /opt/test/lib/wireshark/plugins/1.99.6 ERROR: Cannot connect to ADB: Connection refused INFO: Please check that adb daemon is running. == after double clicking the wlan0 interface /home/jmayer/work/wireshark/git/wsutil/sign_ext.h:53:33: runtime error: left shift of negative value -1 /home/jmayer/work/wireshark/git/epan/proto.c:9154:47: runtime error: left shift of 1 by 31 places cannot be represented in type 'int' ___ 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 runtime messages we don't want to see
On Thu, Apr 30, 2015 at 01:44:41PM -0700, Guy Harris wrote: On Apr 30, 2015, at 9:58 AM, Joerg Mayer jma...@loplof.de wrote: jmayer@egg epan$ wireshark ../../asn1/c1222/packet-c1222-template.c:1427:3: runtime error: null pointer passed as argument 1, which is declared to never be null ../../asn1/c1222/packet-c1222-template.c:1427:3: runtime error: null pointer passed as argument 2, which is declared to never be null That probably means that oid_string2encoded() failed. Pascal Quantin's working on a fix for this: https://code.wireshark.org/review/8251 but presumably the failure means either that 1) you specified an invalid (not a syntactically-valid OID) setting for the Base OID to use for relative OIDs preference for the C.1222 dissector or 2) you have no setting for it so that the string is null (which is, as far as I know, not a syntactically-valid OID) and I strongly suspect it's 2) here, so perhaps that code should also special-case null strings. (Ultimately, we should catch syntactically-invalid OIDs rather than just silently ignoring them.) Yes, it's case 2) Hopefully, the code also can handle a missing OID. Ciao Jörg -- Joerg Mayer jma...@loplof.de We are stuck with technology when what we really want is just stuff that works. Some say that should read Microsoft instead of technology. ___ Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org Archives: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 runtime messages we don't want to see
On Thu, Apr 30, 2015 at 01:08:59PM -0700, Guy Harris wrote:
On Apr 30, 2015, at 1:00 PM, Roland Knall rkn...@gmail.com wrote:
On Thu, Apr 30, 2015 at 6:58 PM, Joerg Mayer jma...@loplof.de wrote:
ERROR: Cannot connect to ADB: Connection refused
INFO: Please check that adb daemon is running.
Do not know about the others, but
ERROR: Cannot connect to ADB: Connection refused
INFO: Please check that adb daemon is running.
is the new androiddump extcap utility, and I think it should be ok, that
this message is printed, as it is an external tool, not Wireshark itself.
Is it run whenever you start Wireshark, even if you don't have any Android
development tools installed?
Correct. I don't have any Android development environment installed and it
appears all
the time.
If not, is it still run even if you don't happen to be debugging an Android
device at the time?
It should perhaps try to distinguish, if possible, between failure to
connect to ADB when you're actually debugging an Android device and failure
to connect to ADB because {you're not using any Android development tools
right now, you don't even have Android development tools installed, you don't
have any Android devices on which to develop, etc.}.
Ciao
Jörg
--
Joerg Mayer jma...@loplof.de
We are stuck with technology when what we really want is just stuff that
works. Some say that should read Microsoft instead of technology.
___
Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org
Archives: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] Latest libnghttp2 checkin broken
The latest checkin to libnghttp2 should not have happend: a) it breaks compilation on my system /home/jmayer/work/wireshark/git/epan/nghttp2/nghttp2_hd.c: In function ‘hd_inflate_remove_bufs_with_name’: /home/jmayer/work/wireshark/git/epan/nghttp2/nghttp2_hd.c:1736:10: error: variable ‘rv’ set but not used [-Werror=unused-but-set-variable] size_t rv; ^ and b) it can only have been committed with --no-verify as it contains deprecated functions (checkAPI.pl). I hit this during conflict resolution (git commit). Either we should remove the lib from the Wireshark source (an inconvenience as most distros don't provide packages for this) or the code needs to conform to Wireshark's development environment, i.e. it requires adaption and stricter testing than what seems to be happening right now. Ciao Jörg -- Joerg Mayer jma...@loplof.de We are stuck with technology when what we really want is just stuff that works. Some say that should read Microsoft instead of technology. ___ Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org Archives: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 4e68f01: Fix: packet-bitcoin.c:1735:6: error: 'hfi_msg_getheaders_version' undeclared (first use in this function) hfi_msg_getheaders_version,
On Fri, Apr 03, 2015 at 12:17:32AM +, Wireshark code review wrote: 4e68f01 by Joerg Mayer (jma...@loplof.de): Fix: packet-bitcoin.c:1735:6: error: 'hfi_msg_getheaders_version' undeclared (first use in this function) hfi_msg_getheaders_version, caused by previous commit. Weird that the compiler on my system didn't catch that. Change-Id: I73cb06553bdf3a37f7c3d61d85f425d7c92d5b99 Reviewed-on: https://code.wireshark.org/review/7888 Reviewed-by: Jörg Mayer jma...@loplof.de OK, not so weird once I remembered that I run cmake with -DHAVE_HFI_SECTION_INIT=ON Ciao Jörg -- Joerg Mayer jma...@loplof.de We are stuck with technology when what we really want is just stuff that works. Some say that should read Microsoft instead of technology. ___ Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org Archives: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] WS runtime error
When starting Wireshark with a specific trace file (unfortunately confidential), I get the following message on startup (git head): /home/jmayer/work/wireshark/git/ui/qt/packet_list.cpp:537:13: runtime error: load of value 9, which is not a valid value for type 'bool' Does this provide enough information? If not, what should I do to track down the cause of this? Thanks Jörg -- Joerg Mayer jma...@loplof.de We are stuck with technology when what we really want is just stuff that works. Some say that should read Microsoft instead of technology. ___ Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] Custom cmake files
Hello Anders, On Wed, Jan 28, 2015 at 09:50:27AM +, Anders Broman wrote: Commit https://code.wireshark.org/review/gitweb?p=wireshark.git;a=commitdiff;h=3b46e6eaf61a29f9bd8f8c162caa54cc2ea81fe2 is causing me problems. Are you opposed to changing back the file name to CMakeListsCustom.txthttps://code.wireshark.org/review/gitweb?p=wireshark.git;a=blob;f=epan/CMakeListsCustom.txt;h=d1f41d62ab11221332d26a56a04b470426de65ab;hb=84629f43cb6c19ca2e0e512ac2429584925be896 ? That makes it easy to have the files included in a tarball and makes it possible for me to Use the same file names in my custom build as in the standard one. I do not want to carry changes to standard files if it can be avoided. As it stands I would have To have my own Makefile.am or add some sort of hack to it. I think it would be much cleaner just changing the file names back. I'm not sure I understand what you are asking: If you want to rename the CMakeListsCustom.txt.example back to CMakeListsCustom.txt then yes, I'm really opposed to it, because in that case I don't see any advantage in modifying the ...Custom... file instead of changing the original CMakeLists.txt file. My motivation for this change was to avoid haing a modified *checked* in file in my source tree while doing dissector development. How about adding a variable in the custom file that allows additional files to be pickt up for packaging? Ciao Jörg -- Joerg Mayer jma...@loplof.de We are stuck with technology when what we really want is just stuff that works. Some say that should read Microsoft instead of technology. ___ Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] QT with cmake
On Tue, Oct 21, 2014 at 03:13:01PM +0200, Dario Lombardo wrote: On Tue, Oct 21, 2014 at 2:48 PM, Peter Wu pe...@lekensteyn.nl wrote: Have you tried to clear your build dir? The QtGui/QAction file is located in the qt4 include directory, in qt5 it is located at QtWidgets/QAction. I've completely deleted the build dir and started over. Same output. [ 79%] Building CXX object ui/qt/CMakeFiles/qtui.dir/about_dialog.cpp.o In file included from /home/dario/Projects/wireshark/ui/qt/about_dialog.cpp:25:0: /home/dario/Projects/wireshark/ui/qt/ui_about_dialog.h:13:25: fatal error: QtGui/QAction: No such file or directory #include QtGui/QAction Weird. Where does this include come from? I can't find it in any file. Hmm, OK, it's in a generated file and most probably generated for Qt4. So maybe it is not properly picking up the qt5 tools (uic) but using the qt4 version instead? Or there is a leftover. The path looks like the file ui_about_dialog.h is in tree, not out of tree, but that's for you to confirm or deny. Ciao Jörg -- Joerg Mayer jma...@loplof.de We are stuck with technology when what we really want is just stuff that works. Some say that should read Microsoft instead of technology. ___ Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] Gerrit patches with trailing whitespace
On Mon, Aug 25, 2014 at 06:06:15PM +0100, Graham Bloice wrote: When reviewing some submissions on Gerrit, I've noted a few with trailing whitespace. The git pre-commit hook always warns me of this, so how are folks managing to do this? Are they using clients that ignore the hook? How about adding a test to our build systems: If we are part of a git repo and .git/hooks/pre-commit doesn't exist then print a message at the end of the build that in case of an intended submission the file should be installed first. Ciao Jörg -- Joerg Mayer jma...@loplof.de We are stuck with technology when what we really want is just stuff that works. Some say that should read Microsoft instead of technology. ___ Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] Qt License Change
On Thu, Aug 21, 2014 at 02:30:49PM +0100, Tyson Key wrote: I'm not a lawyer - but judging by that post, and the statements ...we are now adding LGPL v3 as a licensing option to Qt 5.4 in addition to LGPL v2.1, and All modules that existed in Qt 5.3 will still be available under LGPL v2.1. So if you are using Qt under the GPL v2 or LGPL v2.1, nothing changes as long as you don’t use any of the new modules that are only available under LGPL v3, we should be OK, as long as we're careful about using some of the New Shiny(TM) stuff in 5.4. That said, to be honest, I can't see us moving the UI to Qt Quick; or using WebGL, or the new HTML renderer, any time soon, anyway... I noticed the license change as well and came to the same conclusion as Tyson: We are *not* affected as one of the QT licenses is (and will remain) the GPLv2 (but that's easy to miss in the announcement). LGPLv2.1 may go away for some components, but we don't have to care about that as we are GPLv2. Ciao Jörg -- Joerg Mayer jma...@loplof.de We are stuck with technology when what we really want is just stuff that works. Some say that should read Microsoft instead of technology. ___ Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] building a Gtk2 RPM (Was: QT_MIN_VERSION)
On Tue, Aug 12, 2014 at 10:51:06PM +, Christopher Maynard wrote: Jeff Morriss jeff.morriss.ws@... writes: That's odd; I just tried it (starting from the wireshark-1.12.0 source tarball[1]) and did not have any problems. I wonder if your wireshark.spec file isn't being regenerated (from wireshark.spec.in)? You could try comparing the two or just remove wireshark.spec to force it to be built again. [1] cd /tmp tar xjf /path/to/wireshark-1.12.0.tar.bz2 cd wireshark-1.12.0 ./configure --with-gtk2 make rpm-package Thanks for retesting. The wireshark.spec file was definitely being regenerated. I noticed above that you did not run ./autogen.sh. I tried once again, this time *without* running autogen.sh just as you've shown, but unfortunately the results were the same. I don't know, for now I'll just build --with-qt I guess. Just tried this against git head on opensuse13.1, it worked fine. jmayer@egg:~/work/wireshark/build/rpm-gtk2 ../../git/configure --with-gtk2 jmayer@egg:~/work/wireshark/build/rpm-gtk2 make rpm-package Ciao Jörg -- Joerg Mayer jma...@loplof.de We are stuck with technology when what we really want is just stuff that works. Some say that should read Microsoft instead of technology. ___ Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] Can we now assume IPv6 support on all target OSes?
On Sun, Aug 03, 2014 at 11:20:08AM -0700, Guy Harris wrote: Currently, there are a few bits of code in Wireshark that check, at compile time, whether INET6 is defined. For Windows nmake builds, we appear to hard-wire INET6 to be defined; the user would have to edit config.nmake to turn it off. For autotools builds, we go through a long series of tests for various flavors of IPv6 support. For CMake builds, we appear to hard-wire INET6 to be defined. Is there any reason to continue to try to handle OSes with no IPv6 support, or should we just get rid of the INET6 #define and unconditionally include the code that it currently controls? IIRC we talked about that some time ago (or maybe I just wanted to do that ;) IMO we should set it to always defined for now and restore detection in case of (valid) complaints. I don't yet count the fact that I haven't seen any cmake complaints about this. If no complaints come along we should remove the precompiler stuff on about 3-4 months. Ciao Jörg -- Joerg Mayer jma...@loplof.de We are stuck with technology when what we really want is just stuff that works. Some say that should read Microsoft instead of technology. ___ Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] [Wireshark-commits] master 53957d8: Go back to non-verbose Makefiles.
On Mon, Aug 04, 2014 at 01:53:13AM -0700, Guy Harris wrote: On Aug 4, 2014, at 1:43 AM, Joerg Mayer jma...@loplof.de wrote: There is no need to change CMakeLists.txt for this kind of stuff: Just use make VERBOSE=1. Gerald, on what machine would I need to have an account in order to change the buildbot to do that, and do I have such an account? (If the answer is no, then there *is* a need, at least for me, to change CMakeLists.txt for that kind of stuff) (And, no, I'm not asking for such an account, given that I can get verbose builds, when necessary, by changing CMakeLists.txt.) Ah, OK, so I wasn't too far off with my idea that you might have a reason for that ;) So either it's setting these flags or using petri dish to do the platform testing. @Gerald: Which reminds me: Are the scripts for the windows buildbots available somewhere? If so, I could create a modified version that will (optionally) replace the nmake build by the (more or less) equivalent cmake + msbuild steps. That way we could test cmake windows builds as well. Ciao Jörg -- Joerg Mayer jma...@loplof.de We are stuck with technology when what we really want is just stuff that works. Some say that should read Microsoft instead of technology. ___ Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] How to support wireshark w/o having an OpenID
On Mon, Aug 04, 2014 at 05:25:29PM +0200, Toralf Förster wrote: I developer pointed me to http://code.wireshark.org/review - but I do not have an OpenID nor I have an account listed here : http://openid.net/get-an-openid/ And I do not own a home page. Any chance to participate in WS under this circumstances ? P.S.: I'm not subscribed, please Cc: me. I ended up using launchpad. It's been a rather time consuming thing but now it's working and once cmake has become the universal build system for Wireshark I'm going to set up my own openid provider and get Gerald to add it to the list ;-) Ciao Jörg -- Joerg Mayer jma...@loplof.de We are stuck with technology when what we really want is just stuff that works. Some say that should read Microsoft instead of technology. ___ Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] Wireshark Qt : Decode As
If someone starts to work on the Decode As stuff for qtshark: Can you please give me the same command line options as with tshark? The need to in some cases click half a dozen decode as dialogs and repeat that on the next capture again has annoyed me quite a few times with gtkshark. Thanks Jörg On Mon, Aug 04, 2014 at 03:33:29PM -0700, Guy Harris wrote: On Aug 4, 2014, at 1:13 PM, Alexis La Goutte alexis.lagou...@gmail.com wrote: The decode As feature work for you with Wireshark Qt (qtshark) I have try on Windows, Linux, Mac OS X and don't work for me... (the value is never save...) Isn't saved, as in isn't written to the decode_as_entries file, or is saved but doesn't work? if i try with GTK and reopen with Qt works... For uint dissector tables, GTK+ was writing out the value in decimal, regardless of the base of the value for the table; Qt was writing it out in hex if the base for the value was hex. The code to *read* the tables assumed decimal, and read a hex value as 0, because it was using atoi(). I fixed it to use strtol() with a base argument of 0 (so that a number beginning with 0x or 0X is treated as hex), and to check that that the string was a valid number and the value was in the range 0 - UINT_MAX and report lines where it isn't. This fixes it to the extent that the saved values work; I backported that fix to the 1.12 branch. However, if I change it in Qt, the change doesn't take effect until I quit and restart Wireshark, so there's another bug hiding there. ___ 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 -- Joerg Mayer jma...@loplof.de We are stuck with technology when what we really want is just stuff that works. Some say that should read Microsoft instead of technology. ___ Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] [Wireshark-commits] master 8b2a8a9: Suppress 10 of the CMP0020 CMake warnings on Windows, only 8 left now.
On Tue, Aug 05, 2014 at 12:33:30PM +, Wireshark code review wrote: 8b2a8a9 by Graham Bloice (graham.blo...@trihedral.com): Suppress 10 of the CMP0020 CMake warnings on Windows, only 8 left now. I had so hoped you would find out why moving the policy makes a difference. Now I have to do this myself ;) Ciao Jörg -- Joerg Mayer jma...@loplof.de We are stuck with technology when what we really want is just stuff that works. Some say that should read Microsoft instead of technology. ___ Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] [Wireshark-commits] master 53957d8: Go back to non-verbose Makefiles.
There is no need to change CMakeLists.txt for this kind of stuff: Just use make VERBOSE=1. That's how I do my builds to be always verbose although the default is non-verbose. In case you are using another make system then I don't know how to achieve that. Ciao Jörg On Sun, Aug 03, 2014 at 06:30:29PM +, Wireshark code review wrote: URL: https://code.wireshark.org/review/gitweb?p=wireshark.git;a=commit;h=53957d846c6831e943b70db5ae79bc750bf7397f Submitter: Guy Harris (g...@alum.mit.edu) Changed: branch: master Repository: wireshark Commits: 53957d8 by Guy Harris (g...@alum.mit.edu): Go back to non-verbose Makefiles. (The difference in question turned out to be that optimization wasn't turned on for autotools builds but was turned on for CMake builds. Comparing the compiler options also found some other differences that should be cleaned up.) Change-Id: I2edb28dedc47fe10b3f68f25d3e302430b27bf46 Reviewed-on: https://code.wireshark.org/review/3386 Reviewed-by: Guy Harris g...@alum.mit.edu Actions performed: from 3da89d6 Add missing macro parameter adds 53957d8 Go back to non-verbose Makefiles. Summary of changes: CMakeLists.txt |7 --- 1 file changed, 7 deletions(-) ___ Sent via:Wireshark-commits mailing list wireshark-comm...@wireshark.org Archives:http://www.wireshark.org/lists/wireshark-commits Unsubscribe: https://wireshark.org/mailman/options/wireshark-commits mailto:wireshark-commits-requ...@wireshark.org?subject=unsubscribe -- Joerg Mayer jma...@loplof.de We are stuck with technology when what we really want is just stuff that works. Some say that should read Microsoft instead of technology. ___ Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] Change in wireshark[master]: Fix another (valid) complaint from the mac buildbot
Could we get back so somewhat more readable commit messages please? thanks Jörg On Sat, Aug 02, 2014 at 02:13:59AM +, Evan Huus (Code Review) wrote: Evan Huus has uploaded a new change for review. https://code.wireshark.org/review/3347 Change subject: Fix another (valid) complaint from the mac buildbot .. Fix another (valid) complaint from the mac buildbot What mystical new compiler upgrade is this? Change-Id: I89b3bfb53b9a19bbfb1cc8339d38cdc4a4652c62 --- M epan/dissectors/packet-bgp.c 1 file changed, 1 insertion(+), 1 deletion(-) git pull ssh://code.wireshark.org:29418/wireshark refs/changes/47/3347/1 -- To view, visit https://code.wireshark.org/review/3347 To unsubscribe, visit https://code.wireshark.org/review/settings Gerrit-MessageType: newchange Gerrit-Change-Id: I89b3bfb53b9a19bbfb1cc8339d38cdc4a4652c62 Gerrit-PatchSet: 1 Gerrit-Project: wireshark Gerrit-Branch: master Gerrit-Owner: Evan Huus eapa...@gmail.com -- Joerg Mayer jma...@loplof.de We are stuck with technology when what we really want is just stuff that works. Some say that should read Microsoft instead of technology. ___ Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] [Wireshark-announce] Wireshark 1.12.0rc3 is now available
On Thu, Jul 31, 2014 at 12:34:18PM +0200, Peter Wu wrote: Another thing to consider is the availability of cmake which does not require additional files in a distribution tarball like autotools. If all platforms support cmake, what about dropping the autotools-generated stuff? Oh no! Now you have uncovered my evil masterplan - and you know what happens to evil master plans once they are revealed? :-) Jörg -- Joerg Mayer jma...@loplof.de We are stuck with technology when what we really want is just stuff that works. Some say that should read Microsoft instead of technology. ___ Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] [Wireshark-commits] master 43a81b6: Add some information on running from the build directory.
On Thu, Jul 31, 2014 at 08:56:31PM +, Wireshark code review wrote: URL: https://code.wireshark.org/review/gitweb?p=wireshark.git;a=commit;h=43a81b61395358d93a3f859e9058dfd7ecc39a7e Submitter: Guy Harris (g...@alum.mit.edu) Changed: branch: master Repository: wireshark Commits: 43a81b6 by Guy Harris (g...@alum.mit.edu): Add some information on running from the build directory. Change-Id: I6c01141cd02af358152d007175ec0b51357e42b3 Reviewed-on: https://code.wireshark.org/review/3298 Reviewed-by: Guy Harris g...@alum.mit.edu If I understand cmake correctly - and that's a big if - it will build the code to be run from the build environment. Make install will relink the code to run from the install environment. Ciao Jörg -- Joerg Mayer jma...@loplof.de We are stuck with technology when what we really want is just stuff that works. Some say that should read Microsoft instead of technology. ___ Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] [Wireshark-commits] master 43a81b6: Add some information on running from the build directory.
On Thu, Jul 31, 2014 at 05:11:59PM -0400, Evan Huus wrote:
This issue has been bugging me for a while, but I also haven't been able to
come up with a satisfactory solution.
I hope to look into this soon ('ish)
Ciao
Jörg
--
Joerg Mayer jma...@loplof.de
We are stuck with technology when what we really want is just stuff that
works. Some say that should read Microsoft instead of technology.
___
Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org
Archives:http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
[Wireshark-dev] Compile error in tap-iousers.c
[ 81%] Building C object CMakeFiles/tfshark.dir/ui/cli/tap-iousers.c.o /home/jmayer/work/wireshark/git/ui/cli/tap-iousers.c: In function ‘iousers_draw’: /home/jmayer/work/wireshark/git/ui/cli/tap-iousers.c:106:5: error: format ‘%d’ expects argument of type ‘int’, but argument 4 has type ‘guint64’ [-Werror=format=] ); ^ /home/jmayer/work/wireshark/git/ui/cli/tap-iousers.c:106:5: error: format ‘%d’ expects argument of type ‘int’, but argument 6 has type ‘guint64’ [-Werror=format=] /home/jmayer/work/wireshark/git/ui/cli/tap-iousers.c:106:5: error: format ‘%d’ expects argument of type ‘int’, but argument 8 has type ‘guint64’ [-Werror=format=] cc1: all warnings being treated as errors -- Joerg Mayer jma...@loplof.de We are stuck with technology when what we really want is just stuff that works. Some say that should read Microsoft instead of technology. ___ Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] [Wireshark-commits] master 31ecdf5: Refactor common Conversation table functionality.
On Mon, Jul 28, 2014 at 06:17:37PM -0400, Jeff Morriss wrote: On 07/26/14 16:59, Wireshark code review wrote: URL: https://code.wireshark.org/review/gitweb?p=wireshark.git;a=commit;h=31ecdf5b06bff3bb2e706e840c28c519698e6f67 Submitter: Gerald Combs (ger...@wireshark.org) Changed: branch: master Repository: wireshark Commits: 31ecdf5 by Michael Mann (mman...@netscape.net): Refactor common Conversation table functionality. Refactor (non-GUI) conversation table functionality from gtk/Qt to epan. Also refactor common GUI conversation table functionality. The idea is to not have to modify the GUI when a dissector adds a new conversation type Wow, nice work! +2 -- Joerg Mayer jma...@loplof.de We are stuck with technology when what we really want is just stuff that works. Some say that should read Microsoft instead of technology. ___ Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] Change in wireshark[master]: Skip the NCP dissector when building on Windows without Python
Does it really make sense to allow Windows builds without python installed? IMO we should by now require python to be present to be able to build on Windows (or any other plattform). Ciao Jörg PS: In my opinion this is one of the cases which need to be discussed on this list - too many *relevant* things ngs are gerrit only these days. -- Joerg Mayer jma...@loplof.de We are stuck with technology when what we really want is just stuff that works. Some say that should read Microsoft instead of technology. ___ Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] Difference between Autofoo and CMake build ?
On Thu, Jul 24, 2014 at 11:58:51AM -0400, Bill Meier wrote: While reviewing the new ceph dissector [1], two issues cropped up where my build on Linux (using Autofoo) apparently gave different results then a build by Kevin Cox (the submitter of the new dissector) using CMake on Linux. He used GCC 4.9.1 and CMake while I used GCC 4.9.0 and Autofoo. 1. The Autofoo compile indicated an unused but set variable The CMake apparently did not. Should not be: I do (or at least did) get these messages regularly with CMake. Different CFlags ? As the order of flags in both files is rather random I did a bit of grepping, sorting and some manual editing. It looks like the flags should be the same. 2. The ceph dissector had several value_string_ext structs defined as 'static const ...'. The Wireshark built with CMake worked AOK when the ceph dissector used the extended value strings for the first time (i.e., no exceptions). The Wireshark built with Autofoo trapped when the extended value string structs were used for the first time (when there was an attempt to write to the struct). IOW: In one case, the structs were apparently not in a r/o section while in the other they apparently were. I've no idea if this difference has anything to do with CMake vs Autofoo. Thoughts ? Not on first sight. Maybe you can do a comparison on your system where all the other tools are identical? Ciao Jörg -- Joerg Mayer jma...@loplof.de We are stuck with technology when what we really want is just stuff that works. Some say that should read Microsoft instead of technology. ___ Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
[Wireshark-dev] Oldest version of VS supported?
IIRC there was some discussion which versions of VS should still be supported, but I failed to find it in the archives. So, was there some consensus which is the oldest version we are going to support with master? Thanks Jörg -- Joerg Mayer jma...@loplof.de We are stuck with technology when what we really want is just stuff that works. Some say that should read Microsoft instead of technology. ___ Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] Oldest version of VS supported?
On Thu, Jul 24, 2014 at 06:20:48PM +0100, Graham Bloice wrote: On 24 July 2014 18:08, Joerg Mayer jma...@loplof.de wrote: IIRC there was some discussion which versions of VS should still be supported, but I failed to find it in the archives. So, was there some consensus which is the oldest version we are going to support with master? I brought up the issue of moving to VS2013 for master, and separately dropping info from the (master) docs for earlier than VS2010. I didn't see any requests for support to build with earlier than 2010, although Guy did wonder about the doc changes, but no real conclusion was reached. Personally I would make 2013 the minimum supported for master. Hmm, OK. So we need an updated developer's guide setup section. I will try to update my Windows vom 2010 to 2013 and see how it goes - just have to find out how to snapshot the VM first ;- Could you update Makefile.nmake and config.nmake to rip out all the stuff that deals with older versions? That would make my life with the CMake work on Windows somewhat easier ;-) Thanks Jörg -- Joerg Mayer jma...@loplof.de We are stuck with technology when what we really want is just stuff that works. Some say that should read Microsoft instead of technology. ___ Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] Oldest version of VS supported?
On Thu, Jul 24, 2014 at 07:51:37PM +0200, Pascal Quantin wrote: Le 24/07/2014 19:39, Joerg Mayer a écrit : [...] Hmm, OK. So we need an updated developer's guide setup section. I will try to update my Windows vom 2010 to 2013 and see how it goes - just have to find out how to snapshot the VM first ;- Could you update Makefile.nmake and config.nmake to rip out all the stuff that deals with older versions? That would make my life with the CMake work on Windows somewhat easier ;-) Could not we keep at least VS2010 but change the default to VS2013 (if everybody agree)? I find it a quite drastic change to drop all older compilers suddenly... This is not something we have done in the past. I wouldn't mind that either - in that case I would not need to update my Windows build box right now :-) Btw, I've already found out that without updated setup instructions for the wsdg it would probably take me way too much time to do the upgrade from 2010 to 2013. Ciao Jörg -- Joerg Mayer jma...@loplof.de We are stuck with technology when what we really want is just stuff that works. Some say that should read Microsoft instead of technology. ___ Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
[Wireshark-dev] Problem with qtshark command line
Hello, the following works with wireshark but not qtshark: jmayer@egg:~/work/wireshark/git(review/gerald_combs/wsug-intro-asciidoc) qtshark -i wlan0 -k FIX: packet list heading menu sensitivity 08:51:34.953 Dbg plugin_dir: lib/wireshark/plugins/1.99.0 08:51:35.010 Main Dbg Translator en_US Usage: wireshark [options] ... [ infile ] Capture interface: -i interface name or idx of interface (def: first non-loopback) -f capture filter packet filter in libpcap filter syntax -s snaplen packet snapshot length (def: 65535) -p don't capture in promiscuous mode -k start capturing immediately (def: do nothing) -Q quit Wireshark after capturing -S update packet display when new packets are captured -l turn on automatic scrolling while -S is in use -B buffer size size of kernel buffer (def: 2MB) -y link type link layer type (def: first appropriate) -D print list of interfaces and exit -L print list of link-layer types of iface and exit Capture stop conditions: -c packet countstop after n packets (def: infinite) -a autostop cond. ... duration:NUM - stop after NUM seconds filesize:NUM - stop this file after NUM KB files:NUM - stop after NUM files Capture output: -b ringbuffer opt. ... duration:NUM - switch to next file after NUM secs filesize:NUM - switch to next file after NUM KB [...] I someone willing to take a look at this? Thanks Jörg -- Joerg Mayer jma...@loplof.de We are stuck with technology when what we really want is just stuff that works. Some say that should read Microsoft instead of technology. ___ Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] Problem with qtshark command line
On Mon, Jul 21, 2014 at 11:07:57AM +0200, Alexis La Goutte wrote: The help is wrong... (Copy/paste from gtk) -i and -k option is not yet supported by qtshark OK, that explains it :-) Thanks! Jörg -- Joerg Mayer jma...@loplof.de We are stuck with technology when what we really want is just stuff that works. Some say that should read Microsoft instead of technology. ___ Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
[Wireshark-dev] WSUG - Asciidoc: Fixed docbook/CMakeLists.txt
Hello Gerald, as I'm too dumb to attach a corrected version of the docbook/CMakeLists.txt to https://code.wireshark.org/review/#/c/3139/ I'm sending it via the list Ciao Jörg -- Joerg Mayer jma...@loplof.de We are stuck with technology when what we really want is just stuff that works. Some say that should read Microsoft instead of technology. # CMakeLists.txt # # Wireshark - Network traffic analyzer # By Gerald Combs ger...@wireshark.org # Copyright 1998 Gerald Combs # # This program is free software; you can redistribute it and/or # modify it under the terms of the GNU General Public License # as published by the Free Software Foundation; either version 2 # of the License, or (at your option) any later version. # # This program is distributed in the hope that it will be useful, # but WITHOUT ANY WARRANTY; without even the implied warranty of # MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the # GNU General Public License for more details. # # You should have received a copy of the GNU General Public License # along with this program; if not, write to the Free Software # Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA. # find_package( FOP ) # Call before XSLTPROC find_package( LYNX ) find_package( XSLTPROC ) find_package( XMLLINT ) find_package( ASCIIDOC ) set(WSUG_FILES wsug_src/WSUG_app_files.xml wsug_src/WSUG_app_howitworks.xml wsug_src/WSUG_app_messages.xml wsug_src/WSUG_app_protocols.xml wsug_src/WSUG_app_tools.xml wsug_src/WSUG_chapter_advanced.xml wsug_src/WSUG_chapter_build_install.xml wsug_src/WSUG_chapter_capture.xml wsug_src/WSUG_chapter_customize.xml WSUG_chapter_introduction.xml wsug_src/WSUG_chapter_io.xml wsug_src/WSUG_chapter_statistics.xml wsug_src/WSUG_chapter_telephony.xml wsug_src/WSUG_chapter_troubleshoot.xml wsug_src/WSUG_chapter_use.xml wsug_src/WSUG_chapter_work.xml wsug_src/WSUG_meta_info.xml WSUG_preface.xml wsluarm.xml ws.css ) set(WSDG_ASCIIDOC_FILES wsug_src/WSUG_chapter_introduction.asciidoc wsug_src/WSUG_preface.asciidoc ) set(WSUG_GRAPHICS wsug_graphics/ws-analyze-menu.png wsug_graphics/ws-bytes-pane-tabs.png wsug_graphics/ws-bytes-pane.png wsug_graphics/ws-capture-info.png wsug_graphics/ws-capture-interfaces.png wsug_graphics/ws-capture-interfaces-win32.png wsug_graphics/ws-capture-menu.png wsug_graphics/ws-capture-options.png wsug_graphics/ws-capture-options-remote-capture.png wsug_graphics/ws-capture-options-remote-interface.png wsug_graphics/ws-capture-options-remote-settings.png wsug_graphics/ws-capture-preferences.png wsug_graphics/ws-choose-color-rule.png wsug_graphics/ws-coloring-fields.png wsug_graphics/ws-coloring-rules-dialog.png wsug_graphics/ws-column-header-popup-menu.png wsug_graphics/ws-decode-as-show.png wsug_graphics/ws-decode-as.png wsug_graphics/ws-column-header-popup-menu.png wsug_graphics/ws-details-pane-popup-menu.png wsug_graphics/ws-details-pane.png wsug_graphics/ws-display-filter-tcp.png wsug_graphics/ws-edit-color-rule-dialog.png wsug_graphics/ws-edit-menu.png wsug_graphics/ws-enabled-protocols.png wsug_graphics/ws-expert-colored-tree.png wsug_graphics/ws-expert-column.png wsug_graphics/ws-expert-infos.png wsug_graphics/ws-export-objects.png wsug_graphics/ws-export-pdml.png wsug_graphics/ws-export-plain.png wsug_graphics/ws-export-ps.png wsug_graphics/ws-export-psml.png wsug_graphics/ws-export-selected.png wsug_graphics/ws-file-import.png wsug_graphics/ws-file-menu.png wsug_graphics/ws-file-set-dialog.png wsug_graphics/ws-filter-add-expression.png wsug_graphics/ws-filter-toolbar.png wsug_graphics/ws-filters.png wsug_graphics/ws-find-packet.png wsug_graphics/ws-follow-stream.png wsug_graphics/ws-go-menu.png wsug_graphics/ws-goto-packet.png wsug_graphics/ws-gui-colors-preferences.png wsug_graphics/ws-gui-columns-preferences.png wsug_graphics/ws-gui-config-profiles.png wsug_graphics/ws-gui-font-preferences.png wsug_graphics/ws-gui-layout-preferences.png wsug_graphics/ws-gui-preferences.png wsug_graphics/ws-help-menu.png wsug_graphics/ws-internals-menu.png wsug_graphics/ws-list-pane.png wsug_graphics/ws-logo.png wsug_graphics/ws-main-toolbar.png wsug_graphics/ws-main.png wsug_graphics/ws-menu.png wsug_graphics/ws-merge-gtk20.png wsug_graphics/ws-merge-gtk24.png wsug_graphics/ws-merge-win32.png
Re: [Wireshark-dev] Fwd: Re: Storing Generated Code in Git [Was: master 9079e3a: Cheat and try to fix the generated file manually.]
On Mon, Jun 23, 2014 at 09:17:32PM -0400, Evan Huus wrote: So perhaps what we should do is: not check generated code into Git; put all generated code into the source tarballs. +2 Presumably we should rebuild all the DCERPC files as well at buildtime then? YEs, once we have a version in our source that is actually capable of doing that. It doesn't build all files for me. If that's possible, yes. I don't actually know how to generate them, so I don't know how fast and/or cross-platform it is. See epan/dissectors/pidl/README on how to do that in tree (in theory). Ciao Jörg -- Joerg Mayer jma...@loplof.de We are stuck with technology when what we really want is just stuff that works. Some say that should read Microsoft instead of technology. ___ Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] Stateless Dissection
On Sun, Jun 22, 2014 at 05:07:19PM -0400, Evan Huus wrote: After Kurt's recent post I dug up an old patch I'd played with and cleaned it up a bit. It still needs some work (documentation at the very least) but [1] should add a -Z option to tshark which turns on stateless dissection. You lose reassembly and all that, but you should get no memory growth at all. The implementation is a bit of a hack in that stateless dissection still does all the stateful work, it just throws it away after each packet (so stateless is actually slightly slower than stateful) but it seems to work in my simple tests. Does this seem useful to people? Ideas for a better flag (Z just happened to be handy)? Other thoughts, comments, suggestions? How about having the cake and eating it (at least partially)? What I am thinking about is something like keeping state but only for the last 1000 (insert your favourite number here) packets and only *then* throwing it away. Or is this unrealistic? Ciao Jörg -- Joerg Mayer jma...@loplof.de We are stuck with technology when what we really want is just stuff that works. Some say that should read Microsoft instead of technology. ___ Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
[Wireshark-dev] Should checkapi check for bad includes?
Hello, Guy's recent changes to packet-corosync-totemsrp.c make me look at some includes that should not be necessary in dissectors. Is there a valid (design) use for the following includes in the dissectors/ subtree? sys/socket.h netinet/in.h winsock2.h Should other includes be added to this list? Thanks Jörg -- Joerg Mayer jma...@loplof.de We are stuck with technology when what we really want is just stuff that works. Some say that should read Microsoft instead of technology. ___ Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
[Wireshark-dev] Change in wireshark[master]: Qt: fix loading of language translation (forw)
Hi (mostly Gerald), two modest requests: 1) please change the spelling in the Mail subject from wireshark to Wireshark to match the spelling from the other mailings 2) please include the unified diff (at least as an option) with the gerrit patch mails. Thanks Jörg - Forwarded message from Alexis La Goutte (Code Review) code-review-do-not-re...@wireshark.org - Authentication-Results: strato.com 1; spf=pass smtp.mailfrom=code-review-do-not-re...@wireshark.org; dkim=none; dkim-adsp=none header.from=code-review-do-not-re...@wireshark.org Date: Mon, 16 Jun 2014 23:36:43 + From: Alexis La Goutte (Code Review) code-review-do-not-re...@wireshark.org To: Gerald Combs ger...@wireshark.org Reply-To: alexis.lagou...@gmail.com Subject: Change in wireshark[master]: Qt: fix loading of language translation User-Agent: Gerrit/2.8.3 Alexis La Goutte has uploaded a new change for review. https://code.wireshark.org/review/2286 Change subject: Qt: fix loading of language translation .. Qt: fix loading of language translation But need always restart to apply change... Change-Id: I0f95afb68aa5b125e0707b0af1ce096dab9c29e4 --- M ui/qt/main_window.cpp M ui/qt/main_window.h 2 files changed, 21 insertions(+), 0 deletions(-) git pull ssh://code.wireshark.org:29418/wireshark refs/changes/86/2286/1 -- To view, visit https://code.wireshark.org/review/2286 To unsubscribe, visit https://code.wireshark.org/review/settings Gerrit-MessageType: newchange Gerrit-Change-Id: I0f95afb68aa5b125e0707b0af1ce096dab9c29e4 Gerrit-PatchSet: 1 Gerrit-Project: wireshark Gerrit-Branch: master Gerrit-Owner: Alexis La Goutte alexis.lagou...@gmail.com - End forwarded message - -- Joerg Mayer jma...@loplof.de We are stuck with technology when what we really want is just stuff that works. Some say that should read Microsoft instead of technology. ___ Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] [Wireshark-commits] master e143570: Define INET6 for all platforms. Show the addresses as a tooltip in capture interfaces.
On Sat, Jun 14, 2014 at 01:27:12PM +, Wireshark code review wrote: URL: https://code.wireshark.org/review/gitweb?p=wireshark.git;a=commit;h=e14357032f38416a733596d3f003d51710eb1e52 ... e143570 by Irene Ruengeler (ruenge...@wireshark.org): Define INET6 for all platforms. Show the addresses as a tooltip in capture interfaces. Change-Id: I911784e09ed9479229a7d6f8a7f1476e2e1e6224 Reviewed-on: https://code.wireshark.org/review/2155 Reviewed-by: Evan Huus eapa...@gmail.com Reviewed-by: Alexis La Goutte alexis.lagou...@gmail.com Why not take the clean approach and remove all the #ifdef AF_INET6/#ifndef AF_INET6/defined(INET6) checks and the definition of INET6 itself instead? Thanks Jörg -- Joerg Mayer jma...@loplof.de We are stuck with technology when what we really want is just stuff that works. Some say that should read Microsoft instead of technology. ___ Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
[Wireshark-dev] SIMD optimizations with CMake
Hi, I'm planning to add the SIMD optimization that was recently added to autofoo to cmake as well. The current solution looks a bit weird to me, so maybe I have read the existing code incorrectly or misunderstood the ideas behind the current solution: Current situation: - Runtime: If the code has been compiled with SSE support then there is a runtime check whether the current cpu supports the optimizations. If not, a non-sse code path is taken. - Compile time: The C-compiler in wsutil/ is told to use the optimization flags discovered at configuration time. HAVE_SSE4_2 is the only flag curently used in the following files: ws_mempbrk.h and ./ws_mempbrk_sse42.c whether to enable the code or not. - Configuration time: The aclocal-fallback/ax_XXX.m4 files check whether the *current host cpu* supports theses extensions and sets the HAVE_xxx and SIMD_FLAGS (which then get added to ws_util/-CLFAGS) variables accodingly. Questions: a) Is this correct? b) Is there any check whether the compiler actually supports these flags? c) Are there any provisions for cross-compiling? Cmake only needs to redo the configuration time stuff, so I looked at it and didn't understand the design. What I intend to do is to just test whether the current compiler supports the extensions via adding the following flags to WIRESHARK_C_FLAGS: -faltivec, -mmmx, -msse, -msse2, -msse3, -mssse3, -msse4.1, -msse4.2, -mavx and then creating the necessary HAVE_xxx variables. Is there a good reason not to take this path (note: I have a cpu that only supports sse_4.1 so I can only do limited testing). Thanks Jörg -- Joerg Mayer jma...@loplof.de We are stuck with technology when what we really want is just stuff that works. Some say that should read Microsoft instead of technology. ___ Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
