"ip_checksum_shouldbe()" compute the correct checksum given the computed
whole-packet checksum and the value of the checksum field; that scheme
can be better extended in the future to handle checksums other than the
IP header checksum, e.g. ICMP, UDP, and TCP checksums (although we'd
want a somewhat more optimized checksumming routine for that, and
perhaps have an option to control whether to do checksum checking on TCP
and UDP packets, as that could be expensive).
That requires that we remember the value of the computed checksum, not
just check it against 0; that renders "ip_checksum_state()"
uninteresting, as we can just compare the value against 0 in line.
svn path=/trunk/; revision=2210
have "ip_checksum()" compute the checksum of the IP header;
have "ip_checksum_state()" call "ip_checksum()" and then return
TRUE if the result is 0 and FALSE otherwise;
have "ip_checksum_shouldbe()" save the current value of the
checksum field in the header, set that field to 0, call
"ip_checksum()" to get the checksum, restore the value of the
checksum field in the header to the saved value, and then return
what "ip_checksum()" returned;
rather than having duplicated code to compute checksums.
svn path=/trunk/; revision=2206
compile it, find their info at the top of the file.
Explain the generated sources for developers, and the Unix-ish tools that
are needed.
svn path=/trunk/; revision=2205
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 test whether a file the user selected to be opened from the file
selection box is really a directory (so that we can point the file
selection box at it, rather than trying to open the directory as a
capture file, which wouldn't work), use the routine in question.
To make the GTK+ file selection box start out in the last directory from
which we opened a file, use "gtk_file_selection_complete()", rather than
"chdir()"ing to that directory.
Those changes keep us from "chdir()"ing all over the place; that way, if
Ethereal dumps core, the core dump shows up in the directory from which
it was run, rather than in the directory from which you last opened or
into which you last saved a file.
svn path=/trunk/; revision=2190
the C run-time library sets "statb.st_mode" appropriately, at least for
plain files and directories; it just doesn't offer the POSIX "S_ISxxx()"
macros to test the file type.
If those macros aren't defined (which might also be the case on really
ancient UNIX systems), define them appropriately, and use them even on
Win32 systems, so that we can properly report attempts by a user to read
from a directory on Win32, just as we do on UNIX.
svn path=/trunk/; revision=2188
defined on Win32 systems - it's not defined in <sys/types.h> on those
systems.
In "buffer.c", include "config.h", to cause HAVE_WINSOCK_H to be
defined, on systems that have it, so that we include it in <buffer.h>.
svn path=/trunk/; revision=2187
"guint32" rather than "uint32_t" so that it'll compile on systems (e.g.,
Win32, and probably some UNIX flavors) that don't declare "uint32_t".
svn path=/trunk/; revision=2185
capture.c :
- modified capture() to try to open an interface as a pipe if pcap_open_live()
failed, and then read data in libpcap format from this pipe ;
- add new functions used by capture() : pipe_open_live() and pipe_dispatch()
which are equivalents to the pcap_ functions.
libpcap.[ch] :
- moved the MAGIC and headers definitions from libpcap.c to libpcap.h
because capture() now needs it.
svn path=/trunk/; revision=2181
as a cause for the RST, as per RFC 1122:
4.2.2.12 RST Segment: RFC-793 Section 3.4
A TCP SHOULD allow a received RST segment to include data.
DISCUSSION
It has been suggested that a RST segment could contain
ASCII text that encoded and explained the cause of the
RST. No standard has yet been established for such
data.
Thanks and a tip of the Hatlo hat to Kevin Steves of HP for mentioning
this on the tcpdump-workers list (he contributed a tcpdump patch to do
the same).
svn path=/trunk/; revision=2178
argument of "Undefined(%d)"; just use "val_to_str()" (and use "%u"
rather than "%d", as the value passed to it is unsigned).
svn path=/trunk/; revision=2177
a framework for the dissector; of the more than 400 NCP packet types, only
a handful are defined. But this dissector framework is much better than
the previous one.
svn path=/trunk/; revision=2173
a waste of time. Instead, set $(PERL) to @PERL_PATH@ in the Makefile and
call dfilter2pod.pl via $(PERL) $(src_dir)/dfilter2pod.pl
svn path=/trunk/; revision=2171
indicating the string length. It's available only with proto_tree_add_item().
Add proto_item_get_len(), so that dissectors can find out how long
the FT_NSTRING_UINT8 turned out to be.
In proto_tree_add_item(), don't add a proto_item to the proto_tree until
*after* the attempt to pull data from the tvbuff. That way, if the tvbuff
raises an exception, an item with garbage data won't be left in the
proto_tree.
svn path=/trunk/; revision=2167
1) aclocal expects autoconf/automake macros to be hidden;
2) GTK+ hid its autoconf/automake macros;
and, if both places exist but aren't the same directory, returns a "-I"
flag to tell aclocal to look in GTK+'s directory.
Then have "autogen.sh", and Makefiles in directories with "acinclude.m4"
files, use that script and pass what flag it supplies, if any, to
aclocal.
This should, I hope, avoid problems such as those FreeBSD systems where
GTK+ was installed from a port or package (and thus stuck its macros in
"/usr/X11R6/share/aclocal") but aclocal doesn't look there.
(It doesn't solve the problem of somebody downloading and installing,
say, libtool from source - which means it probably shows up under
"/usr/local", with its macros in "/usr/local/share/aclocal" - on a
system that comes with aclocal (meaning it probably just looks in
"/usr/share/aclocal", but that may be best fixed by, whenever you
download a source tarball for something that's part of your OS,
configuring it to install in the standard system directories and
*overwriting* your OS's version.)
svn path=/trunk/; revision=2165
is finally dead, and you're walking away, it springs up again and
attacks.
It appears that the ss990915 version of Alexey Kuznetzov's libpcap patch
has some extra stuff in the per-packet header for some sort of SMP
debugging, and that SuSE Linux 6.3 picked it up.
Thus, even if a libpcap file has the modified magic number, we *still*
have to go through the usual heuristic hell to figure out what type of
file it is.
svn path=/trunk/; revision=2164
package build targets. Move ethereal.spec(.in) to packaging/rpm.
The spec file is different from Henri's. We might want to switch to his
for the sake of consistency.
svn path=/trunk/; revision=2162
Guy Harris