tethereal internally converted the stdout capture filename "-" into "" which doesn't make any real sense and only complicated things.
To make things even more confusing, wiretap expected "" for dump output and "-" for offline reading ...
svn path=/trunk/; revision=16962
warnings.
Include "wiretap/libpcap.h" in "capture_loop.h", to get its declarations
of data structures for headers in libpcap files. This lets us remove
the includes of "wiretap/libpcap.h from files including
"capture_loop.h".
Make "log_func_ignore()" in "tethereal.c" static, and declare some of
its arguments unused. Also get rid of an unused variable.
Include <pcap.h> before including "wiretap/wtap-capture.h", to declare
"struct pcap_pkthdr".
svn path=/trunk/; revision=16791
remove a lot of redundant code from tethereal and use (move) stuff from capture_loop.c instead.
concentrate common capture related code in capture_opts.c, e.g. trying to find the right interface to capture from (command line option, preference, first usable) instead of duplicating this code over several files.
remove redundant code from dumpcap.c
this also implements command line option -D (and indexed interfaces at -i) for Ethereal and Dumpcap (as we have it in Tethereal already for a while)
svn path=/trunk/; revision=16787
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
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
this fortunately removes *a lot* of dependencies and make the resulting binary a lot smaller (and hopefully faster to load :-)
some more cleanup (like replacing // by /**/)
svn path=/trunk/; revision=16620
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
made the CaptureSetup wiki page more prominent
added some "headings" so some of the help subtopics are easier for "human grep" IMHO
svn path=/trunk/; revision=16592
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
currently limited to Ethereal and all the variants of libpcap filetypes only.
We might want to add output compression support to the other tools as well (tethereal, mergecap, ...).
We might also want to add support for the other filetypes, but this is only possible if the filetype functions doesn't use special output operations like fseek.
One bug is still left: if the input and output filetypes while saving are the same, Ethereal currently optimizes this by simply copy the binary file instead of using wiretap (so it will be faster but it will ignore the compress setting).
Don't know a good workaround for this, as I don't know a way to find out if the input file is currently compressed or not. One idea might be to use a heuristic on the filesize (compared to the packet size summmary). Another workaround I see is to remove this optimization, which is of course not the way I like to do it ...
svn path=/trunk/; revision=15804
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
fflush new output file (to have at least the pcap header on disk) before sending the corresponding message to the capture parent
svn path=/trunk/; revision=14052
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
filter after installing the filter.
Set HAVE_PCAP_LIB_VERSION if we're building with WinPcap 3.1; it's not
present in earlier versions, but is present in current 3.1 betas.
Check HAVE_PCAP_LIB_VERSION when building capture-wpcap.c.
svn path=/trunk/; revision=13872
Ulf Lamping