I've also changed the way the secondary error message is transported from former "header message 0 secondary 0" to "header header message 0 header secondary 0" as that might be a bit more clearer, and I'll need it for further development anyway.
I was using this while debugging and not recognizing the real problem - for about four hours :-(. I'll need this feature when doing the interface (and link layer type) browsing later (transferring this data from dumpcap to Ethereal) to get a full blown privilege seperation.
svn path=/trunk/; revision=17608
primary and secondary error messages and let the parent worry about how
to display them. This means dumpcap doesn't need stub routines for
generating the formatting tags for the primary and secondary messages.
Have a separate message for capture filter errors, so that the parent
can check whether the capture filter looks like a display filter and
report the appropriate message. This means that dumpcap doesn't need a
stub routine for compiling display filters (a stub routine also means
that Ethereal won't do the check for capture filters that look like
display filters!).
svn path=/trunk/; revision=17465
command line passed to Create_Process().
On UN*X, use "execv()", not "execvp()", as we now construct the absolute
pathname of "dumpcap".
svn path=/trunk/; revision=17330
name of the program as used to run it (command name/path name). Pass
that - otherwise, we pass "-i" as argv[0], and dumpcap ignores it and
treats the capture device as the first argument and doesn't handle it
correctly (i.e., it doesn't capture on that device).
svn path=/trunk/; revision=17277
and writing the sync pipe, using g_log() calls at the G_LOG_LEVEL_DEBUG
or G_LOG_LEVEL_WARNING levels, so we can get at them if necessary. Add
some messages for errors for which we had no logging.
svn path=/trunk/; revision=17275
file, strip off the last component to get the pathname of the directory
containing the executable file, and save it for future use. On Windows,
you can get that from the OS, but, on UN*X, you have to look at argv[0]
and derive the absolute path from that (argv[0] is not guaranteed to be
an absolute path, or even a path at all). (In addition, if you're
running from the build directory, you might have to strip off a ".libs/"
added to argv[0] as an artifact of the libtoolizing script.)
Use that in the About dialog, and use it to construct the path of
dumpcap.
Don't put quotes into the path of dumpcap; you don't have to quote
strings with spaces in them when handing them to execvp and, in fact,
you *mustn't* quote them, as the quotes will be treated as part of the
pathname.
svn path=/trunk/; revision=17267
using dumpcap as the capture child for Ethereal.
dumpcap is a plain console application now, even for Win32 (so no WinMain, create_console and special piping stuff reguired). The undocumented command line option -Z will switch dumpcap into "child mode", using binary instead of plain text output messages to communicate with a parent Ethereal.
Ethereal's main.c no longer needs to distinguish between child mode or not, so some simplifying here.
capture_sync.c has to call dumpcap in a "hidden window" mode using CreateProcess instead of spawnvp, otherwise an uggly console window would appear. The handles created by _pipe doesn't seem to be inheritable for this function, using CreatePipe instead.
The file capture_loop.c is only needed by dumpcap, removed from Ethereal link objects.
Some debugging aid added and other minor cleanup done.
svn path=/trunk/; revision=17256
second try to bring dumpcap to life. Currently it's working, but the child (dumpcap) will show an annoying Win32 console window while running.
svn path=/trunk/; revision=17239
This way, the capture child don't need to now any of the packet_counter things (no epan/packet.h and all alike).
Currently the capture_info code will always open another wiretap file instance to build it's own counter values. This isn't optimized for now (next step: use data from cf_continue_tail() somehow).
svn path=/trunk/; revision=16669
capture_input_drops
capture_input_error_message
and move the functionality from capture_sync.c to capture.c (just where it belongs)
svn path=/trunk/; revision=16663
binary data, so the maximum message length can be up to 2^24-1.
Add a #define for that message size, and have it be 4096, for now, as
that was the size of the buffer used to read sync pipe messages.
Clean up white space.
When displaying an error message from the capture child, don't use it as
a format string - it could conceivably contain "%"s. Instead, format it
with "%s".
svn path=/trunk/; revision=16541
to do this, I've added file_util.h to wiretap (would file_compat.h be a better name?), and provide compat_macros like eth_open() instead of open(). While at it, move other file related things there, like #include <io.h>, definition of O_BINARY and alike, so it's all in one place.
deleted related things from config.h.win32
As of these massive changes, I'm almost certain that this will break the Unix build. I'll keep an eye on the buildbot so hopefully everything is working again soon.
svn path=/trunk/; revision=16403
remove Byte(s) from the dropdown list of filesizes, this doesn't make sense
replace 1000 with 1024, as all (modern?) file managers are based on 1024 bytes for a kilobyte (the old KB vs. KiB controversy)
svn path=/trunk/; revision=16149
-use g_snprintf instead of sprintf and snprintf
-use g_strdup_printf where appropriate
-remove #include "snprintf.h" (as only g_snprintf should be used)
-replace some more alloc/realloc/calloc/free with their glib pendants
svn path=/trunk/; revision=15264
use the console_log_handler in main.c for win32 AND unix now
Currently use the log for the capturing engine (only), as I desperately needed a log output for debugging.
svn path=/trunk/; revision=14438
add a new feature to clear the currently captured packets and restart the capture with the previous parameters
various code cleanup and minor bugfixes
Win32: use millisecond resolution in capture_loop, to smooth screen update a bit (500ms instead of 1000ms)
svn path=/trunk/; revision=14059
If this is used together with an option where input files changes too fast (e.g. new file every second), capturing will be (hopefully) stopped.
I've replaced the former capture pipe message format into a somewhat more general format to remove a lot of confusion.
svn path=/trunk/; revision=14054
display filename in statusbar while capturing
print_usage banner fixed
cf_cb_live_capture_prepare no longer needed
rename sync_pipe_do_capture -> sync_pipe_start
bugfix: sync_pipe_input_wait_for_start replaced by former implementation
fix cleanup of old file in capture_input_new_file
fix a tempfile detection bug (named file showed up as tempfile after capture)
svn path=/trunk/; revision=14053
most notably:
- moved opening of safe_file to the capture child (capture_loop.c)
- removed save_file_fd from capture_opts (no longer need to have it global)
svn path=/trunk/; revision=13953
Ulf Lamping