that you can tell from examination whether the search is forward or
backward.
Make the cf_find_packet routines take the direction as an explicit
argument, rather than, in the cases where you don't want to permanently
set the direction, saving the direction in the capture_file structure,
changing it, doing the search, and restoring the saved direction. Give
more information in the Doxygen comments for those routines.
Add a cf_find_packet_dfilter_string() routine, which takes a filter
string rather than a compiled filter as an argument. Replace
find_previous_next_frame_with_filter() with it.
Have cf_read_frame_r() and cf_read_frame() pop up the error dialog if
the read fails, rather than leaving that up to its caller. That lets us
eliminate cf_read_error_message(), by swallowing its code into
cf_read_frame_r(). Add Doxygen comments for cf_read_frame_r() and
cf_read_frame().
Don't have find_packet() read the packet before calling the callback
routine; leave that up to the callback routine.
Add cf_find_packet_marked(), to find the next or previous marked packet,
and cf_find_packet_time_reference(), to find the next or previous time
reference packet. Those routines do *not* need to read the packet data
to see if it matches; that lets them run much faster.
Clean up indentation.
svn path=/trunk/; revision=33791
- Add missing 'user_data' arg as needed;
- Use gboolean rather than int as the type of the value returned.
Also: Cleanup whitespace & reformat long lines in a few cases.
svn path=/trunk/; revision=33679
1) This indicates that the string has ephemeral lifetime
2) More consistent with its existing seasonal counterpart, se_address_to_str().
svn path=/trunk/; revision=29747
a protocol tree;
the column values.
This includes stats-tree listeners.
Have the routines to build the packet list, and to retap packets, honor
those requirements. This means that cf_retap_packets() no longer needs
an argument to specify whether to construct the column values or not, so
get rid of that argument.
This also means that there's no need for a tap to have a fake filter
to ensure that the protocol tree will be built, so don't set up a fake
"frame" filter.
While we're at it, clean up some cases where "no filter" was represented
as a null string rather than a null pointer.
Have a routine to return an indication of the number of tap listeners
with filters; use that rather than the global num_tap_filters.
Clean up some indentation and some gboolean vs. gint items.
svn path=/trunk/; revision=28645
is signed; make the flags field in "struct magnify" unsigned, and make
the flags unsigned, so we shift 1U rather than 1.
svn path=/trunk/; revision=25421
add the possibility, that a dissector writer can provide (usually non-trivial) display filters specific for the protocol in question (with an example in packet-dcerpc-pn-io.c), that will appear in the GUI
svn path=/trunk/; revision=22530
Fix compilation failures when building wireshark-0.99.6-SVN-21916 on an
x86_64-unknown-linux-gnu target with gcc version 4.1.2 20070403 (Red Hat
4.1.2-8).
The failures fall into two categories:
(1) Casts between pointers and 32-bit integers without an intermediary cast
via 'long' or 'unsigned long'. This results in a compiler warning complaining
about casts between a pointer and an integer of a different size.
(2) Passing values to "%lld" or similar printf-style format options that the
compiler thinks are a different size. Such values need to be cast to 'long
long' or 'unsigned long long'.
svn path=/trunk/; revision=21975
while this should improve performance by unmeasurably little it does have the sideeffect that once we finish the rewrite tcp analysis might actually work and work well even for tcp over tcp tunnelling.
this also means that if you include packet-tcp.h you also need to include emem.h .
svn path=/trunk/; revision=17681
drawing_area widgets. Instead of canoodling around with a global list
of graphs, simply associate a graph to its widgets using OBJECT_SET_DATA.
This should take care of Coverity CIDs 50 - 59.
Clean up whitespace.
svn path=/trunk/; revision=17554
This bug was discovered while looking at defects #130 and #131 discovered by coverity.
This patch also fixes these non-severe defects.
svn path=/trunk/; revision=17531
After investigating the time-sequence graphs (Stevens and tcptrace) produced
using an FTP capture file supplied by Eduardo Segura
(see http://www.ethereal.com/lists/ethereal-users/200512/msg00153.html )
I've identified several problems in tcp_trace.c.
The problems mostly involve incorrect determination of the lower/upper
sequence number bounds (for the Y axis) in certain cases (e.g. having to do
with 'partial' conversations).
I've reworked the '...get_bounds' code to handle cases such as:
1. out of order data segments (e.g.: the first segment in a captured
conversation has a higher sequence number than a later segment);
2. 'ack' sequence numbers for initial ack segments in a conversation lower
than the sequence numbers of the initial data segments;
3. maximum 'ack + win' sequence number in a conversation greater than the
max data sequence number;
4. Stevens graph: only use data segment sequence numbers when
determining bounds;
5. TCP RST packet without 'ack' flag: do not try to use the 'ack' seq num from
the packet in this case. (This was the specific cause of the originally reported
problem).
I've also reworked the tcptrace display code slightly to properly handle
the initial ack packet of a sequence;
As an example of the some of the fixes the Ethereal tcptrace style graph
of the following conversation fragment will now be similar to the graph
produced by Tcptrace.
data: seq 10000 len 100
data: seq 10100 len 200
ack: ack 5000 win 6000
ack: ack 5400 win 5600
svn path=/trunk/; revision=16874
directory to the epan directory. Some of them should perhaps ultimately
be moved to epan/dissectors, if they pertain only to stuff exported by a
particular dissector.
Fix Gerald's e-mail address in files we're moving.
svn path=/trunk/; revision=15844
Bill Meier