at the end of follow_read_stream(), which causes a segfault if you change
the TCP Follow screen to EBCDIC, and then go back and select a TCP packet.
svn path=/trunk/; revision=1578
if I correctly read the Windows NT DDK documentation on WAN drivers, for
PPP as well - an ISO NLPID, so use the "nlpid.h" values where they
exist.
Currently doesn't treat NLPID_PPP as PPP, but if we get a PPP-over-X.25
capture, we may find that it should do so.
svn path=/trunk/; revision=1577
traces. The trace we got from Tom Poe (tomp@intrex.net) contains PPP
data which NetXRay has transformed into looking like Ethernet frames.
The hardware addresses are the bytes for the ASCII reprsentation of
"SRC" and "DEST", with null pad bytes at the end. Interesting.
svn path=/trunk/; revision=1576
timeval" (if, say, it's a "struct bpf_timeval", with member sizes wired
to 32 bits, as it appears to be in SuSE 6.3 and will, I think, be in the
0.5 release of libpcap), copy the members of that field to the "ts"
field of the Wiretap per-packet header (which also lets us make it not a
"struct timeval" as well).
svn path=/trunk/; revision=1572
supposed to look like "ftell()".
If you don't have zlib, just define "file_seek" as an alias for "fseek",
rather than defining it as a routine.
svn path=/trunk/; revision=1571
The files were created by Frederic Peters <fpeters@debian.org>, the maintainer
of the ethereal debian package.
I just modified `rules' to use autogen.sh when building from a CVS tree.
Building a debian package is now very easy :
- in debian/changelog : change the version number (and replace my name with
yours)
- dpkg-buildpackage -rfakeroot -us -uc
svn path=/trunk/; revision=1569
well as before reading a capture file - if the user didn't specify that
the capture should be saved to a file, it'll be dissected as it arrives.
svn path=/trunk/; revision=1568
either a pointer to the directory part of the pathname (after stomping
on the pathname separator with a '\0', so don't use this on pathnames
you plan to use afterwards), or NULL if the pathname contains no
directory part, and make it handle Win32 pathnames on Win32 systems.
Use it to get the containing directory of the currently open file, so
that the "chdir()" stuff we do to cause the "File:Open" dialog box to
show you files in the directory in which you last looked works on Win32
systems.
svn path=/trunk/; revision=1555
is bigger than a "long"; this is itojun's fix for that, turning
"file_tell()" into a wrapper function in "file_wrappers.c", just like
"file_seek()".
svn path=/trunk/; revision=1554
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
one is loading, we dump core. Add the "Open..." menu item to the list of
items that we disable while a file is loading.
svn path=/trunk/; revision=1551
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
directly; it should use them through Wiretap. (Arguably, it shouldn't
use "file_open()", "file_dopen()", or "file_close()" directly, and
should use those through Wiretap as well.)
svn path=/trunk/; revision=1540
the IPv4 TOS field as a TOS field or as a DiffServ field, and allow that
field to be controlled by a command-line option or an option in the
"Display:Options" dialog box.
svn path=/trunk/; revision=1532
"fd->cap_len" for the frame length - or to use macros such as
"BYTES_ARE_IN_FRAME()", "IS_DATA_IN_FRAME()", and "END_OF_FRAME", which
use "pi.captured_len" - so that they correctly handle frames where the
actual data length of the packet is less than the size of the raw frame,
e.g. with encapsulations such as ISL.
svn path=/trunk/; revision=1531
"fd->cap_len" for the frame length - or to use macros such as
"BYTES_ARE_IN_FRAME()", "IS_DATA_IN_FRAME()", and "END_OF_FRAME", which
use "pi.captured_len" - so that they correctly handle frames where the
actual data length of the packet is less than the size of the raw frame,
e.g. with encapsulations such as ISL.
svn path=/trunk/; revision=1530
Gilbert Ramirez