to the raw packet data, don't use "cf->pd" - "cf->pd" doesn't contain
the packet data when the file is being read in, it only contains it when
we're re-reading packets.
svn path=/trunk/; revision=1728
the row for that frame, and using that to get the frame for the selected
row in "select_packet()", revives the crash caused by the GtkCList
selecting the first row added to the list as it's added, i.e. before we
get a chance to set the data for that row, in this case.
Introduce a workaround for this instance of that crash.
svn path=/trunk/; revision=1711
which means we're already doing a "do something to the last row in the
packet list" operation on every frame we add to the list, so adding a
call to "gtk_clist_set_row_data()" won't make matters worse.
In addition, we already set one column in a row on a "change time
format" operation, so finding the row for a frame by calling
"gtk_clist_find_row_from_data()" doesn't turn a constant-time operation
into a linear-time operation, it just cranks the proportionality
constant up - it was quadratic before, alas, and it's still quadratic.
Adding calls to "gtk_clist_find_row_from_data()" to the "Find Frame" and
"Go To Frame" code does add an extra linear operation there, but those
operations shouldn't be common - and "Go To Frame", going to the last
frame on an ~100,000-frame big capture file, was quick, at least on my
450 MHz Pentium II machine, so maybe it won't be too bad.
And "select_packet()" either has to search the frame table for the frame
with the specified row number, or has to call "gtk_clist_get_row_data()"
to do that - the first is linear in the position of the frame in the
frame table, and the latter is linear in its position in the CList, and
the latter is less than or equal to the former, so the only thing making
it worse would be a change in the proportionality constant.
So it probably won't hurt performance by much.
Furthermore, if we add the ability to sort the display on an arbitrary
column, or to delete frames from the display - both of which are in the
wish list - storing the row number of the frame in the "frame_data"
structure won't necessarily work, as the row number can change out from
under us.
Therefore, reinstate the old way of doing things, where we associate
with each row a pointer to the "frame_data" structure for the row, using
"gtk_clist_set_row_data()".
svn path=/trunk/; revision=1703
routine to be called every time a new capture file is opened instead of
calling it in read_cap_file() and do_capture().
svn path=/trunk/; revision=1651
capture file for an unsupported link-layer encapsulation type (as the
nettl reader does), and report it correctly if it occurs on an open or
read attempt rather than a save attempt.
svn path=/trunk/; revision=1647
This function is used to re-initialize the hash table used by the X.25
dissector to record the upper layer protocol used by each VC. The hash
table should be re-initialized each time we read / start a new capture.
I moved the definition of the function from packet.h to packet-x25.h, and
added calls to reinit_x25_hashtable() in read_cap_file (file.c) and
do_capture (capture.c).
svn path=/trunk/; revision=1644
packets and doesn't change the capture file format, i.e. that's done by
a raw copy, read the file in binary. (XXX - does "creat()", on Win32,
open the file in ASCII or binary mode? If ASCII, we may have to use
open(fname, O_CREAT|O_TRUNC|O_WRONLY|O_BINARY, 0644)
rather than
creat(fname, 0644)
so that the output file is written in binary as well.)
svn path=/trunk/; revision=1599
pointer to the name of the file to which it refers (i.e., to the last
component of the pathname) in a "get_basename()" routine, and have the
code in "file.c" call it.
svn path=/trunk/; revision=1552
packets displayed", not just "if there aren't any packets" - there may
be packets but no displayed packets if the display filter didn't find
any packets.
NULL out the pointers to the first and last displayed packet when
closing a capture file.
svn path=/trunk/; revision=1548
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
file, not when filtering or colorizing packets - filtering shouldn't
change the frame number of a frame (yes, this means that a filtered
display won't necessarily have packets numbered contiguously 1 through N
- that's a feature).
svn path=/trunk/; revision=1456
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
will just give it the value it's always had, as packets are counted
regardless of whether they pass the filter or not (which is what we
want).
Given that, so there's no need for a separate "cf->unfiltered_count"
value, so get rid of it and use "cf->count" instead.
svn path=/trunk/; revision=1441
number to 0, so that "select_packet()" will find it if a "select-row"
signal is emitted when it's added.
(The previous workaround for this problem worked when initially
constructing the list of all frames, but not when reconstructing the
list of displayed frames when filtering packets, as, in the latter case,
there could be more than one frame in the list of all frames, so we
couldn't just say "pick the one and only frame in the list". The row
number is set to the correct value after the frame is added to the list
of displayed frames and we know the row number it was given.)
svn path=/trunk/; revision=1416
of routines to enable and disable various sets of menu items; call only
those routines, not routines to enable or disable particular menu items,
from files in the top-level directory, as other UIs may not refer to
menu items with path strings of the sort used in GTK+, and as this
buries knowledge of the menu items available in "gtk/menu.c" rather than
requiring stuff outside of "gtk/menu.c" to know what menu items exist.
svn path=/trunk/; revision=1410
GTK_SELECTION_BROWSE mode - that mode apparently always arranges that
there is (in a non-empty GtkCList) one row selected, which means that
when the first row is added, it selects it.
Unfortunately, that causes a "select-row" signal to be emitted, which
causes "select_packet()" to be called - but we haven't yet set "fd->row"
for the frame we're adding, so "select_packet()" can't find the frame
for the row being selected, and it aborts.
This causes a core dump when the first packet arrives during an "Update
list of packets in real time" capture.
For now, we handle this by, if we don't find the frame with the given
row number, checking that there's exactly one frame in our list of
frames and, if so, saying that frame is the frame for which we're
looking.
svn path=/trunk/; revision=1409
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
"file.c" to "packet.c"; it's not really related to file access (or to
manipulating the packet list as a whole, which much of the stuff in
"file.c" is really for), but is more related to analyzing packets, and
moving it to "packet.c" lets me build an experimental "line-mode" flavor
of Ethereal (based on Gilbert's "tethereal" experiment) - "line-mode"
means "like tcpdump or snoop" - without having to drag in "file.c" and a
pile of GUI stuff.
svn path=/trunk/; revision=1388
"Colorize Display" dialog box is created, and let it be destoryed when
that dialog box is destroyed.
When moving color filters up or down, update the (order of the elements
in the) list of color filters, as well as the CList that displays them.
If we have a "Colorize Display" dialog box open, and the user selects
"Display:Colorize Display", raise the existing window, rather than
creating a new window. (Alas, GTK+ doesn't have a call to request that
the window be given the input focus, so we can't do that as well.)
Fix up some names to be more consistent and to better reflect what the
variables/routines are for.
svn path=/trunk/; revision=1361
color filters check whether it's null to decide if there are any color
filters to apply.
Make "color_filter()" act on that list - there really aren't multiple
lists of color filters, there's only one list ("read_filters()" and
"write_filters()" acts only on one global list - and always has, as they
handled only one file).
svn path=/trunk/; revision=1359
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
WTAP_ENCAP_PER_PACKET, if there's more than one type of packet in the
file, or could be WTAP_ENCAP_UNKNOWN, if the file is of a type that
doesn't put an encapsulation type in the file header, and it has no
packets), we just need to call "wtap_file_encap()" when we're done
reading the file.
svn path=/trunk/; revision=1205
*" as an argument, there's no need to save the file type string in a
"capture_file" structure - we save the file type, and can use that when
generating the summary display.
svn path=/trunk/; revision=1202
"wtap_file_type_string()" take, as its argument, a file type, rather
than a "wtap *".
Fix some range checks of file types to check against WTAP_NUM_FILE_TYPES
rather than WTAP_NUM_ENCAP_TYPES.
svn path=/trunk/; revision=1201
if a "File:Save" or "File:Save As" fails - the message box it pops up
when that happens tells you that, it didn't do so before the change to
add the ability to save only the packets currently being displayed, and
putting that message in the status bar hides the normal message telling
you what the current file is (and it's still the current file, if the
save failed).
svn path=/trunk/; revision=1171
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
"capture.c", along with the other code that deals with the sync pipe.
Close the sync pipe, and get rid of the temporary capture file, on
errors.
Split "tail_cap_file()" into routines to set up to read from the capture
file, to read a specified number of packets from it when told to do so
by the child process, and to read the rest of the capture file and
finish up the capture, to provide the code in "capture.c" the hooks it
needs.
Have a common routine to set the status bar to report the file name and
number of dropped packets, to use both when reading in a capture file in
its entirety all at once and when done with a "read it while the capture
is writing to it" live capture.
svn path=/trunk/; revision=1137
regardless of whether we were displaying it in real time or not; if we
were displaying it in real time, activate "File/Save", rather than
"File/Save As", when it finishes.
svn path=/trunk/; revision=1135
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
Guy Harris