This is a VERY PRELIMINARY version of tfshark. It's an attempt to jumpstart FileShark and its architecture. Right now it's mostly just a very stripped down version of tshark with all of the necessary build modifications (including now building filetap library since tfshark depends on it)
This code has helped me identify what I believe to be all of the necessary layers for a complete fileshark architecture. And those layers will slowly be added in time (patches always welcome!).
svn path=/trunk/; revision=54646
on what libwiretap thinks it is.
Update some comments to reflect the death of the hack used to include
(libwiretap) plugin support in programs not built with libwireshark.
svn path=/trunk/; revision=54015
wireshark etc should now work, the basic stuff at least.
Known problems/todos:
- The plugins are not searched for in the current directory,
so find out how to let Wireshark know to search for the
plugins
- Other supporting files are missing (COPYING.txt, AUTHORS*, ...)
- Your missing feature could be listed here ;)
Ciao
Jörg
svn path=/trunk/; revision=53780
knowledge of particular types of plugins. Instead, let particular types
of plugins register with the common plugin code, giving a name and a
routine to recognize that type of plugin.
In particular applications, only process the relevant plugin types.
Add a Makefile.common to the codecs directory.
svn path=/trunk/; revision=53710
pcap probably is different from the WinPcap version.
- Set WINPCAP_VERSION for cmake builds to "unknown"
- Oh, the NEWS file changed again.
svn path=/trunk/; revision=53690
Always include the "true" zlib includes first. This works around a
bug in the Windows setup of GTK[23] which has a faulty zconf.h.
svn path=/trunk/; revision=53647
http://gcc.gnu.org/onlinedocs/gcc-4.8.2/gcc/Code-Gen-Options.html#Code-Gen-Options
-ftrapv "generates traps for signed overflow on addition, subtraction,
multiplication operations." and -fwrapv "instructs the compiler to
assume that signed arithmetic overflow of addition, subtraction and
multiplication wraps around using twos-complement representation."
Those seem mutually-exclusive to me, and we probably want wrapping, not
traps, as there's probably a fair bit of code out there that explicitly
or implicitly assumes wrapping. (Actually, we really want to avoid
signed arithmetic for the cases that most matter, such as offsets and
lengths, but, unfortunately, we currently have API conventions that
allow negative values for lengths, either with -1 meaning "to the end"
or with negative values meaning "relative to the end".) In addition,
there seem to be some bugs complaining that -ftrapv doesn't always cause
traps on signed integer overflow.
We seem to be seeing crashes in Lemon on the Solaris buildbot subsequent
to adding -ftrapv; I don't know whether that's an overflow being
detected, a bug in the compiler, or something unrelated, especially
given that we're using Sun C, not GCC, on the Solaris buildbot.
However, we'll try removing -ftrapv, to see if it fixes the problem; the
MIT CSAIL paper in question wasn't really recommending all the GCC
options it mentioned (which, as noted, wouldn't make sense, as -ftrapv
and -fwrapv appear to be mutually-exclusive).
svn path=/trunk/; revision=53556
cmake 2.6.
Add two more policy statements to avoid warnings on current cmake systems.
CMP0020 doesn't work - no idea why.
svn path=/trunk/; revision=53180
- Add a CMAKE_BUILD_TYPE default of RelWithDebInfo (Release with debug info),
print the choice.
This will pick up the previously used flags LINK_FLAGS and
CMAKE_C_FLAGS and CMAKE_CXX_FLAGS but also pick up the variables postfixed
by _<build-type>
- Remove Optimization (-O2) and debug (-g) flags from list of default flags
as they are now automagically set by CMAKE_C_FLAGS_RELWITHDEBINFO etc.
NOTE: This also needs to be done for the Windows flags, I just don't have
a Win system to test on right now.
svn path=/trunk/; revision=53083
data files (diameter/*, COPYING, manuf) when running *shark from the
build directory.
Do this by passing in the top-level source directory as a compile-time
definition (unfortunately this has to be in the top-level Makefile too because
some programs link directly with epan/filesystem.c).
The plugins dir is no longer below the datafile directory but rather the
progfile directory (if we have one). Handle the special case of AUTHORS-SHORT
(a data file but a generated one) by checking the file name before building
the path.
https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=5664
svn path=/trunk/; revision=52940
problem/solution.
"Long" since solved by copying the solution from Makefile.nmake.
Small update to the status of cmake builds on windows
svn path=/trunk/; revision=52574
variable of our parent process isn't going to work. Plan B is to write
this stuff into a file and manually run it once.
Hard code the QT5 search path on Windows for now.
svn path=/trunk/; revision=52489
running the executables from the build tree without installation.
It doesn't really work yet but the troubleshooting has to wait
until either I've gotten some sleep or someone else fixes it.
svn path=/trunk/; revision=52454
some smaller changes by me.
- README.cmake
Document how to (one day) run on Windows
- CMakeLists.txt
Use MSVC compiler flags for MSVC instead of gcc flags
- FindWSWinLibs.cmake
New: Creates HINTS for finding includes and libraries
inside the Wireshark support library installation.
- FindXXX.cmake
Make use of HINTS generated by FindWSWinLibs.cmake
This has not really been tested on Windows as my installation seems to have
automagically downloaded some fixes and is in an inconsistent state since.
Will probably need to reinstall.
svn path=/trunk/; revision=52194
Michael Mann