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
Sniffer format, it doesn't distinguish between LE Control and LANE
encapsulated LAN frames, so we can't rely on the ATM subtype being
correct even when reading DOS Sniffer captures - we force it to
TRAF_ST_LANE_LE_CTRL for LANE frames that begin with 0xff 0x00.
Move the calls to "infer_pkt_encap()" into "fix_pseudo_header()".
svn path=/trunk/; revision=6869
number.
Put in some commented-out code to deal with some end-of-packet crud in
some ISDN captures - not all ISDN captures have it, so we can't
unconditionally slice it out.
svn path=/trunk/; revision=6867
number.
Put in some commented-out code to deal with some end-of-packet crud in
some ISDN captures - not all ISDN captures have it, so we can't
unconditionally slice it out.
svn path=/trunk/; revision=6863
HDLC-flavored encapsulation (or, at least, it was in at least one
capture). Instead, treat it as WTAP_ENCAP_PER_PACKET, and infer the
packet type, as we do for NET_ROUTER.
For NET_ROUTER captures, if the ISDN channel number is zero, infer the
packet type from the contents, rather than wiring it to PPP - it might
be, for example, Cisco or Wellfleet HDLC.
Fix the check for Cisco HDLC to look for 0x0F 0x00 and 0x8F 0x00, as
0x0F, not 0x08, is the unicast address in Cisco HDLC.
When fixing the pseudo-header, fix it for WTAP_ENCAP_WFLEET_HDLC,
WTAP_ENCAP_CHDLC, and WTAP_ENCAP_PPP_WITH_PHDR, as well as for
WTAP_ENCAP_ISDN, as the three ones listed don't use x25.flags, they use
p2p.sent.
svn path=/trunk/; revision=6850
used for the DOS-based ATM Sniffer. (That's not a great name, but I
couldn't think of a better one.)
Add a new WTAP_ENCAP_ATM_PDUS_UNTRUNCATED encapsulation type for capture
files where reassembled frames don't have trailers, such as the AAL5
trailer, chopped off. That's what at least some versions of the
Windows-based ATM Sniffer appear to have.
Map the ATM capture file type for NetXRay captures to
WTAP_ENCAP_ATM_PDUS_UNTRUNCATED, and put in stuff to fill in what we've
reverse-engineered, so far, for the pseudo-header; there's more that
needs to be done on it, e.g. getting the channel, AAL type, and traffic
type (or inferring them if they're not in the packet header).
svn path=/trunk/; revision=6840
Make the "fs" and "flags" fields in type 6 records unsigned, as they are
in other per-frame records - they're probably the same set of flag bits.
svn path=/trunk/; revision=6814
well as Cisco HDLC support. It compiles OK, but I do not claim that it is
not borken.
I will have to add a small dissector that eats the first two bytes and then
calls the Ethernet dissector as well, to complete the work.
svn path=/trunk/; revision=6809
