"unsigned short", "unsigned int" (or "int", as the items appear to be
unsigned), or "unsigned long".
Convert data to and from the appropriate byte order.
Don't free the private data structure in the dumper's close routine -
"wtap_dump_close()" does that for you.
svn path=/trunk/; revision=8094
the network type being 1 and the byte after it being 2; we assume, for
now, that the network type is 1 byte, and that if the byte after it is
0, the network type is an NDIS type - 1, and if it's 2, it's an NDIS type.
svn path=/trunk/; revision=7973
rathe than the record length minus the record header length, as the
number of available (captured) bytes in the packet. Check to make sure
that value isn't bigger than the record length minus the header length.
Only subtract the 4-byte FCS length from the purported length of the
packet on the wire if that would leave the on-the-wire length >= the
number of captured bytes, so that we can better handle capture files
from programs that produce LANalyzer-format captures where the
on-the-wire length *doesn't* include the FCS.
svn path=/trunk/; revision=7948
is pointless, as it's a 16-bit unsigned quantity. Remove those checks -
but note in a comment that WTAP_MAX_PACKET_SIZE must be at least 65535
(as there might well be link-layer types with packets at least that
large).
svn path=/trunk/; revision=7934
variables the user configures - the user isn't expected to change
GLIB_LIBS or GTK_LIBS, and there's a comment nothing that users
shouldn't have to do so), which contain the appropriate libraries for
building stuff that requires only GLib, and stuff that required GTK+ and
GLib, respectively, and use those macros in the Makefile.nmake files.
svn path=/trunk/; revision=7885
variables the user configures - the user isn't expected to change
GLIB_CFLAGS or GTK_CFLAGS, and there's a comment nothing that users
shouldn't have to do so), which contain the appropriate "/I" flags for
building stuff that requires only GLib, and stuff that required GTK+ and
GLib, respectively, and use those macros in the Makefile.nmake files.
svn path=/trunk/; revision=7884
matched if it succeeds, so that it gets re-read when we read the capture
file - it's a line containing a time stamp for a packet, so we need to
re-read it to get that time stamp.
svn path=/trunk/; revision=7752
line, not the "RCV packet" part, so that we recognize files even if they
don't have an "RCV packet" line in the first 200 lines.
svn path=/trunk/; revision=7699
value for DLT_PFLOG, and that goes along with a change to the link-layer
header for DLT_PFLOG - support both the old and new values and format.
svn path=/trunk/; revision=7676
Following fixes for nettl (HP-UX):
1) Fixed 11.X timestamp issue
there is no difference in 10.X/11.X timestamps, so no
need to shift 11.X timestamps
2) Fixed NS_LS_DRIVER trace record handling
now works rather than throwing "...network type that
Ethereal doesn't support" error
3) Fixed handling of traces with sliced packets (nettl -m xx)
now uses correct packet and capture lengths
4) Additional ethernet card support
now handles btlan[1,3-6],gelan,igelan,intl100 driver
trace records
svn path=/trunk/; revision=7642
Makefile.am:99: `YFLAGS' is a user variable, you should not override it;
Makefile.am:99: use `AM_YFLAGS' instead.
Fix it in the proposed way.
svn path=/trunk/; revision=7582
stuff I sent out in a mail message to somebody asking how to add support
for a new file format, but hopefully it'll get improved by various
contributors over time (hint hint).
svn path=/trunk/; revision=7397
aren't 1/1193000.0 second; the code used to use 1/1193180.0 second, but
at least one capture appears to have units of somewhere around
1/3579540.0 second.
svn path=/trunk/; revision=7388
2 the time stamps are in units of 1/31250000 seconds rather than
nanoseconds - and, by generating Windows Sniffer captures with various
hdr.timeunit values, that for all the non-zero values he tested, the
time stamps for non-gigabit pod captures are in units of 1/1193000
second.
Instead of having a TpS array, just test for the exception value (0 for
non-gigabit pod captures, 2 for gigabit pod captures).
svn path=/trunk/; revision=7380
type for loopback devices; map it to DLT_NULL when reading libpcap files
with a major version of 2 and a minor version of 2, and when capturing
from an "loN" device on AIX.
svn path=/trunk/; revision=7361
rename WTAP_ENCAP_ENC0 to WTAP_ENCAP_ENC.
un-#if 0 out the code to handle the value 109 for DLT_ENC, as I've just
checked in support for DLT_ENC in tcpdump.org libpcap and tcpdump, which
maps DLT_ENC to 109 in the file header.
Give packet-enc.c an RCS ID.
svn path=/trunk/; revision=7323
Add support for the OpenBSD enc(4) encapsulating interface. Add
support for Ethernet over IP (RFC 3378).
Fold Markus' .h files into their respective .c files, add a define to
ipproto.h and use it.
svn path=/trunk/; revision=7310
Add a bunch of capture types discovered by stuffing them into Windows
Sniffer captures and seeing what a Sniffer thought they were. Add
support for writing at least some of them.
svn path=/trunk/; revision=7265
it's a gigabit Ethernet capture, possibly, with special hardware, and
that time stamps have 1000 times the resolution that they have in other
captures (perhaps due to the special hardware having a higher-resolution
clock?).
svn path=/trunk/; revision=7240
Get rid of acconfig.h, as it's an archaism; put descriptions
into AC_DEFINE instead. That squelches some warnings from
later versions of autoconf.
Fix an unquoted call to AC_MSG_ERROR.
Move the stuff to define HAVE_SOME_SNMP into configure.in.
svn path=/trunk/; revision=7203
bytes of padding into the packet (possibly more, as if it's putting
extra stuff in the padding as Shomiti/Finisar Surveyor does, it might be
up to 7). Fortunately, Surveyor puts lots of stuff into the padding, so
we'll crank up the "snoop vs. Surveyor" check to look for 4 or more
bytes.
svn path=/trunk/; revision=7167
that have direction information.
Support writing WTAP_ENCAP_FRELAY_WITH_PHDR and WTAP_ENCAP_PPP_WITH_PHDR
captures out in libpcap format - we throw away the direction
information, but so it goes.
When reading/writing Windows Sniffer format, read and write the
direction flag.
svn path=/trunk/; revision=7052
configure option is given on the command line. The value of the arguement
is passwd in the enableval variable. The 4th argument tells what to do in
case no command line argument was given.
This causes --disable-gtk2 (which is the default) to behave differently
from the case when no option is given.
I do not really understand where the difference in the behaviour of the
generated codes comes from, but I definitely see a difference.
Fixed all occurrences where the 3rd arguement was empty.
svn path=/trunk/; revision=7044
addresses and the protocol type, as supplied by BPF; on Linux, they *do*
have an offset field, as supplied by PF_PACKET sockets. Add a new
WTAP_ENCAP_ARCNET_LINUX, with packets that include the offset field, and
don't dissect an offset in WTAP_ENCAP_ARCNET packets.
Map a libpcap link-layer type of 129 to WTAP_ENCAP_ARCNET_LINUX; that
value was recently assigned to Linux-style ARCNET.
Add some more ARCNET protocol IDs.
For most protocol IDs, dissect an ATA 878.2 fragmentation header; don't
do it for RFC 1051 IP and ARP, and Diagnose packets. Set the length of
the ARCNET protocol tree item appropriately.
Dissect both the RFC 1051 and RFC 1201 styles of IP and ARP over ARCNET,
and dissect the RFC 1201 style of RARP as well.
svn path=/trunk/; revision=6981
indicates the subtype of an "Internetwork analyzer" capture; we've seen
only one such capture, and it was a frame relay capture, so we just wire
it to frame relay for now.
svn path=/trunk/; revision=6923
as it's the major version number.
Try using the first word of "rsvd" to determine whether a capture is an
ISDN capture or not in version 1 captures.
Version 1 captures look as if they might also have a REC_HEADER2 record
- it's longer than the ones in version 4 and 5 captures, but it still
appears to have a network subtype in the 5th byte.
Get rid of the heuristic that checks for WTAP_ENCAP_ISDN by looking at
the packet data; if we fail to recognize an ISDN capture, we should look
for stuff in the headers to determine whether the capture is one or not.
svn path=/trunk/; revision=6894
that flag in the ATM pseudo-header, and use it to determine whether a
frame is a raw cell or a reassembled frame, rather than using the AAL,
as you can have raw AAL5 cells in a capture.
svn path=/trunk/; revision=6889
length of the packet, and the second two bytes are the captured length
of the packet. The old "length" value appears to be the captured length
of the packet as well; perhaps it's to be interpreted as the number of
bytes of data following the packet header (just in case there's padding,
for example).
Treat "ATM/", as an encapsulation string, as RFC 1483 ATM. (It may
actually be raw ATM, but the only capture I've seen had, in the parts I
saw, only RFC 1483 traffic LLC/SNAP traffic.)
There are 8 bytes in front of the LLC/SNAP header in ATM captures; skip
them, for now. (Perhaps they're a pseudo-header, giving VPI/VCI
information and stuff such as that? Or perhaps that's in the record
header?)
svn path=/trunk/; revision=6871
Guy Harris