sequence of frame_data structures, indexed by the frame number. Extract
the relevant bits of the capture_file data structure and move them to
the frame_data_sequence, and move the relevant code from cfile.c and
tweak it to handle frame_data_sequence structures.
Have a possibly-null pointer to a frame_data_sequence structure in the
capture_file structure; if it's null, we aren't keeping a sequence of
frame_data structures (we don't keep that sequence when we're doing
one-pass processing in TShark).
Nothing in libwireshark should care about a capture_file structure; get
rid of some unnecessary includes of cfile.h.
svn path=/trunk/; revision=36881
This lets us get rid of the per-frame_data-structure prev and next
pointers, saving memory (at least according to Activity Monitor's report
of the virtual address space size on my Snow Leopard machine, it's a
noticeable saving), and lets us look up frame_data structures by frame
number in O(log2(number of frames)) time rather than O(number of frames)
time. It seems to take more CPU time when reading in the file, but
seems to go from "finished reading in all the packets" to "displaying
the packets" faster and seems to free up the frame_data structures
faster when closing the file.
It *is* doing more copying, currently, as we now don't allocate the
frame_data structure until after the packet has passed the read filter,
so that might account for the additional CPU time.
(Oh, and, for what it's worth, on an LP64 platform, a frame_data
structure is exactly 128 bytes long. However, there's more stuff to
remove, so the power-of-2 size is not guaranteed to remain, and it's not
a power-of-2 size on an ILP32 platform.)
It also means we don't need GLib 2.10 or later for the two-pass mode in
TShark.
It also means some code in the TCP dissector that was checking
pinfo->fd->next to see if it's NULL, in order to see if this is the last
packet in the file, no longer works, but that wasn't guaranteed to work
anyway:
we might be doing a one-pass read through the capture in TShark;
we might be dissecting the frame while we're reading in the
packets for the first time in Wireshark;
we might be doing a live capture in Wireshark;
in which case packets might be prematurely considered "the last packet".
#if 0 the no-longer-working tests, pending figuring out a better way of
doing it.
svn path=/trunk/; revision=36849
Make the loops that scan through all the packets do so by frame number,
to abstract away the "next" and "previous" pointers in the frame_data
structure. Add a routine to cfile.c to map frame numbers to frame_data
structures, and put in some special case handling so scanning forward or
backward through the packets is O(N) rather than O(N^2).
svn path=/trunk/; revision=36846
- Added traffic statistics for marked packages.
- Do not show Displayed column unless using it.
- Removed Marked packets line, as this info is in the marked packets column.
Will add documentation changes if keeping this feature.
svn path=/trunk/; revision=23633
setuid instead of Wireshark. Remove the "DANGEROUS" notices, but leave it
disabled by default. Whine if the user runs Wireshark or TShark as root.
Add a preference to disable the whining. Add a "setuid-root" script that
can be used to switch dumpcap and TShark's setuid-ness on and off for
development and testing. Update the release notes and README.packaging.
svn path=/trunk/; revision=22733
Try to call get_interface_descriptive_name() as little as possible (storing
the result in capture_opts) to avoid a performance hit during live capture
(especially if you have lots of interfaces) and to avoid leaking memory.
One issue with this is that capture_opts.c cannot (without adding significant
dependencies) set the iface_descr so readers of that field (only gtk/main.c
and tshark.c) use a macro to (set if not already set and) get the value of
that field.
svn path=/trunk/; revision=22587
I've done more than a day to change the timestamp resolution from microseconds to nanoseconds. As I really don't want to loose those changes, I'm going to check in the changes I've done so far. Hopefully someone else will give me a helping hand with the things left ...
What's done: I've changed the timestamp resolution from usec to nsec in almost any place in the sources. I've changed parts of the implementation in nstime.s/.h and a lot of places elsewhere.
As I don't understand the editcap source (well, I'm maybe just too tired right now), hopefully someone else might be able to fix this soon.
Doing all those changes, we get native nanosecond timestamp resolution in Ethereal. After fixing all the remaining issues, I'll take a look how to display this in a convenient way...
As I've also changed the wiretap timestamp resolution from usec to nsec we might want to change the wiretap version number...
svn path=/trunk/; revision=15520
data, so that "f_len" still keeps the size of the underlying file (which
is necessary in order to make the progress bar when files are being read
work correctly).
svn path=/trunk/; revision=15415
move another two capture related fields (iface and cfilter) from cfile to capture_opts
also move the handling of capture related command line options from main.c to capture.c, that way a future privilege seperated capture program can use the same code to parse it's command line than Ethereal.
It might be even possible to share this parser code even with Tethereal, didn't took a closer look at this.
svn path=/trunk/; revision=13320
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
packets that passed the current display filter, as well as about the
entire capture.
Document the Tools:Summary item in the man page.
Update Gerald's e-mail address.
svn path=/trunk/; revision=8344
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
capturing; if we succeed, display the packet drops count as the "Drops"
value in the status line and as the "Dropped packets" statistics in the
summary dialog box, otherwise don't display it at all.
In Tethereal, attempt to get the packet statistics from libpcap when
capturing; if we succeed, and if there were any dropped packets, print
out the count of dropped packets when the capture finishes.
svn path=/trunk/; revision=3016
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
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
for example, you're doing a live capture with "Update list of packets in
real time" and none have arrived yet, or if you've read in a capture
file where there aren't actually any packets), don't look for the start
or stop time, and don't accumulate the number of captured bytes or the
number of packets that passed the display filter.
svn path=/trunk/; revision=1394
summary.c now provides a struct of info (see summary.h)
Changed the name of the summary dialogue callback (hence the change
in menu.c), and added a close button to the dialogue.
Moved #include <gtk/gtk.h> out of print.c and into prefs.h where it
was needed for GdkColor.
svn path=/trunk/; revision=1273
*" 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
"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
in dfilter-grammar.y) to a new struct dfilter. Display filters now have
their own struct, rather than simply being GNode's. This allows multiple
display filters to exist at once, aiding John McDermott in his
work on colorization.
svn path=/trunk/; revision=480
N^2 in the ultimate size of the list (as "g_list_append()" is linear in
the size of the list, at least when used in the way the GLib
documentation says to use it); instead, maintain our own linked list of
"frame_data" structures for all packets read, including a pointer to the
last element.
"gtk_clist_set_row_data()" is linear in the row number, so if it's used
to attach a pointer to the "frame_data" structure for a packet to the
packet list GtkClist row for each packet, that's also N^2 in the number
of packets in that packet list; instead, store the row number in the
"frame_data" structure, and find the packet for a given row by scanning
the list for it (we were already scanning the list linearly to find that
packet's index in the list of all packets; that's only done when a
packet's selected, so it's not *too* bad, but it might be nice to avoid
having to do that scan).
svn path=/trunk/; revision=457
wiretap support for RADCOM Ltd.'s WAN/LAN analyzers (see
http://www.radcom-inc.com/
). Note: as I remember, IEEE 802.2/ISO 8022 LLC has somewhat of an SDLC
flavor to it, just as I think LAP, LAPB, LAPD, and so on do, so we may
be able to combine some of the LLC dissection and the LAPB dissection
into common code that could, conceivably be used for other SDLC-flavored
protocols.
Make "S" a mnemonic for "Summary" in the "Tools" menu.
Move the routine, used for the "Tools/Summary" display, that turns a
wiretap file type into a descriptive string for it into the wiretap
library itself, expand on some of its descriptions, and add an entry for
files from a RADCOM analyzer.
Have "Tools/Summary" display the snapshot length for the capture.
svn path=/trunk/; revision=416
display filter code, which uses features in GLIB-1.2.x), I removed
the vestigial code supporting old 1.0.x and 1.1.x GTK+ versions.
svn path=/trunk/; revision=360
but does not link. Perhaps someone who understands the MS tools can help
out. I made it link a few months ago, but with different version of glib/gtk+.
I can't remember how I made it link.
Most of the compatibility issues were resolved with adding
#ifdef HAVE_UNISTD_H the the source code. Please be sure to add this to all
future code.
svn path=/trunk/; revision=359
doesn't link with libpcap, so no packet captures can be made. The
"--disable-pcap" option has been added to the configure script. Docs
have been updated. And the string buffer size in the simple_dialog()
has been doubled so that Johan's e-mail address in the "About" dialogue
window doesn't get chopped off.
svn path=/trunk/; revision=351
mechanism that is built into ethereal. Wiretap is now used to read all
file formats. Libpcap is used only for capturing.
svn path=/trunk/; revision=342
NetMon statistic packets for now. We might fix that problem with wiretap,
either filtering out those packets, and/or providing the summary
information through a new wiretap API.
svn path=/trunk/; revision=326
Michael Tüxen