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
encapsulation/data-link type to 16 bits, and shuffle some fields to
eliminate some unnecessary padding - the net result should be no change
in the structure size for 32 bits and a few bytes removed for 64 bits.
This allows more encapsulation types - we've just about run out of the
ones that fit in a signed 8-bit integer - and thus should fix bug 5025.
svn path=/trunk/; revision=33613
This patch is cut&paste code from gtk/main_packet_list.c:packet_list_compare()
to new function frame_data_compare()
+ it make use of new function inside packet_list_compare() and
packet_list_compare_records()
svn path=/trunk/; revision=29164
This patch optimizes the data source name processing in add_new_data_source()
by delaying it. We now simply store the constant string and lazily compute the
name when needed. This gives a performance boost because we only need the name
if we have multiple data sources.
svn path=/trunk/; revision=29066
- Change apply / prepare / ... as filter to use the field's value, which
is now stored in fdata as well as cinfo. Now we don't have to reprocess
the entire packet list when using these features. This also prevents
the use of these features from overwriting custom column information.
(custom columns can now be used in apply / prepare ... as filter)
- Break col_expr and col_expr_val out into a struct that is included not only
in cinfo, but now also fdata.
- Have col_custom_set_fstr() quote FT_STRING & FT_STRINGZ when storing the
col_expr_val value (for filter creation).
svn path=/trunk/; revision=24511
Fix for bug #491: Unexpected frame.time_delta behavior
This patch ... fixes bug 491. It does this by changing the
behaviour of the frame.time_delta field so it reflects the delta
time between captured packets (tshark already did this). To keep
the delta time between displayed packets, the field
frame.time_delta_displayed is created.
svn path=/trunk/; revision=21154
"unknown" for frame numbers. Note that in epan/frame_data.h, and make
the frame number in experts unsigned, and use 0 for "unknown", and
display it as an unsigned number - and, if it's 0, don't display it at
all.
Fix the signature of "expert_dlg_draw()" to match what a tap's draw
routine's signature is expected to be.
svn path=/trunk/; revision=15760
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
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
filter's colors" bug, by storing the pointer to the matching color_filter_t
structure in the frame_data structure.
Replace "frame" and "frames" by "packet" and "packets" in many places.
svn path=/trunk/; revision=9607
One can now select a packet and mark it as a TimeReference packet using the menu.
A TimeReference packet will be indicated by having all timestamp related column entries replaced by the string *REF*
A TimeReference packet will always be displayed in the packet pane, and overrides any display filters.
When a frame is a TimeReference frame, all later frames will calculate the TimeRelativeToFirstPacket relative to the timestamp of the TimeReference frame instead of the first frame of the capture.
You can have any number of TimeReference frames you like.
svn path=/trunk/; revision=8459
Ethereal presents a column to display culmulative bytes into the capture.
A new column type is added : Culmulative Bytes.
While PacketLength column type specifies the number of bytes in the current packet,
Culmulative Bytes specifies the culmulative number of bytes from the start of the capture.
svn path=/trunk/; revision=8359
While we're at it, add "extern" to a bunch of function declaration the
preceding change *didn't* require to have the "extern" added.
svn path=/trunk/; revision=5995
in the "packet_info" structure instead, as we don't need a pointer for
every single frame in the capture file, just for each frame for which we
currently have an open "epan_dissect_t".
svn path=/trunk/; revision=5614
"data source" has a name and a top-level tvbuff, and frames can have a
list of data sources associated with them.
Use the tvbuff pointer to determine which data source is the data source
for a given field; this means we don't have to worry about multiple data
sources with the same name - the only thing the name does is label the
notebook tab for the display of the data source, and label the hex dump
of the data source in print/Tethereal output.
Clean up a bunch of things discovered in the process of doing the above.
svn path=/trunk/; revision=4749
structure to the "packet_info" structure; only stuff that's permanently
stored with each frame should be in the "frame_data" structure, and the
"column_info" structure is not guaranteed to hold the column values for
that frame at all times - it was only in the "frame_data" structure so
that it could be passed to dissectors, and, as all dissectors are now
passed a pointer to a "packet_info" structure, it could just as well be
put in the "packet_info" structure.
That saves memory, by shrinking the "frame_data" structure (there's one
of those per frame), and also lets us clean up the code a bit.
svn path=/trunk/; revision=4370
Stig Bjørlykke