they have LF at the end of the line on UN*X and CR/LF on Windows;
hopefully this means that if a CR/LF version is checked in on Windows,
the CRs will be stripped so that they show up only when checked out on
Windows, not on UN*X.
svn path=/trunk/; revision=11400
This matters for "update of list in real time" (sync_mode) only,
as in normal mode you wouldn't otherwise have the possibility
to stop the capture.
svn path=/trunk/; revision=11194
and the error message includes "Not enough storage is available
to process this command" or "The operation completed successfully",
suggest that the user install a WinPcap version later than 3.0 - this is
definitely a Frequently Asked Question on the Ethereal list.
svn path=/trunk/; revision=11143
changed window_xy (dialog) function calling in a lot of gtk files
cleanup of file selection code
cleanup in dlg_utils/file_dlg/ui_util
Please report any problems!!!
svn path=/trunk/; revision=11003
would be an independent clause, so it should be separate from the other
clause with a semicolon).
Note that, in that tooltip, in some cases "link-layer types" would be
appropriate and in others "link-layer header types" might be more
appropriate.
svn path=/trunk/; revision=10722
Ethereal-defined indication of the action (open vs. save), regardless of
whether we're building for GTK+ >= 2.4 or not; we just ignore the
argument in pre-2.4 GTK+.
Use "file_selection_new()" rather than #if'ed code to use it or
"gtk_file_chooser_dialog_new()" for GTK+ >= 2.4 and
"gtk_file_selection_new()" or it for pre-2.4 GTK+.
Add a "file_selection_set_current_folder()" routine that does the
appropriate thing depending on whether we're GTK+ >= 2.4 or not, and use
that rather than #if'ed code to use
"gtk_file_chooser_set_current_folder()" or
"gtk_file_selection_set_filename()".
svn path=/trunk/; revision=10511
them, so we can't look for "\Device\" as the beginning of the interface
name. Instead, on Windows, scan backwards for a colon and then skip the
colon and any subsequent blanks. (I don't *think* interface names have
colons in them in Windows, even on NT 5.x with the GUID crapola in the
name.)
svn path=/trunk/; revision=10210
Mac OS X
GNOME
Qt
KDE
Windows
all indicate that {message,alert} boxes are modal, at least for the
window to which they apply. (Presumably the idea is that not forcing
the user to pay attention to the alert box, and allowing more than one
alert box to be up for a given window, causes more problems than not
letting the user do stuff to that window in order to figure out what the
underlying problem is or figure out what to do to fix it - the message
should be sufficient, in most if not all cases, to let you know what the
problem is.)
Make "simple_dialog()" unconditionally make the alert box modal, and get
rid of ESD_TYPE_MODAL. XXX - we need to make it possible to make an
alert box modal for a given window, rather than just the top-level
window.
svn path=/trunk/; revision=10051
as that seems to be the name used in the GNOME HIG, at least. Make it
use the Warning icon (that's what the GNOME HIG says - and it's also
what's used for the equivalent on Windows), and use it for the "Save
current capture?" alert boxes.
svn path=/trunk/; revision=10030
simple_dialog routines (which are really just message box/alert box
routines).
Add some macros for combinations of buttons (corresponding to
combinations that some GUI toolkits, which only support some
combinations, allow).
svn path=/trunk/; revision=9977
using GTK2 primary/secondary message text from GNOME HIG for simple_dialogs,
added a "question dialog" for the coloring rules "Clear" button
svn path=/trunk/; revision=9921
"simple_dialog()"; NULL might be #defined to be a pointer expression on
some platforms, causing compiler warnings (and, on platforms where a
null pointer doesn't have all its bits 0, possibly causing misbehavior,
although I don't think there are any such platforms on which Ethereal
runs).
Don't allow 0 as button mask argument to "simple_dialog()".
Squelch a compiler warning.
Report fatal problems as errors, not warnings.
Report file I/O errors with "file_open_error_message()".
Report file write errors (including those reported by "close()", e.g.
some errors writing to an NFS server) when saving raw packet data to a
file.
svn path=/trunk/; revision=9915
interface name, look forward in the interface string for "\Device\", not
backwards for a space, on Windows. (Continue to look backwards for a
space on UNIX; names don't start with "\Device\", or even "/dev/", and
don't have spaces in them on any UNIX-flavored OS I know of.)
svn path=/trunk/; revision=9859
layouting the dialog buttons, and use it where appropriate.
This will help us with the GTK1/2 conflict on button layouts and
will also result in a more consistent look of the dialogs at all.
svn path=/trunk/; revision=9771
the interface isn't in the list of known (local) interfaces - that way
we don't try to get entries if the user's in the middle of changing the
"Interface:" text, or if the interface is an rpcap: URL (getting the
link-layer header type list for a remote interface is currently
impossible, and even just getting its *default* interface type could
hang for a long time if the remote machine isn't responding).
Free the link-layer header type list when we're done with it.
Label the option menu for that list "Link-layer header type", as it
doesn't control the data link type of the interface in the only case I
know of where it's settable, namely 802.11 interfaces - it just controls
whether the packets you get from the interface have a fake Ethernet
header or a real 802.11 header.
svn path=/trunk/; revision=8867
2.x) and transient-for setting that's done for other dialogs, and use it
for dialogs that come from the main window or from children of the main
window.
svn path=/trunk/; revision=8531
Capture Options dialog box to the first string in the combo box, not to
the first interface name in the list, so we get the description.
svn path=/trunk/; revision=8444
containing a pointer to an interface name and possibly a pointer to an
interface description (although that pointer might be null if no
description is available), rather than having the Windows version glue
together the name and description into a single string.
Supply for the Linux "any" device the same description that libpcap's
"pcap_findalldevs()" returns.
svn path=/trunk/; revision=8440
support for user-supplied interface descriptions;
support for hiding interfaces in drop-down list in capture
dialog.
Clean up comments written to preferences file.
svn path=/trunk/; revision=8419
when the new "Rotate capture file every n second(s)" checkbox or the
-b <# of file>[:<duration>] argument are used, [t]ethereal will skip to the
next ring buffer file if the specified duration has elapsed (even if the
specified capture size is not reached). This is useful when you want to have
separate capture files per hour or day for instance.
I let the autostop filesize parameter mandatory (i.e. the "rotate capture
file after n kilobytes") but this could be no longer strictly necessary when
that new feature is used ...
Another point: it might be interesting to really truncate the file at the
switch and not the closure ... According to user comments and my own real
case tests, I might plan to enhance this point and others (still ring buffer
related) in the future.
svn path=/trunk/; revision=7678
"destroy" signal handler for any button that pops up a filter; if the
button has a filter dialog box associated with it, it destroys that
dialog box.
Have the routines that create filter dialog boxes asociate the dialog
box with the button that created it, so that if the button is destroyed
the filter dialog box can be destroyed as well, and associate the button
with the dialog box.
This means that if a dialog box has a button to create a filter, we no
longer have to have the destroy handler for the dialog box destroy any
filters - that'll happen when the button in the dialog box is destroyed
as part of the process of destroying the dialog box.
Don't make the "Filter" buttons in the io_stat dialog box insensitive if
there's already a filter dialog box open - we can have more than one
open per dialog box.
svn path=/trunk/; revision=6930
In my recent patches to set and use a default directory, I neglected
to set the directory when the user enters a file name directly into the
"Capture Options" and "Print" dialogs instead of using the file dialog.
This set of patches corrects this.
svn path=/trunk/; revision=6318
Currently Ethereal sets and uses a default directory for reading
and writing, but only in some places. This set of patches extends
the setting of the default directory to the -w option as well as
the -r option, and causes all file dialogs to use and set the
default consistently. (I haven't changed the
Preferences/Printing/File dialog, though, as that's a special
case.)
There's also a fix for a bug where Ethereal was issuing the
message "Ring buffer requested, but capture isn't being saved to
a permanent file" even though a file was specified with -w.
There also appear to be some other cleanups in his patch.
svn path=/trunk/; revision=6238
dftest.c:
Remove #if-0-ed includes
packet-ieee80211.c, packet-wtls.c, packet-afp.c, packet-wsp.c,
packet-wtp.c, ethereal_gen.py:
Remove redundant include varargs (already in snprintf.h,
and required only for snprintf.h)
Remove unused include of snprintf.h from files not using
"snprintf()".
svn path=/trunk/; revision=5889
Move the ringbuffer capture options from the "capture_file" structure to
the structure for capture options, as they're a property of an
in-progress capture, not a property of a particular capture file.
svn path=/trunk/; revision=4799
"capture_file" structure - they're a property of an in-progress capture,
not a property of an open capture file. Make them just variables.
The maximum number of packets to be captured should be a variable
separate from the "count" field in the "capture_file" structure - the
latter is a count of the packets in the capture file in question.
Have Boolean variables indicating whether a maximum packet count,
maximum capture file size, and maximum capture duration were specified.
If an option isn't set, and we're doing an "update list of packets in
real time" capture, don't pass the option to the child process with a
command-line argument.
Don't create "stop when the capture file reaches this size" or "stop
when the capture's run for this long" conditions if a maximum capture
file size or a maximum capture duration, respectively, haven't been
specified. Don't test or free a condition if it wasn't created.
Don't allow a 0 argument to the "-c" flag - the absence of a "-c" flag
is the way you specify "no limit on the number of packets".
Initialize the check boxes and spin buttons for the "maximum packets to
capture", "maximum capture size", and "maximum capture duration" options
to the values they had in the last capture. If an option wasn't
specified, don't read its value from the dialog box and set the
variable.
svn path=/trunk/; revision=4795
reading the capture file. Have callers of "wtap_snapshot_length()"
treat a value of 0 as "unknown", and default to WTAP_MAX_PACKET_SIZE (so
that, when writing a capture file in a format that *does* store the
snapshot length, we can at least put *something* in the file).
If we don't know the snapshot length of the current capture file, don't
display a value in the summary window.
Don't use "cfile.snap" as the snapshot length option when capturing -
doing so causes Ethereal to default, when capturing, to the snapshot
length of the last capture file that you read in, rather than to the
snapshot length of the last capture you did (or the initial default of
"no snapshot length").
Redo the "Capture Options" dialog box to group options into sections
with frames around them, and add units to the snapshot length, maximum
file size, and capture duration options, as per a suggestion by Ulf
Lamping. Also add units to the capture count option.
Make the snapshot length, capture count, maximum file size, and capture
duration options into a combination of a check box and a spin button.
If the check box is not checked, the limit in question is inactive
(snapshot length of 65535, no max packet count, no max file size, no max
capture duration); if it's checked, the spinbox specifies the limit.
Default all of the check boxes to "not checked" and all of the spin
boxes to small values.
Use "gtk_toggle_button_get_active()" rather than directly fetching the
state of a check box.
svn path=/trunk/; revision=4709
"epan/..." pathnames, so as to avoid collisions with header files in any
of the directories in which we look (e.g., "proto.h", as some other
package has its own "proto.h" file which it installs in the top-level
include directory).
Don't add "-I" flags to search "epan", as that's no longer necessary
(and we want includes of "epan" headers to fail if the "epan/" is left
out, so that we don't re-introduce includes lacking "epan/").
svn path=/trunk/; revision=4586
Separate the preferences value for those flags and the name resolution
code's value into separate variables; this means that the resolution
code no longer depends on the preferences code, and may let us
eventually have the current setting and the preference setting differ
(so that a user can temporarily override the preference setting without
causing subsequent saves of the preferences to save the temporary
value).
Add routines to create various types of widgets for preferences, and to
fetch the values for "enumerated" preferences, and use them both in the
code to handle hardwired preference pages and table-driven preference
pages.
svn path=/trunk/; revision=4536
"Capture Preferences", to avoid confusion with the "Capture" item in the
"Preferences" dialog (which sets the initial default values for the
"Capture Options" dialog).
svn path=/trunk/; revision=4523
and "Automatic scrolling in live capture" options from the preference
settings for them, so that the preference settings affect the initial
values of those options, but changing those values in a capture don't
affect the preferences, and don't automatically get saved when you save
the preferences.
If we're building without libpcap, don't have an "Automatic scrolling in
live capture" option anywhere.
svn path=/trunk/; revision=4514
directly edit the capture preferences, rather than only being able to
set them implicitly from the values for the most recent capture.
Add a preferences item for the interface on which to capture.
Get rid of some unused variables.
svn path=/trunk/; revision=4510
insensitive, make its label sensitive or insensitive too.
When "update list of packets in real time" mode is on, make the ring
buffer mode toggle button, and the "number of ring buffer files" spin
button, insensitive, as ring buffer mode is not supported in "update
list of packets in real time" captures.
When "update list of packets in real time" mode is off, make the
auto-scroll mode button insensitive, as auto-scroll mode is meaningless
unless you're doing an "update list of packets in real time" capture.
Bundle all the sensitivity setting into a single common routine.
Make "ring buffer" two words.
svn path=/trunk/; revision=4325
files to get that big.
From Thomas Wittwer and Matthias Nyffenegger:
Support for "ring buffer mode", wherein there's a ring buffer of N
capture files; as each capture file reaches its maximum size (the ring
buffer works only with a maximum capture file size specified), Ethereal
rolls over to the next capture file in the ring buffer, replacing
whatever packets might be in it with new packets.
svn path=/trunk/; revision=4323
for AIX 5.x's non-standard libpcap, where "pcap_datalink()" doesn't
return DLT_ values, it returns RFC 1573 ifType values.
Put that wrapper, and the routine to get the interface list, in a
separate file, for packet-capture utility routines, so not everybody who
includes "util.h" needs to include <pcap.h>.
Fix up the Wiretap hack for dealing with said incompatibility to use the
correct ifType value for Token Ring.
svn path=/trunk/; revision=4184
mirroring procedure, due to the Politecnico di Torino site's IIS not
being configured to allow the relevant "virtual directories" to be
listed, thus keeping Wiretapped.net from figuring out what files were
there and whether they've changed), so put back the references to it.
svn path=/trunk/; revision=3976
WinPcap's installer (it dates back to May, meaning it may be a beta of
2.2 or may even be 2.1), so don't suggest that people go there.
svn path=/trunk/; revision=3964
when wpcap.dll couldn't be loaded more detailed, in the hopes that it'll
reduce the chances that somebody will see that message and not know what
to do. Also, mention the Wiretapped.net mirror of the WinPcap site, as
the WinPcap site is all-too-often down due to networking glitches.
svn path=/trunk/; revision=3955
Joerg Meyer.
Support for saving to the preferences file the settings for all types of
name resolution.
Do a case-insensitive check for "true" and "false" in Boolean preference
settings.
svn path=/trunk/; revision=3489
and never was - there's only an Ethereal-wide "enable name resolution"
preference. Name it just "name_resolve".
Replace all tests of "g_resolving_actif" with tests of
"prefs.name_resolv", and replace all code that sets "g_resolving_actif"
with code that sets "prefs.name_resolv", so that the setting of
"prefs.name_resolv" actually affects whether names are resolved or not.
svn path=/trunk/; revision=3300
for Win32, and show a slightly more informative (i.e., geared to the
user) help message when trying to capture without having WinPcap installed.
svn path=/trunk/; revision=3261
That means that I no longer need to distribute capture and non-capture
versions of Ethereal for Win32; one version (compiled with WinPcap headers)
can run on systems with or without WinPcap.
For systems that don't have WinPcap, instead of disabling the Capture
menu, Capture|Start brings up a dialogue informing the user that wpcap.dll
was not loadable, and gives a URL to the WinPcap home page.
svn path=/trunk/; revision=3249
compiled capture filter program, so remove it, and remove the include of
<pcap.h> from "file.h"; instead, have local "struct bpf_program"
structures where needed, and have those files that need stuff from
<pcap.h> include it.
This cleans stuff up a bit, and should eliminate a pile of compile
warnings with Visual C++ due to <pcap.h> and some GTK+/GLib header file
(or files they include) both defining "inline".
svn path=/trunk/; revision=2954
display tree, based on Jeff Foster's dialog box for selecting fields.
Make the dialog box for browsing filters into a dialog box for
constructing filters; make the "Apply" button and the "OK" button apply
the filter in the text entry box in the dialog, not the currently
selected filter (selecting a filter puts it in that text entry box, but
the user may edit it afterwards, or may use the aforementioned dialog
box to construct a filter not in the list).
Get rid of extra declarations of "m_r_font" and "m_b_font" in
"proto_draw.c"; they're declared in "gtk/gtkglobals.h", which it includes.
svn path=/trunk/; revision=2805
"globals.h" file to "epan/resolv.h", as it's exported by
"epan/resolv.c", have files that use "g_resolving_actif" include
"resolv.h", and don't have "epan/resolv.c" include "globals.h" so that
it doesn't drag in, for example, headers that, in turn, drag in GTK+
headers.
svn path=/trunk/; revision=2517
you stop an "Update list of packets in real time" capture from the main
window as well as from the capture statistics dialog.
svn path=/trunk/; revision=2487
Preferences" dialog box, to control whether to put the interface in
promiscuous mode or not; Debian bug #34376 asked for this.
svn path=/trunk/; revision=2439
for the dialog window as an argument (as various dialog creators in GTK+
do), not oblige every caller of it to cut-and-paste a
"gtk_window_set_title()" call after it.
svn path=/trunk/; revision=2345
- add <stdarg.h> or <varargs.h> in snprintf.h
and remove those inclusions in the other #ifdef NEED_SNPRINTF_H codes
- remove the check of multiple inclusions in source (.c) code
(there is a bit loss of _cpp_ performance, but I prefer the gain of
code reading and maintenance; and nowadays, disk caches and VM are
correctly optimized ;-).
- protect all (well almost) header files against multiple inclusions
- add header (i.e. GPL license) in some include files
- reorganize a bit the way header files are included:
First:
#include <system_include_files>
#include <external_package_include_files (e.g. gtk, glib etc.)>
Then
#include "ethereal_include_files"
with the correct HAVE_XXX or NEED_XXX protections.
- add some HAVE_XXX checks before including some system header files
- add the same HAVE_XXX in wiretap as in ethereal
Please forgive me, if I break something (I've only compiled and regression
tested on Linux).
svn path=/trunk/; revision=2254
to use "warning" dialog boxes only to warn the user "if you do that, bad
things may happen" *and* to offer them the option either to drive on or
quit, so perhaps ESD_TYPE_CRIT should be used for all errors).
However, put "Ethereal: Error" rather than "Ethereal: Critical" in the
title bar, in the hopes that it'll make it clearer that Something Bad
Happened.
If the user specifies that captures should be saved to a user-specified
file rather than a temporary file, report errors trying to create that
file with "file_open_error_message()".
Make the "for_writing" argument to "file_open_error_message()" a
"gboolean", as it's either TRUE (if the file is being opened for
writing) or FALSE (if it's being opened for reading).
Report EISDIR as "XXX is a directory (folder), not a file.".
svn path=/trunk/; revision=2143
window and makes it transient for the top-level window; the
transient-for at least provides a hint to X window managers to
minimize the dialog if the main window is minimized;
keep the dialog on top of the main window in the Z order for
windows;
perhaps (if there are any window managers that actually *do*
this) even put it atop the main window in the X-Y plane (KWM
doesn't and I seem to remember that the Exceed X server for
Windows doesn't).
It's generally considered the Right Thing To Do for dialog boxes.
Use that routine to create dialog boxes, rather than doing it directly
in the code for that dialog box.
svn path=/trunk/; revision=2112
make it easier to use grep to find all references to it without getting
a lot of false hits and to check, after allocating the memory chunk for
"frame_data" structures, that the allocation succeeded.
svn path=/trunk/; revision=2092
"File->Open", "File->Save As", and the "File:" buttons in the Capture
Preferences and Print dialog boxes, and make it cancel the file
selection dialog box.
svn path=/trunk/; revision=1921
mnemonics.
Give the button, in the "Display Options" dialog box, that controls
whether name resolution is enabled or not the same label ("Enable name
resolution") as the equivalent button in the "Capture Preferencs" dialog
box.
svn path=/trunk/; revision=1920
box it has open, so that:
if the capture preferences dialog box goes away, so does the
file selection dialog box (as it no longer has a text widget
into which it can stuff the selected file name);
if the "File:" button is clicked when there's already a file
selection dialog box open, we just reactivate that existing
dialog box rather than popping up a new one.
svn path=/trunk/; revision=1919
"global" dialog box when "Edit:Filters" is selected, so that the list of
filters can be edited, and "filter_browse_cb()", which pops up a dialog
box associated with a "Filter:" button and a text entry widget attached
to that button, so that a filter can be selected or saved (although it
also supports the same editing that the "global" dialog box does).
Have "filter_dialog_cb()" connect the window in which the "Filter:"
button lives and the filter dialog box, so that:
if the window in which the "Filter:" button lives goes away, so
does the filter dialog box (as it no longer has a text widget
into which it can stuff the selected filter);
if the "Filter:" button is clicked when there's already a filter
dialog box open, we just reactivate that existing dialog box
rather than popping up a new one.
Also keep a pointer to the "global" filter dialog box, so that we also
arrange that there's only one of them (by reactivating the existing on
if "Edit:Filters" is selected when there's already a "global" filter
dialog box open).
Keep around pointers to the dialog boxes that contain the "Filter:"
buttons, so that we can arrange that there be only one of them (that was
a side-effect of an earlier attempt at fixing the problems described
above, but it's still useful for keeping multiple competing dialog boxes
from being open - there's more of that to be done).
Make the pointer to the "Open Capture File" dialog box widget static to
"file_dlg.c" - nobody outside of "file_dlg.c cares about it.
svn path=/trunk/; revision=1774
Declare the one routine exported by "gtk/filter_prefs.c" in
"gtk/filter_prefs.h" rather than in "gtk/main.h". Declare
"E_FILT_TE_PTR_KEY" there, as well, rather than in "prefs_dlg.h", as the
filter-editing dialog box is no longer a preference tab.
Don't include "prefs_dlg.h" unless the stuff declared therein is of
interest.
Fix "gtk/find_dlg.c" to fire up the filter-editing dialog box, not the
no-longer-extant preferences tab for filters, if the "Filter:" button is
clicked.
svn path=/trunk/; revision=1619
whether, in a live capture that updates the display as packets arrive,
the packet list pane should scroll to show the most recently captured
packets or not.
svn path=/trunk/; revision=1506
to "util.c", and provide a routine to free that list as well.
When picking an interface on which to do a capture (if no "-i" flag was
specified), use that routine, and pick the first interface on the list.
svn path=/trunk/; revision=1495
even if it's empty, rather than using an empty string instead of it if
it's empty.
Also, "gtk_entry_get_text()" appears, from the documentation, always to
return a non-null pointer (and it returned a non-null pointer when I
started a capture with an empty filter string); don't supply a null
string if it's null, just do a "g_assert()" to make sure it's non-null.
Put in a comment explaining why we aren't trying to be clever and
detecting an empty filter string and setting "cf.filter" to NULL if it's
empty.
svn path=/trunk/; revision=1423
dialog box if we hadn't found any interfaces on which we could capture,
but perhaps the problem was that "gtk_combo_set_popdown_strings()"
doesn't like it if you set the list of items to a NULL list - if you
don't set it at all, you get a combo box with only one blank entry in
the list, but you don't seem to get complaints from GTK+ 1.2.6, at
least.
Pop up the "Capture:Start" dialog box even if we don't find any
interfaces on which we could capture; at least this way, they won't just
get confronted with a
There are no network interfaces that can be opened.
Please check to make sure you have sufficient permission
to capture packets.
message box and no way to give us any more information other than "it
said 'There are no network interfaces that can be opened...'" - they can
at least try the interfaces that *should* work, and report the error
messages they get, giving us a better chance at figuring out what the
problem is.
Trim white space from the entry in that combo box, and, if there isn't
anything other than possibly white space, pop up a
You didn't specify an interface on which to capture packets.
message box and leave the dialog box up so that the user can supply an
interface name.
svn path=/trunk/; revision=1373
"Edit:Preferences" and put it directly under "Edit:Filters", and to add
an "Apply" button to it, which makes the currently selected filter the
current filter and applies it to the current capture.
svn path=/trunk/; revision=1275
into "gtk/ui_util.c", and move the declarations of those UI utilities
out of "util.h" into "ui_util.h". (The header file is in the top-level
directory, rather than the "gtk" directory, because it declares
window-system-independent interfaces to routines with
window-system-dependent implementations.)
Add to "gtk/ui_util.c" a routine to set the window and icon title.
Use that routine to make the title of an Ethereal top-level window be
{filename} - Ethereal
if there's a capture open, and have "{filename}" be "<capture>" if it's
a temporary capture file.
svn path=/trunk/; revision=1255
set the capture length on IRIX, may fail if the capture length supplied
is too large, rather than just truncating it. Use MIN_PACKET_SIZE,
rather than WTAP_MAX_PACKET_SIZE, in our sample open.
Let's hope some *other* platform doesn't barf if the capture length is
too *small*....
(Sigh. Would that "pcap_open_live()" accepted 0 as a capture size,
meaning "give me the whole packet". Unfortunately, it doesn't, so IRIX
users may have to crank the capture size back in the capture dialog
box.)
svn path=/trunk/; revision=1239
file to which to write the capture; if it's NULL, create a temporary
file and use that.
Have "-w" set a local variable, which starts out null, and, for "-k"
captures, call "do_capture()" and pass it that local variable as an
argument; this lets you do "-k" without "-w", which makes it use a
temporary file for the capture.
This means "run_capture()" no longer serves a useful purpose, as its
only caller is "do_capture()"; swallow it into "do_capture()".
svn path=/trunk/; revision=748
- Capture->Start->"Active name resolution"
Allows the user to turn on/off name resolution
during a live capture.
- Display->Options->"Name resolution"
Turn on/off name resolution for the displayed
data (or during the -S mode).
E.g. clicking on a packet captured with
resolution disabled will resolve names in
the detailed list if this option is set.
And applying or resetting a display filter
allows the update of the packet list as well.
svn path=/trunk/; revision=726
list of packets in real time" in the "Capture/Start" dialog box,
"ethereal -F" won't work - you get your choice of non-forked capture or
"-S".
Don't have "fork_mode" track "sync_mode"; instead, in those places where
we check for "fork_mode", check for "sync_mode" as well.
svn path=/trunk/; revision=711
and to fork off and run a separate copy of "ethereal" for "-S" and "-F"
captures or just call "capture()" otherwise, out of "gtk/capture_dlg.c"
and into a routine in "capture.c".
If the attempt to create said temporary capture file fails, pop up a
dialog box and don't do the capture.
Have the child capture process send a message upstream after it either
successfully starts the capture and syncs out the header of the capture
file, or fails to start the capture; the message indicates whether it
succeeded or failed, and, if it failed, includes a failure message.
This:
avoids the use of a signal, and thus means we don't have to
worry about whether to capture the signal, or whether to start
or stop capturing depending on whether this particular capture
is in sync mode or not;
lets us pop up the message box for the error in the parent
process if we're in sync mode, rather than doing it in the
child, which didn't work well.
Add a check button to the Capture/Start dialog box, so that we can
control, for each capture, whether it's to be done in sync mode or not.
svn path=/trunk/; revision=708
now in "gtk/capture_dlg.c" - so it doesn't need to include
<sys/sockio.h> on, for example, Solaris...
...but "gtk/capture_dlg.c" does need to include it.
"gtk/capture_dlg.c" also may need to include "snprintf.h", as it uses
"snprintf()".
svn path=/trunk/; revision=655
Guy Harris