aboutsummaryrefslogtreecommitdiffstats
path: root/capture_loop.c
AgeCommit message (Collapse)AuthorFilesLines
2006-04-03Put the low-level sync routines into a common file so they can be sharedGuy Harris1-19/+19
by dumpcap and Ethereal (so that, on UN*X, the child process can report a detailed "can't exec dumpcap" error). Rename most of the "sync_pipe_XXX_to_parent()" routines, as they're also in Tethereal, which doesn't have a sync pipe. svn path=/trunk/; revision=17789
2006-04-03In Tethereal, don't save to a temporary file if "-w" isn't specified,Guy Harris1-35/+41
even if doing a live capture; just print the packets without saving them. In dumpcap: default to the capturing the entire packet; don't do the "Press any key" stuff when debugging on UN*X; do console logging (to the standard error) even when we're running as the capture child (the sync pipe should only be the standard output, not the standard error). svn path=/trunk/; revision=17786
2006-03-24remove some XXX markers in comments which are no (longer) ToDo itemsUlf Lamping1-2/+2
svn path=/trunk/; revision=17715
2006-03-21Simplify the argument list to cap_pipe_dispatch().Guy Harris1-16/+15
svn path=/trunk/; revision=17690
2006-03-13fix bug #803: sync pipe on Win32 wasn't set to binary mode, so error message ↵Ulf Lamping1-1/+2
transport failed between Ethereal and dumpcap. 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
2006-03-09fix two bugs causing crashes on Win32: Ulf Lamping1-6/+10
- fix buggy g_snprintf call (Win32 fails if %s is called with a NULL pointer) - don't call file close if file wasn't open before (Win32 crashes if eth_unlink is called with a NULL pointer) svn path=/trunk/; revision=17558
2006-03-05Add in a variable we need on Windows.Guy Harris1-0/+3
svn path=/trunk/; revision=17469
2006-03-05In the capture_loop.c code, open the capture device for input beforeGuy Harris1-8/+8
doing anything with the output file, so that 1) if the attempt to open the capture device fails, we don't bother creating any output files; 2) we could relinquish privileges permanently as soon as we finish opening the capture device, so we don't have to give them up temporarily when opening the output file, reclaim them to open the input device, and then give them up permanently; (we already do that in Tethereal). While we're at it, set the capture filter immediately after opening the capture device, so we quit before opening capture devices if that fails. svn path=/trunk/; revision=17468
2006-03-05Make some routines not used outside capture_loop.c static.Guy Harris1-2/+2
svn path=/trunk/; revision=17466
2006-03-05Pass two strings in capture child messages, so the child can sendGuy Harris1-73/+69
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
2006-03-04When capturing, we only support writing to libpcap files. Given that,Guy Harris1-50/+29
bypass Wiretap; that means we don't have to run the packet through wtap_process_pcap_packet() and then undo that conversion in Wiretap if we're just going to write it out, shortening the code path. svn path=/trunk/; revision=17461
2006-02-17remove dependencies to pcap.h, so getting an idea what needs to be done by ↵Ulf Lamping1-39/+18
dumpcap in addition to the things already done now various dumpcap related code cleanup: mainly #include's and capture engine related stuff svn path=/trunk/; revision=17327
2006-02-12Move create_tempfile() to tempfile.c out of util.c. This means dumpcapGuy Harris1-1/+1
no longer needs util.c, so it no longer includes routines that use host_ip_af(), so it no longer needs to define its own host_ip_af(). That also means dumpcap.c no longer needs to include <sys/socket.h>. svn path=/trunk/; revision=17278
2006-02-12mark an unused parameterUlf Lamping1-1/+1
svn path=/trunk/; revision=17263
2006-02-11the point of no return ...Ulf Lamping1-6/+9
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
2006-01-07move output_to_pipe flag from tethereal's loop_data into capture_opts, so it ↵Ulf Lamping1-2/+5
can be used by dumpcap (capture_loop.c) as well svn path=/trunk/; revision=16972
2006-01-06code cleanup: use "-" for all places, where stdin/stdout is meantUlf Lamping1-1/+1
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
2006-01-04Handle a null-string file name in "capture_loop_open_output()" - that'sGuy Harris1-12/+25
what indicates that we're supposed to write to the standard output (Tethereal turns "-" into ""). svn path=/trunk/; revision=16941
2005-12-31Ooops, remove a debug message in the Win32 code part of the capturing loop.Ulf Lamping1-1/+1
It might (very slightly) slow down capturing in the 0.10.14 release :-( svn path=/trunk/; revision=16923
2005-12-17Win32 bugfix: peeking the signal_pipe at capture_loop start seems to be ↵Ulf Lamping1-10/+5
unreliable Instead, simply keep the signal_pipe setting directly from the command line which is working well svn path=/trunk/; revision=16833
2005-12-14Constify a bunch of arguments and variables, to squelch compilerGuy Harris1-3/+2
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
2005-12-13HUGE STEP (hopefully toward the right direction):Ulf Lamping1-125/+81
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
2005-12-06rename pcap-....c/.h files to capture-pcap-....c/.hUlf Lamping1-1/+1
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
2005-12-05I've forgot to put one line under _WIN32, should fix the unix buildUlf Lamping1-5/+5
svn path=/trunk/; revision=16679
2005-12-05Win32: fix signal_pipe handling if we run dumpcap as a standalone ↵Ulf Lamping1-22/+39
application (no signal_pipe) svn path=/trunk/; revision=16677
2005-12-04move the complete functionality of the capture info dialog from ↵Ulf Lamping1-55/+6
capture_loop.c to capture_info.c and call it from capture.c (instead of capture_loop.c). 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
2005-12-03split some parts of the packet counting functions into their own files ↵Ulf Lamping1-102/+14
capture_info(.c/.h), so we can use it from the main program svn path=/trunk/; revision=16668
2005-12-03split capture.h into capture.h, capture_loop.h and capture_opts.h and place ↵Ulf Lamping1-0/+1
the parts into the corresponding files svn path=/trunk/; revision=16664
2005-12-03the function capture_loop_popup_errmsg seems to be useless and misleading, Ulf Lamping1-17/+8
simply call sync_pipe_errmsg_to_parent directly instead svn path=/trunk/; revision=16662
2005-12-02performance improvement: if the packet info dialog is hidden, we don't need ↵Ulf Lamping1-0/+7
to call the capture_... packet count functions svn path=/trunk/; revision=16647
2005-11-28dumpcap.c doesn't need to link with file.c!Ulf Lamping1-1/+8
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
2005-11-28first steps towards a separated capture tool, working title "dumpcap"Ulf Lamping1-0/+2
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
2005-11-25rephrase the error dialog if an interface couldn't be opened.Ulf Lamping1-7/+9
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
2005-11-07Fix a typo.Guy Harris1-1/+1
svn path=/trunk/; revision=16408
2005-11-06replace *a lot* of file related calls by their GLib counterparts. This is ↵Ulf Lamping1-11/+7
necessary for the switch to GTK 2.6 (at least on WIN32). 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
2005-10-30Make capture filter (and capture filter error message) strings "safe" asGuy Harris1-4/+10
necessary before putting them into an error message dialog. Fixes bug 564. svn path=/trunk/; revision=16365
2005-10-07fix Ethereal so command line capture parameter will work with kilobytes (again)Ulf Lamping1-3/+1
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
2005-10-06bugfix: reset the packet counter to zero, if switching to the next "multiple ↵Ulf Lamping1-0/+2
file". This fixes the live update of the packet output after switching to another capture file svn path=/trunk/; revision=16135
2005-10-04Add a note about 64-bit support in WinPcap to the capture errors onGuy Harris1-0/+8
Windows, and add the URL for the CaptureSetup page to the Tethereal error. svn path=/trunk/; revision=16103
2005-09-27mention "http://wiki.ethereal.com/CaptureSetup" in the error dialog, when ↵Ulf Lamping1-0/+2
the capture interface couldn't be opened svn path=/trunk/; revision=16025
2005-09-22Libpcap uses u_char; use it in our calls to libpcap routines and in ourGuy Harris1-8/+8
libpcap callback routine (if it's not getting defined, <pcap.h> doesn't work). svn path=/trunk/; revision=15952
2005-09-22Update to current reality (WinPcap 3.1) the messages shown on Windows ifGuy Harris1-7/+4
a capture device open fails. svn path=/trunk/; revision=15951
2005-09-14added compression support for capture file output. The Save/As dialog now ↵Ulf Lamping1-5/+5
has a checkbox "Compress with gzip" 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
2005-08-06Last set of char -> const char trivial warning fixes.Jörg Mayer1-1/+1
svn path=/trunk/; revision=15244
2005-05-26fix #125: as suggested, the data in rechdr has to be kept over several calls ↵Ulf Lamping1-2/+2
to capture_loop_dispatch, so put it in the loop_data svn path=/trunk/; revision=14442
2005-05-26some cleanup of capture error notification handlingUlf Lamping1-1/+1
svn path=/trunk/; revision=14441
2005-05-26use the log features of the GLib to have verbose output of the capturing ↵Ulf Lamping1-8/+83
engine, e.g. GLib provides different domains for different submodules. Output more verbose than warning level will be disabled by default (just like before). 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
2005-05-12Use "pcap_get_selectable_fd()" if we have it, and if it returns -1,Guy Harris1-32/+52
don't do a "select()". svn path=/trunk/; revision=14358
2005-04-30(hopefully) removed various gcc warningsUlf Lamping1-1/+1
svn path=/trunk/; revision=14241
2005-04-16beautify an error messageUlf Lamping1-7/+11
svn path=/trunk/; revision=14101
generated by cgit v1.2.3 (git 2.25.1) at 2024-05-17 00:27:34 +0000