"gint8" - there's no reason for them to be signed, and making them
signed can cause compiler warnings if a value won't fit in 8 bits if
sign-extended.
svn path=/trunk/; revision=9467
except that the 0x80 bit is turned on in the file version number field.
Turn that bit off before processing that field.
svn path=/trunk/; revision=9342
errors when reading the header as indications that the file isn't an
AiroPeek V9 file.
Put in comments nothing some additional checks we should do.
svn path=/trunk/; revision=9145
snoop file unless it has enoguh padding to hold a Shomiti trailer
record. (DEAR SUN MICROSYSTEMS: PLEASE DO NOT STUFF 16 OR MORE BYTES OF
PADDING INTO A SNOOP PACKET. THANK YOU. HAVE A NICE DAY.)
Add a little paranoia about the record and captured data lengths.
svn path=/trunk/; revision=8883
2000, 00:00:00 *local* time. The amount to add to that is just the UNIX
time stamp value for that point in time; get it with "mktime()".
svn path=/trunk/; revision=8854
get rid of the reference to its "tm_gmtoff" member - there are platforms
on which Ethereal runs that don't have "tm_gmtoff" in "struct tm". If
the time stamp in the packets is nanoseconds since midnight 2001-01-01
*local* time, we'd need to compute the offset between that and midnight
2000-01-01 GMT, and adjust the time with that.
svn path=/trunk/; revision=8842
swap the "captured length" and "length" fields, to the open-file code;
store a tri-state (definitely swapped, definitely not swapped, maybe
swapped) value in the per-capture-file-format information for libpcap
format, and use that when processing packets.
svn path=/trunk/; revision=8774
recurse into subdirectories doing "nmake -f Makefile.nmake distclean".
Have "nmake -f Makefile.nmake clean" not remove stuff that "make clean"
doesn't remove (such as Flex/Bison output and config.h files) - and have
"nmake -f Makefile.nmake distclean" remove stuff that "make distclean"
removes, including "tethereal-tap-register.c" and
"ethereal-tap-register.c".
svn path=/trunk/; revision=8672
a UNIX version generating code that, by default, assumes you have
<unistd.h> (as might be the case with recent versions of Cygwin, which I
assume *does* supply <unistd.h>), but you're building on a platform that
lacks <unistd.h> (e.g., building with MSVC++ or MinGW), you can still
compile.
svn path=/trunk/; revision=8602
0 means "there is no FCS in the packet data", 4 means "there is an FCS
in the packet data", -1 means "I don't know whether there's an FCS in
the packet data, guess based on the packet size".
Assume that Ethernet encapsulated inside other protocols has no FCS, by
having the "eth" dissector assume that (and not check for an Ethernet
pseudo-header).
Have "ethertype()" take an argument giving the FCS size; pass 0 when
appropriate.
Fix up Wiretap routines to set the pseudo-header. This means we no
longer use the "generic" seek-and-read routine, so get rid of it.
svn path=/trunk/; revision=8578
0 means "there is no FCS in the packet data", 4 means "there is an FCS
in the packet data", -1 means "I don't know whether there's an FCS in
the packet data, guess based on the packet size".
Assume that Ethernet encapsulated inside other protocols has no FCS, by
having the "eth" dissector assume that (and not check for an Ethernet
pseudo-header).
Have "ethertype()" take an argument giving the FCS size; pass 0 when
appropriate.
Fix up Wiretap routines to set the pseudo-header. This means we no
longer use the "generic" seek-and-read routine, so get rid of it.
svn path=/trunk/; revision=8574
type, and telling them how it should *NOT* be done, i.e. you should ask
tcpdump-workers for a new DLT_ value, you should not just pick a value
on your own, and you should especially not reuse a value that's already
in use!
Put in comments about reserved values in the current CVS libpcap.
svn path=/trunk/; revision=8367
use WTAP_ENCAP_ATM_PDUS as the default encapsulation for ATM;
don't use ULL constants, as not all C compilers that support
gint64 support them, and as there's no need to make them ULL
constants.
svn path=/trunk/; revision=8278
a not-yet-ready-for-prime-time project of mine (fast random access to
gzipped files, plus an mechanism to allow support for other forms of
compression).
svn path=/trunk/; revision=8221
the MS Visual Studio debugger, get confused by two files with the same
name being in a program's source, even though they're in different
directories.
svn path=/trunk/; revision=8208