signifies moving west, in case you're wondering). Convert many Ethereal
icons to Wireshark, and remove a few. (Notably Ethereal.icns, for which
we don't currently have a counterpart.)
svn path=/trunk/; revision=18376
not available on all platforms. Include getopt.c in
EXTRA_ethereal_SOURCES and include getopt.h in EXTRA_ethereal_INCLUDES,
as we do with the other files that supply routines not available on all
platforms, rather than always including them in the source for dumpcap.
svn path=/trunk/; revision=17311
"version" field in the manifest is picky about formatting, so setting
a custom version in config.nmake (e.g. "0.10.14-test") will probably
break the Windows build.
svn path=/trunk/; revision=17291
- add a log facility to lua (so far just prints to stderr)
- add settings to disable lua even if installed, to load or not to load user scripts when superuser
- create a default /usr/local/share/ethereal/init.lua that blocks all the io/system calls when running as superuser
svn path=/trunk/; revision=17290
The Windows-native routines were integrated by inserting
#if GTK_MAJOR_VERSION >= 2 && _WIN32
win32_native_routine(GDK_WINDOW_HWND(top_level->window));
return;
#endif
at the beginning of each GTK+ file routine. There's probably a prettier
way to do this.
Some of the sizes need to be tweaked in win32-file-dlg.rc, but everything
seems to work.
Fix up whitespace.
svn path=/trunk/; revision=17285
I have developed an external plugin to enable ssl decryption in
ethereal.
Me
- Remove unnecessary $Id$ from acinclude.m4
- Added packet-ssl-utils.h to Makefile.common
- Fixed a few warnings
TODO
- Lots of warning fixes (see separate mail)
- Reformat function headers to read like the others do
(return value<newline>function-name...)
- Test on Windows platform
- Review the patch to packet-ssl.c and new files packet-ssl-utils.[hc]
svn path=/trunk/; revision=17156
I very often forget to stop a running capture, so Ethereal keeps capturing packets on and on, leaving me with a lot of unrequired packets.
On the other hand (because of the above) I often maximize Ethereal just to see that it's really not capturing any longer.
Looking at the window title isn't of much help, as this title changes with every capture file name loaded, so there's no title which can be easily remembered.
We probably might use this icon mechanism as well, when Ethereal loads a (huge) file, so the user get's a more visual feedback when the capture loading is finished (and probably for other potential "lengthy" tasks as well).
svn path=/trunk/; revision=17042
Attached a small patch to top level Makefile.am to include the recently
added diamter data files chargecontrol.xml and TGPPSh.xml
From jaaap Keuter:
I've polished up the README.malloc describing ememified memory management. It's basically the same information, but made a bit more accessable. All this in response to bug 511
svn path=/trunk/; revision=16845
It might be, that I've removed too many options:
in that case, replace
@PCAP_LIBS@
by some of
@PCAP_LIBS@ @SOCKET_LIBS@ @NSL_LIBS@
and let me know which of the options are needed
svn path=/trunk/; revision=16824
this way, the capture prefix will "logically" group the files together and file browsers will also group them
we may want to move the files into a subdir capture later
svn path=/trunk/; revision=16691
personal backup only, not meant for public testing!
I've copied main.c into dumpcap.c and carved out all things not needed
currently won't work as a command line tool, capture_loop.c wants an input pipe
console output is also very ugly and the whole code needs a lot of further cleanup
shouldn't break the unix build as I've only changed the nmake files so far, but who knows ...
svn path=/trunk/; revision=16615
the lines of what's done for RADIUS. That keeps them together (and
separate from other files), and makes the layout of the top-level source
directory closer to the layout of the installation directory, so that if
you run Ethereal or Tethereal from the top-level directory on Windows
it'll pick up the Diameter dictionary files (if it supports loading
them), and can do so on UN*X if we support a mechanism to let it find
its control files in the directory in which the binary resides.
Use the diameter_DATA, dtds_DATA, and radius_DATA macros in the
EXTRA_DIST macro, so you only have to change the lists of Diameter, DTD,
and RADIUS files in one place if you add or remove a file.
svn path=/trunk/; revision=16050
Gerald Combs