may be redrawing a packet window that displays a frame other than the
current frame; give it arguments to specify the raw frame data and
"frame_data" structure for the frame.
This requires that each packet window have, associated with it, a
pointer to the "frame_data" structure; that replaces the "cap_len" and
"encoding" fields in a "PacketWinData" structure, as those are just
copies of fields from the frame's "frame_data" structure.
"packet_hex_print()" needn't be passed both the start and length values
from a "field_info" structure - just pass it a pointer to that
structure, or NULL for "no field is selected in the packet". It also
needn't, any longer, be passed the "cap_len" and "flags.encoding" fields
of a "frame_data" structure - just pass it a pointer to that structure.
In "redraw_hex_dump_all()", don't redraw the hex dump pane of the main
window if there is no current frame.
svn path=/trunk/; revision=2404
the text in all "Follow TCP Stream" windows;
the text in the help window if we have one up;
all hex dump windows;
when GUI preference changes are to be applied, so that font changes and
"Follow TCP Stream" color changes show up.
Update both the Roman and bold font when the font is changed.
Don't decrement the reference counts on the old Roman and bold fonts
until that's all done.
svn path=/trunk/; revision=2401
highlighting of the bytes, in the hex dump window, corresponding to a
selected field.
Also, make "remember_ptree_widget()" static, as it's not used outside
"gtk/proto_draw.c".
svn path=/trunk/; revision=2399
This allows the display of a short field description (and
field abbreviation) in the status bar when a field is selected
in the protocol tree window.
The description is the blurb field when available (i.e. not empty),
the name otherwise.
When the item is unselected, the file context (e.g. the file name)
is restored.
Now it is much easier to build a display filter without the manual ;-)
svn path=/trunk/; revision=2343
Currently, it allows the selection of the foreground and
background colors of the marked frames but it could be
extended further (e.g. color of normal frames).
Add update_marked_frames() in main.c to update the
display (e.g. colors) of marked frames.
svn path=/trunk/; revision=2339
color of marked frames.
They are currently only available from preferences file,
but I will add the color selection in GUI later.
svn path=/trunk/; revision=2327
the Edit menu which allow you to:
- mark (or unmark) the currently selected frame
- mark all _displayed_ frames
- unmark all _displayed_ frames
Should I be more precise in the menu label ?
(e.g. "Mark All Displayed Frame" instead of "Mark All Frames"
and "Mark Selected Frame" instead of "Mark Frame" ?)
svn path=/trunk/; revision=2325
the middle mouse button. The marked packets are displayed in
reverse video but this should change in the future (the color
should be configurable via the GUI).
Then, the marked packets can be saved (via the "Save as"
window dialog).
Other features will be added in the future (I am waiting for
your comments and wishes).
svn path=/trunk/; revision=2322
- have popup_menu_handler return TRUE or FALSE according
to the fact that the event is really processed or not.
- use gtk_signal_connect instead of gtk_signal_connect_object
to have the widget that emitted the signal _and_ the popup
menu widget.
- call gtk_signal_emit_stop_by_name to abort the propagation
if the signal was processed.
svn path=/trunk/; revision=2318
"cancel", and "delete" methods, give them:
"fetch" - fetch from the notebook tab any values not already
stored in "prefs", and store them there, but doesn't apply them;
"apply" - apply the settings in "prefs";
"destroy" - clean up any windows created from the tab.
As we no longer have "cancel" methods, we don't have per-preference code
to revert preference values; instead, we have the common preference
dialog box code make a copy of all the current preferences, and, when
the "Cancel" button is clicked, free the current preferences and copy
the saved preferences to it, and apply the preferences.
Add an "Apply" button to the preference dialog box, which applies the
current preferences without closing the dialog box.
Treat a request to delete the preferences dialog box as equivalent to
clicking "Cancel".
Have a "remember_ptree_widget()" routine to remember all protocol tree
widgets, and use the list of those widgets when we set GUI preferences
for the protocol tree widgets, rather than setting the main protocol
tree widget and then using the list of packet windows. Move that code
out of "main.c" to "proto_draw.c", as it's not used by anything in
"main.c", but is used by stuff in "proto_draw.c".
Make the font one of the preferences we can set on the fly for protocol
tree widgets. Also make it something we can set on the fly for the
packet list widget.
svn path=/trunk/; revision=2316
uses "normal" rather than "medium" as the weight name for normal-weight
fonts; map "normal", as well as "medium", to "bold" when constructing
the name of the bold version of a font.
svn path=/trunk/; revision=2306
generate the name of the boldface font from the Roman font; if the two
fonts don't have the same widths, the display will look weird when a
field is selected, and it's a bit of a pain for the user to have to
select *two* fonts.
On UNIX/X, default to
"-*-fixed-medium-r-semicondensed-*-*-120-*-*-*-*-*-" rather than to
"-*-lucidatypewriter-medium-r-normal-*-*-120-*-*-*-*-iso8859-1" - some
Linux distributions appear to lack the Lucida typewriter font.
Add a "gui.font_name" preference to the preferences file, specifying the
normal-weight font to use. Have it settable from the "GUI" tab in the
Preferences dialog box - the "Font..." button, when clicked, pops up a
font selection dialog box.
If we either can't open the selected font or the boldfaced version of
the font, default to "6x13" and "6x13bold" as fallbacks - the former
will probably be "fixed", and the latter would be "fixedbold" if X
actually created such an alias, but it doesn't so we use "6x13bold"
instead.
svn path=/trunk/; revision=2304
explicitly; the right thing to do was to have
"remember_scrolled_window()" catch the "destroy" signal on the scrolled
window widget, and have the handler for that signal forget the scrolled
window.
Doing that obviates the need to have creators of scrolled windows keep
track of the windows they have and forget them when they're destroyed.
The signal for a "the window manager has requested that this window go
away" event is "delete_event", not "delete-event"; fix the
"gtk_signal_connect()" calls that were using "delete-event".
svn path=/trunk/; revision=2284
selection mode of the packet list window isn't actually going to be
changed - it's a bit annoying to have the protocol tree window clear out
from under you if all you've done is pop up the Edit->Preferences dialog
and cancelled it (or accepted it without changing any GUI preference).
svn path=/trunk/; revision=2280
at the correct notebook page when a particular protocol (which has registered
some preferences) is selected in the tree view.
- add set_menus_for_selected_tree_row() in menu.[ch]
- add prefs_is_registered_protocol() and
prefs_get_title_by_name() in prefs.[ch]
svn path=/trunk/; revision=2275
- 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
file to a user-specified file.
Move the file-copy routine in save_cap_file() to an indepenent
function in file.c (copy_binary_file()) so that follow_dlg.c can use it.
Remove #include "follow.h" from the C files that don't need it.
svn path=/trunk/; revision=2200
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
a word to use in the progress dialog, and a flag indicating whether the
display filter is to be reevaluated or not, and:
have "colorize_packet()" call that routine with "Colorizing" and
FALSE as those arguments;
have the filtering code call that routine with "Filtering" and
TRUE as those arguments;
add an exported routine to call that routine with "Reprocessing"
and TRUE as those arguments, to use to re-generate the packet
list and to re-filter the packets if a protocol preference has
been changed.
Keep track of whether preferences are changed from their initial value
by a preferences file or a command-line option, or from their previous
value by the "Preferences" dialog box; have "prefs_apply_all()" only
call the "apply" callback for a module if they have.
Call "prefs_apply_all()" after the command-line arguments have been
parsed and after "OK" has been clicked in the "Preferences" dialog box,
to notify modules of preference changes if they've registered a callback
for that.
After "OK" has been clicked in the "Preferences" dialog box, if any
preferences have changed, call the reprocessing routine, as the summary
line for some frames and/or the current display filter's value when
applied to some frames may have changed as a result of a preference
change. Do the same after "OK" or "Apply" has been clicked in the
"Display Options" dialog box (as it controls a protocol preferences
item.
svn path=/trunk/; revision=2126
same directory as the "manuf" file ("/etc" or "/usr/local/etc", most
likely).
Add a mechanism to allow modules (e.g., dissectors) to register
preference values, which:
can be put into the global or the user's preference file;
can be set from the command line, with arguments to the "-o"
flag;
can be set from tabs in the "Preferences" dialog box.
Use that mechanism to register the "Decode IPv4 TOS field as DiffServ
field" variable for IP as a preference.
Stuff that still needs to be done:
documenting the API for registering preferences;
documenting the "-o" values in the man page (probably needs a
flag similar to "-G", and a Perl script to turn the output into
documentation as is done with the list of field);
handling error checking for numeric values (range checking,
making sure that if the user changes the variable from the GUI
they change it to a valid numeric value);
using the callbacks to, for example, update the display when
preferences are changed (could be expensive);
panic if the user specifies a numeric value with a base other
than 10, 8, or 16.
We may also want to clean up the existing wired-in preferences not to
take effect the instant you tweak the widget, and to add an "Apply"
button to the "Preferences" dialog.
svn path=/trunk/; revision=2117
potentially long-running operation that has a progress indicator, pop up
a modal dialog box with
an indication of what is being done;
a progress bar;
a "Cancel" button to stop the operation.
This:
leaves more room on the status line for a filter expression;
provides a mechanism to allow the user to cancel long-running
operations (although the way we do so may not back out of them
as nicely as the user might like, if it's not obvious what the
"right" way is or if the "right" way is difficult to implement
or involves doing as much work as letting the operation
continue);
means that, because the dialog box is modal, we don't have to
worry about the user performing arbitrary UI operations out from
under the operation and changing arbitrary bits of state being
used by that operation.
svn path=/trunk/; revision=2103
a pointer to the "wtap_pkthdr" structure for an open capture
file;
a pointer to the "wtap_pseudo_header" union for an open capture
file;
a pointer to the packet buffer for an open capture file;
so that a program using "wtap_read()" in a loop can get at those items.
Keep, in a "capture_file" structure, an indicator of whether:
no file is open;
a file is open, and being read;
a file is open, and is being read, but the user tried to quit
out of reading the file (e.g., by doing "File/Quit");
a file is open, and has been completely read.
Abort if we try to close a capture that's being read if the user hasn't
tried to quit out of the read.
Have "File/Quit" check if a file is being read; if so, just set the
state indicator to "user tried to quit out of it", so that the code
reading the file can do what's appropriate to clean up, rather than
closing the file out from under that code and causing crashes.
Have "read_cap_file()" read the capture file with a loop using
"wtap_read()", rather than by using "wtap_loop()"; have it check after
reading each packet whether the user tried to abort the read and, if so,
close the capture and return an indication that the read was aborted by
the user. Otherwise, return an indication of whether the read
completely succeeded or failed in the middle (and, if it failed, return
the error code through a pointer).
Have "continue_tail_cap_file()" read the capture file with a loop using
"wtap_read()", rather than by using "wtap_loop()"; have it check after
reading each packet whether the user tried to abort the read and, if so,
quit the loop, and after the loop finishes (even if it read no packets),
return an indication that the read was aborted by the user if that
happened. Otherwise, return an indication of whether the read
completely succeeded or failed in the middle (and, if it failed, return
the error code through a pointer).
Have "finish_tail_cap_file()" read the capture file with a loop using
"wtap_read()", rather than by using "wtap_loop()"; have it check after
reading each packet whether the user tried to abort the read and, if so,
quit the loop, and after the loop finishes (even if it read no packets),
close the capture and return an indication that the read was aborted by
the user if that happened. Otherwise, return an indication of whether
the read completely succeeded or failed in the middle (and, if it
failed, return the error code through a pointer).
Have their callers check whether the read was aborted or not and, if it
was, bail out in the appropriate fashion (exit if it's reading a file
specified by "-r" on the command line; exit the main loop if it's
reading a file specified with File->Open; kill the capture child if it's
"continue_tail_cap_file()"; exit the main loop if it's
"finish_tail_cap_file()".
svn path=/trunk/; revision=2095
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, not as a text file; that makes no difference on UNIX, but, as the
file *is* binary, it makes a difference on Win32 systems.
svn path=/trunk/; revision=2086
there's no need to keep it around in memory - when the frame data is
read in when handing a frame, read in the information, if any, necessary
to reconstruct the frame header, and reconstruct it. This saves some
memory.
This requires that the seek-and-read function be implemented inside
Wiretap, and that the Wiretap handle remain open even after we've
finished reading the file sequentially.
This also points out that we can't really do X.25-over-Ethernet
correctly, as we don't know where the direction (DTE->DCE or DCE->DTE)
flag is stored; it's not clear how the Ethernet type 0x0805 for X.25
Layer 3 is supposed to be handled in any case. We eliminate
X.25-over-Ethernet support (until we find out what we're supposed to
do).
svn path=/trunk/; revision=1975
display to be sorted by the value in that column (and to reverse the sort
order the next time you click on that column).
Use "F<>" rather than "B<>" for file names in the Ethereal man page.
svn path=/trunk/; revision=1931
console-subsystem program, so that when not run from a shell window it
doesn't cause a shell window to be popped up. (Yes, this means that any
messages it prints, when not popped up from a shell window, get lost,
but the same is true of Ethereal on UNIX/X.) Trick for doing this
shamelessly stolen from the Win32 port of the GIMP.
We do not want to build Tethereal or editcap as Windows-subsystem
programs, however, so we take the "/SUBSYSTEM" flag out of LDFLAGS and
put it into the link commands for Ethereal, Tethereal, and editcap.
svn path=/trunk/; revision=1857
it in SOCKS dissector.
(Okay, how many times am I going to modify packet.h today, forcing you
to re-compile everything? :-)
svn path=/trunk/; revision=1850
"dissect_init()" and "dissect_cleanup()", in "packet.c", so that we
don't duplicate those routines in Ethereal and Tethereal (and so on),
and don't have to remember to update N different versions of them if we
have to change the way we do one-time initialization and cleanup.
svn path=/trunk/; revision=1790
registration routines to get rid of the special handling of ONC RPC
protocols - dissectors for ONC RPC-based protocols should register their
protocol, fields, and ETT values in a protocol registration routine, and
register themselves with the ONC RPC dissector in their protocol handoff
routine, so that the latter is done after the ONC RPC dissector's
protocol registration routine is called, so that the data structures
needed when dissectors for ONC RPC protocols register themselves with
the ONC RPC dissector have been initialized.
Get rid of "init_dissect_rpc()", which initializes said data structures;
do that in "proto_register_rpc()" instead.
svn path=/trunk/; revision=1789
hash table attached to "udp.port" out of "init_dissect_udp()" into
"proto_register_udp()", so that it's done the way TCP does it, and then
get rid of "init_dissect_udp()".
svn path=/trunk/; revision=1781
"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
Stream" windows - the window should always be deleted in that situation,
so there's no need for a signal handler that might return TRUE (meaning
"don't delete the window"), and the "destroy" handler gets called when
the window actually gets destroyed, so there's no need to do any cleanup
in the "delete_event" handler.
Catch the "delete_event" signal on the main window in a routine with the
right signature, and that returns FALSE so that the window actually gets
deleted.
Call "close_cap_file()" in the callback for the "File:Quit" menu item
(which is also called by the "delete_event" handler for the main
window), rather than calling it after "gtk_main()" returns -
"close_cap_file()" manipulates stuff in the main window, and if we do so
after "gtk_main()" returns, it appears that the main window may have
disappeared (if we are exiting because the user deleted the main
window), in which case we can get crashes or other errors when
"close_cap_file()" tries to manipulate stuff in the main window.
There's no need to catch the "destroy" signal on the main window - we do
some of the cleanup in the handler for "delete_event" (we have to, for
reasons described above), and we do the rest of it after the main
routine returns.
svn path=/trunk/; revision=1773
routines we register get called.
Register the "follow TCP stream" windows with "gtk_quit_add_destroy()",
so that, when Ethereal exits, they all get destroyed; this means that
their destroy callbacks get called, which means that they get to delete
their temporary files, so that, if you exit Ethereal without manually
closing the "follow TCP stream" windows, the temporary files don't get
left around.
Exit from Ethereal's "main()" function by calling "gtk_exit()", rather
than "exit()", so that we do whatever cleanup GTK+ requires. (We used
to call "gtk_exit()" in the callback for the "File:Quit" menu item and
the "delete" callback for the main window, but we now just call
"gtk_main_quit()" so that we exit from the main loop.)
svn path=/trunk/; revision=1772
Ethereal/win32 now supports command-line options.
Tethereal now compiles on win32, except for the fact that I haven't
put the Makefile.nmake changes in for that yet.
svn path=/trunk/; revision=1758
the "Follow TCP Stream" displays; that means we can use the same GTK+
calls to set the scrollbar placement on them that is used to set it on
other widgets.
Keep a list of all the GtkScrolledWindows whose scrollbar placement we
control with the GUI preference item for that, and change them all when
the GUI preference item is changed (which means that the GUI preference
item now applies to the "Follow TCP Stream" window as well as to the
hex/ASCII panes).
svn path=/trunk/; revision=1676
call "close_cap_file()", which will unlink the current capture file if
it's a temporary file - but will do so after closing it; certain OSes
whose names begin with "W" don't let you remove a file if it's currently
open, so if you exit Ethereal, without closing the capture first, after
doing a capture on one of those OSes, the temporary file won't be
removed.
svn path=/trunk/; revision=1628
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
at the end of follow_read_stream(), which causes a segfault if you change
the TCP Follow screen to EBCDIC, and then go back and select a TCP packet.
svn path=/trunk/; revision=1578
either a pointer to the directory part of the pathname (after stomping
on the pathname separator with a '\0', so don't use this on pathnames
you plan to use afterwards), or NULL if the pathname contains no
directory part, and make it handle Win32 pathnames on Win32 systems.
Use it to get the containing directory of the currently open file, so
that the "chdir()" stuff we do to cause the "File:Open" dialog box to
show you files in the directory in which you last looked works on Win32
systems.
svn path=/trunk/; revision=1555
the IPv4 TOS field as a TOS field or as a DiffServ field, and allow that
field to be controlled by a command-line option or an option in the
"Display:Options" dialog box.
svn path=/trunk/; revision=1532
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
or to Ethereal when the "-k" flag is specified, i.e. when a capture is
to be started immediately, use "pcap_lookupdev()" to pick an interface,
just as tcpdump does.
svn path=/trunk/; revision=1482
with MSVC 6.0 and 'nmake', the make tool that comes with MSVC.
It compiles, links, and runs. It doesn't run correctly. There's a problem
when reading files. I'm getting short reads. I'm not linking in zlib or
libsnmp because it first needs to be debugged.
I changed the plugin code to use gmodule instead of libltdl, but the
Unix build still links ethereal against libltdl. I'll fix that tonight; sorry
about leaving it in such a sad state, but I wanted to check in this code
before I left work on a Friday night. Ethereal still works, but the
building is less than optimal.
svn path=/trunk/; revision=1479
displays the contents of the TCP connexion in hexadecimal.
The two opposite directions of the conversation are displayed side by side.
svn path=/trunk/; revision=1454
into "gtk/column_prefs.c".
Get rid of "get_column_width()" - instead, export
"get_column_longest_string()", and have "get_column_width()"'s callers
make the GDK call to get the width of that string, so that "column.c"
contains no GTK+/GDK code.
svn path=/trunk/; revision=1447
print only the actual stream data, not the address and port binary
information.
Fix it to handle the ASCII/EBCDIC selection as well.
svn path=/trunk/; revision=1427
Add a "Save status" button to the Plugins window which saves the status
(enabled/disabled) and the filter used by all the plugins in
~/.ethereal/plugins.status
Moved plugins_scan_dir() from gtk/plugins_dlg.c to plugins.c because it is
GUI independent. Read plugins.status in this function and restore the saved
status.
Add a init_plugins() function in plugins.c which calls plugins_scan_dir() in
order to build the plugin_list. It is called by ethereal_proto_init() in
gtk/main.c
svn path=/trunk/; revision=1417
In order to use GTK_SELECTION_BROWSE correctly, I had to set auto_resize
to TRUE for the GtkCTree column.
Yes, I'm using terminology that's opposite that of GTK+.
When I say the selection bar "browses", I mean that you can browse the rest
of the widget with an outline selection bar, without changing the
selection. This corresponds to mode GTK_SELECTION_SINGLE.
When I say "select", I mean that the arrow keys change the selection.
This corresponds to mode GTK_SELECTION_BROWSE.
Go figure. But I like my terminology better.
svn path=/trunk/; revision=1398
I did this:
First, Havoc Pennington, in "GTK+/Gnome Application Development", in
Appendix seciton A.3.88, recommends using GtkCTree instead of GtkTree
because GtkCtree is faster, and GtkTree has limitation on its total row
height: since it must fit inside a GdkWindow, it is limited to 32,768
pixels of height. GtkTree is more flexible with regards to the types of
widgets that can be placed in the tree, but since we deal only with text,
that doesn't matter, at least for now.
Secondly, a GtkTree doesn't allow arrow-key navigation (at least as far
as I could tell). It always bothered me that the up and down arrow keys
worked in the packet list and in the hex dump, but no in the protocol tree.
GtkCTree does allow arrow-key navigation. In fact, GtkCTree is a subclass
of GtkCList (the packet list widget), so they behave a lot alike.
I went ahead and fixed the selection bar which has been bothering Richard
for a long time now. :) In the GUI preferences dialogue, you can now set
both the packet list selection bar and the protocol tree selection bar
to either "browse" or "select" mode. "browse" mode is what you're used to:
the arrow keys move an outline of the selection bar, but do not change
the selection. "select" mode does change the selection when the arrow keys
are pressed. The default behavior is set to "select", which seems more
natural for a first-time user.
svn path=/trunk/; revision=1393
option right now is the placement of the vertical scrollbars in the 3 panes.
(it's one decision; you can't have the placement of the vertical scrollbar
in the packet list pane different than the placement in the protocol tree
pane, for example).
I did this because I find it convenient to have the vertical scrollbars
on the *left* side of the text. My mouse cursor is usually expanding and
collapsing the protocol tree widgets, and once the protocol tree changes
size, I usually have to scroll. I'd rather move my mouse cursor just a few
pixels over to find the vertical scrollbar.
svn path=/trunk/; revision=1351
at all since the GtkText widget does not scroll horizontally (it says
so in the GTK+ docs and in the gtktext.c file in the GTK+ distribution).
Even if the Ethereal window is shrunk horizontally, the text widget will
line wrap (we could turn that off, but it just truncates the line, instead
of making the text widget horizontally-scrollable).
Also, change the packet list scrollbar policy to AUTOMATIC so that scroll
bars only appear when needed. This is how the protocol tree pane has
been configured already.
svn path=/trunk/; revision=1308
window is extended veritically, either up or down, the packet list
and hex dump pane sizes stay the same, and the protocol tree pane
is the one that grows. Hurrah! Of course you can still modify the
size of each pane with the little separator between each pane.
svn path=/trunk/; revision=1307
"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
Don't list capture-oriented flags in the usage message if Ethereal was
built without "libpcap".
If a capture-oriented flag is given to an Ethereal built without
"libpcap", print a message noting that and give a usage message.
Print only one usage message, even if more than one bad command-line
flag is given.
svn path=/trunk/; revision=1236
treat CONNECT as an HTTP request;
add DELETE and OPTIONS as request names.
Make the order of names in the AUTHORS file match that of the man page
and the About box.
svn path=/trunk/; revision=1231
loading a new file from within ethereal.
In main(), cf_name was being set to optarg, without g_strdup()'ing it.
Later, in file_open_cmd_cb(), we try to g_free last_open_dir, which is
cf_name, so blammo! We try to g_free something that we can't.
So, in main(), be sure to set cf_name to a g_strdup() of optarg, not
just optarg.
(At home I'm using debug/development versions of glib/gtk, so maybe
that's why I saw the problem only now. I could have sworn that I
have done this sequence of events successfully before).
svn path=/trunk/; revision=1180
packets that are currently being displayed from that capture.
Centralize the code to control whether "File:Save" and "File:Save As"
are enabled (and *always* have "File:Save As" enabled if you have a
capture; "File:Save" is enabled only if you have a live capture you've
not yet saved, although it does the same thing as "File:Save As").
Have the "save_file" member of a "capture_file" structure represent
*only* the file currently being *written* to by a capture, and, if there
is no capture currently in progress, have it be NULL; the name of the
file currently being *displayed" is in the "filename" member, and an
"is_tempfile" member indicates whether it's a temporary file for a live
capture or not.
Have "close_cap_file()" delete the current capture file if it's a
temporary capture file that hasn't been saved (in its entirety - saving
selected frames doesn't count). Do the same (if there *is* a current
capture file) when exiting.
The "Ready to load or capture" message is the only statusbar message in
the "main" context; "close_cap_file()" should never pop it, it should
only pop whatever message exists in the "file" context, and thus has no
need to take, as an argument, the context for the message it should pop.
Update the man page to reflect the new behavior of "File:Save" and
"File:Save As", and to reflect recent changes to "Display:Match Selected".
svn path=/trunk/; revision=1170
"capture_file" - when handed a "capture_file *", it only cared about the
"colors" entry. The only time it cares about a "capture_file" is when
it's actually filtering the packets, as it needs to hand the
"capture_file *" to "colorize_packets()".
Make the stuff exported by "colors.c" in "colors.h" take "colfilter *"
arguments (or return a "colfilter *" to be stuffed into a
"capture_file").
svn path=/trunk/; revision=1162
CMU SNMP library was linked in and, if one of them was, information
about the version of the library, if that information is available.
svn path=/trunk/; revision=1140
the history of display filters. If it is deemed useful to put the filter in
the histor of filters also, then I can do that.
When Match Selected produces byte-range display filters (field[x:y] == x.y.z),
use notation without length, since the length is no longer needed.
(field[x] == x.y.z is produced)
When Match Selected prodcues a filter for FT_ETHER's, use ether_to_str()
instead of sprintf().
svn path=/trunk/; revision=1112
Document changes in this version.
Add Greg to ever-growing list of authors (he was in AUTHORS, but not
in manpage nor in main.c)
svn path=/trunk/; revision=1097
of SNA in a packet changes the character encoding from the default ASCII
to EBCDIC.
The hex-printing routines in the GUI code and in the printing code convert
to EBCDIC if appropriate.
svn path=/trunk/; revision=1089
ip_to_str() is 7 times faster than my sprintf() implementation (both of
which take very little time for the single call that match_selected() makes,
but you know....)
svn path=/trunk/; revision=1071
field's name, if possible. (If the selected field is not a registered field,
then of course, we still have to use the frame[x:y] syntax).
tree_selected_start and tree_selected_len are on longer globals variables;
finfo_selected has replaced them.
svn path=/trunk/; revision=1070
Rename the dissector for the Netware SAP protocol to "dissect_ipxsap()",
so as to keep its name from colliding with that of the dissector for the
Session Announcement Protocol.
svn path=/trunk/; revision=1046
hex window to scroll so that the data in the currently-selected field is
visible, but merely revealed core-dumping bugs in GTK+.
svn path=/trunk/; revision=1040
store the field_info pointer, from which we can get both "start" and
"length" (and "hfinfo" and "value", which I'm working towards, so that
match_selected, or a new function, and create a display filter based on
the field's name, instead of byte offset ).
svn path=/trunk/; revision=1039
colors.c wasn't freeing path in one place
main.c wasn't freeing rc_file
the frame_buffer fix in wtap.c didn't clear everything.
svn path=/trunk/; revision=1001
filter to search forward or backward in the list of displayed frames for
a matching frame.
When filtering the display, readjust the display to show the "current"
frame if it passed the display filter. When a file is read in, the
first frame becomes the "current" frame; when a frame is selected, it
becomes the "current" frame, and remains so *even if you unselect it*,
until another frame is selected.
Select the first frame when a file is read in.
Disable most of the "Display" and "Tools" menu items if there's no
current capture file, and enable the relevant ones if there is.
svn path=/trunk/; revision=982
structure to "dl_src"/"dl_dst", "net_src"/"net_dst", and "src"/"dst"
addresses, where an address is an address type, an address length in
bytes, and a pointer to that many bytes.
"dl_{src,dst}" are the link-layer source/destination; "net_{src,dst}"
are the network-layer source/destination; "{src,dst}" are the
source/destination from the highest of those two layers that we have in
the packet.
Add a port type to "packet_info" as well, specifying whether it's a TCP
or UDP port.
Don't set the address and port columns in the dissector functions; just
set the address and port members of the "packet_info" structure. Set
the columns in "fill_in_columns()"; this means that if we're showing
COL_{DEF,RES,UNRES}_SRC" or "COL_{DEF,RES,UNRES}_DST", we only generate
the string from "src" or "dst", we don't generate a string for the
link-layer address and then overwrite it with a string for the
network-layer address (generating those strings costs CPU).
Add support for "conversations", where a "conversation" is (at present)
a source and destination address and a source and destination port. (In
the future, we may support "conversations" above the transport layer,
e.g. a TFTP conversation, where the first packet goes from the client to
the TFTP server port, but the reply comes back from a different port,
and all subsequent packets go between the client address/port and the
server address/new port, or an NFS conversation, which might include
lock manager, status monitor, and mount packets, as well as NFS
packets.)
Currently, all we support is a call that takes the source and
destination address/port pairs, looks them up in a hash table, and:
if nothing is found, creates a new entry in the hash table, and
assigns it a unique 32-bit conversation ID, and returns that
conversation ID;
if an entry is found, returns its conversation ID.
Use that in the SMB and AFS code to keep track of individual SMB or AFS
conversations. We need to match up requests and replies, as, for
certain replies, the operation code for the request to which it's a
reply doesn't show up in the reply - you have to find the request with a
matching transaction ID. Transaction IDs are per-conversation, so the
hash table for requests should include a conversation ID and transaction
ID as the key.
This allows SMB and AFS decoders to handle IPv4 or IPv6 addresses
transparently (and should allow the SMB decoder to handle NetBIOS atop
other protocols as well, if the source and destination address and port
values in the "packet_info" structure are set appropriately).
In the "Follow TCP Connection" code, check to make sure that the
addresses are IPv4 addressses; ultimately, that code should be changed
to use the conversation code instead, which will let it handle IPv6
transparently.
svn path=/trunk/; revision=909
added misc. constants for parsing flags, and converting time
stamps;
added flags and primary sources explanations;
added function for converting time stamps;
improved item analysis;
new item definitions;
from Tomislav Vujec.
svn path=/trunk/; revision=908
than a command name of "ethereal-dump-fields", to decide whether to run
as normal Ethereal or to just dump out the list of fields that can be
used in a display filter.
This allows us to continue to make that check without doing the regular
command line flag parsing (which we don't want to do, as we don't want
to call "gtk_init()" before making that check, as "gtk_init()" tries to
open an X display, and some people want not to have to have X running in
order to build Ethereal, or want not to have Ethereal try to open an X
connection over a slow line if it's just going to print field names to
the standard output), without having to make a link to "../ethereal"
from the "doc" directory (said link couldn't be a hard link, as ATK
apparently disallows hard links between directories, and I have the
vague impression that a symbolic link might cause other problems).
svn path=/trunk/; revision=902
return the pointer to the compiled filter through a pointer argument.
Have it check whether the filter is a null filter and, if so, free up
the filter and supply a filter pointer, rather than obliging its callers
to check whether the filter actually has any code. (Well, they may want
to check if the filter is null, so that they don't save a pointer to the
filter text, e.g. so that the display filter displays as "none" rather
than as a blank string in the summary box.)
In the process, fix the check in "gtk/file_dlg.c" that tests whether the
read filter compiled successfully.
svn path=/trunk/; revision=812
"cf.dfcode" if the new filter doesn't compile, because the filter
currently in effect will be the one that was last applied - just free up
the text of the new filter, and whatever memory was allocated for the
new filter code.
This means we allocate a new dfilter when a new filter is to be applied,
rather than recycling stuff from the old filter, as we want the old
filter code to remain around if the new filter doesn't compile.
This means that "cf.dfilter" and "cf.dfcode" will be null if there's no
filter in effect.
svn path=/trunk/; revision=803
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 is done; make it do so, and don't bother passing it a "-Q" flag
to tell it to do so.
"capture()" is called in two places; in one place, it's in a child
process, and it shouldn't read in the capture file. Move the reading of
the capture file out of "capture()" itself to the place where we
*should* read in the capture file after it returns. Also, have it
return an indication of whether it succeeded or failed, so we know
whether we should read in the capture file.
svn path=/trunk/; revision=747
"quit_after_cap", and "capture_child" from "gtk/main.c" to "capture.c",
so that the definitions don't have to be duplicated in "main.c" for
other UIs if, as, and when we do versions of Ethereal with other UIs.
svn path=/trunk/; revision=746
process for a sync mode or fork mode capture.
Have that flag control whether we do things that *only* the parent or
*only* the child should do, rather than basing it solely on the setting
of "sync_mode" or "fork_mode" (or, in the case of stuff done in the
child process either in sync mode or fork mode, rather than basing it on
the setting of those flags at all).
Split "do_capture()" into a "run_capture()" routine that starts a
capture (possibly by forking off and execing a child process, if we're
supposed to do sync mode or fork mode captures), and that assumes the
file to which the capture is to write has already been opened and that
"cf.save_file_fd" is the file descriptor for that file, and a
"do_capture()" routine that creates a temporary file, getting an FD for
it, and calls "run_capture()".
Use "run_capture()", rather than "capture()", for "-k" captures, so that
it'll do the capture in a child process if "-S" or "-F" was specified
("do_capture()" won't do because "-k" captures should write to the file
specified by the "-w" flag, not some random temporary file).
For child process captures, however, just use "capture()" - the child
process shouldn't itself fork off a child if we're in sync or fork mode,
and should just write to the file whose file descriptor was specified by
the "-W" flag on the command line.
All this allows you to do "ethereal -S -w <file> -i <interface> -k" to
start a sync mode capture from the command line.
svn path=/trunk/; revision=740
popped up the top-level window (so that it looks like a capture
started from "Capture/Start");
initialized the colors (so that we don't dump core when reading
in the capture file);
popped up any message box for failure to read the preferences
file.
This means we start the capture in "main()", rather than in the realize
callback for the main window, so get rid of that callback.
If we're a child process that's just capturing to a file for our parent
to read, however, we shouldn't pop up the top-level window, because
that's our parent's job; when running that child, set its "argv[0]" to a
special name, so that
1) it shows up in a "ps" with a special name;
2) we don't have to invent Yet Another Flag to say "you're the
child".
(We may want to use the name to turn on *all* behaviors that the capture
child, and only the capture child, should exhibit.)
If "-w" and "-k" were both specified, attempt to open the file specified
by "-w" and, if that succeeds, set "cf.save_file_fd" to refer to it, so
that "-w" plus "-k" works again, rather than popping up a "The file to
which the capture would be saved ... could not be opened: Bad file
descriptor." message box.
svn path=/trunk/; revision=739
current capture file if it's a temporary file, out of paranoia (so that
we don't get into a state where we have a capture file open but unlinked
- it's probably harmless to be in that state, as the file will remain
around until close, modulo NFS fun, and we may never be in that state
for very long, but I'd rather have it obviously stated in the code).
Remove the close in "capture()", and put one before the other call to
"capture()", in "main_realize_cb()" (is that call necessary, e.g. if you
pass "-r <filename>" *and* "-k", for some perverse reason, as
command-line arguments?).
If "cf.save_file" is non-null, free it before setting it, regardless of
whether it refers to a temporary file name or not.
svn path=/trunk/; revision=712
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
gzip. The zLib library is used for this purpose. If zLib is not available
(or it's use is disabled by the --disable-zlib option to configure), you
can still compile Ethereal but it will be unable to read compressed capture
files.
IMPORTANT:
Now all file accesses to capture files should be done through special macros.
Specifically, for any use of the following functions on capture files, replace them.
The arguments for the right-side functions are exactly the same as for the
original stdio functions.
fopen file_open
fdopen filed_open
fread file_read
fwrite file_write
fseek file_seek
fclose file_close
ferror file_error
svn path=/trunk/; revision=695
prints the protocol tree, and summary prints the fields in the summary
clist, with a header line at the beginning of the printout.
Print only packets selected by the current packet filter.
Just have "ARP" and "RARP" in the "Protocol" field for ARP packets;
whether it's a request or a reply can be seen in the "Info" field.
Add to the "Frame" section of the protocol tree the time between the
current packet and the previous displayed packet, and the packet number.
Have FT_RELATIVE_TIME fields be a "struct timeval", and display them as
seconds and fractional seconds (we didn't have any fields of that type,
and that type of time fits the delta time above).
Add an FT_DOUBLE field type (although we don't yet have anything using
it).
svn path=/trunk/; revision=666
Guy Harris