1998-11-15 05:29:17 +00:00
|
|
|
/* snoop.c
|
|
|
|
*
|
2000-05-18 09:09:50 +00:00
|
|
|
* $Id: snoop.c,v 1.26 2000/05/18 09:09:44 guy Exp $
|
1998-11-15 05:29:17 +00:00
|
|
|
*
|
|
|
|
* Wiretap Library
|
2000-01-22 06:22:44 +00:00
|
|
|
* Copyright (c) 1998 by Gilbert Ramirez <gram@xiexie.org>
|
1998-11-15 05:29:17 +00:00
|
|
|
*
|
|
|
|
* This program is free software; you can redistribute it and/or
|
|
|
|
* modify it under the terms of the GNU General Public License
|
|
|
|
* as published by the Free Software Foundation; either version 2
|
|
|
|
* of the License, or (at your option) any later version.
|
|
|
|
*
|
|
|
|
* This program is distributed in the hope that it will be useful,
|
|
|
|
* but WITHOUT ANY WARRANTY; without even the implied warranty of
|
|
|
|
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
|
|
|
|
* GNU General Public License for more details.
|
|
|
|
*
|
|
|
|
* You should have received a copy of the GNU General Public License
|
|
|
|
* along with this program; if not, write to the Free Software
|
|
|
|
* Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
|
|
|
|
*
|
|
|
|
*/
|
1999-07-13 02:53:26 +00:00
|
|
|
#ifdef HAVE_CONFIG_H
|
|
|
|
#include "config.h"
|
|
|
|
#endif
|
Have the per-capture-file-type open routines "wtap_open_offline()" calls
return 1 on success, -1 if they got an error, and 0 if the file isn't of
the type that file is checking for, and supply an error code if they
return -1; have "wtap_open_offline()" use that error code. Also, have
the per-capture-file-type open routines treat errors accessing the file
as errors, and return -1, rather than just returning 0 so that we try
another file type.
Have the per-capture-file-type read routines "wtap_loop()" calls return
-1 and supply an error code on error (and not, as they did in some
cases, call "g_error()" and abort), and have "wtap_loop()", if the read
routine returned an error, return FALSE (and pass an error-code-pointer
argument onto the read routines, so they fill it in), and return TRUE on
success.
Add some new error codes for them to return.
Now that "wtap_loop()" can return a success/failure indication and an
error code, in "read_cap_file()" put up a message box if we get an error
reading the file, and return the error code.
Handle the additional errors we can get when opening a capture file.
If the attempt to open a capture file succeeds, but the attempt to read
it fails, don't treat that as a complete failure - we may have managed
to read some of the capture file, and we should display what we managed
to read.
svn path=/trunk/; revision=516
1999-08-19 05:31:38 +00:00
|
|
|
#include <errno.h>
|
1998-11-15 05:29:17 +00:00
|
|
|
#include "wtap.h"
|
2000-01-13 07:09:20 +00:00
|
|
|
#include "file_wrappers.h"
|
1999-03-01 18:57:07 +00:00
|
|
|
#include "buffer.h"
|
1998-11-15 05:29:17 +00:00
|
|
|
#include "snoop.h"
|
1999-07-13 02:53:26 +00:00
|
|
|
#ifdef HAVE_NETINET_IN_H
|
1998-11-15 05:29:17 +00:00
|
|
|
#include <netinet/in.h>
|
1999-07-13 02:53:26 +00:00
|
|
|
#endif
|
1998-11-15 05:29:17 +00:00
|
|
|
|
|
|
|
/* See RFC 1761 for a description of the "snoop" file format. */
|
|
|
|
|
|
|
|
/* Magic number in "snoop" files. */
|
1999-02-20 06:46:57 +00:00
|
|
|
static const char snoop_magic[] = {
|
1998-11-15 05:29:17 +00:00
|
|
|
's', 'n', 'o', 'o', 'p', '\0', '\0', '\0'
|
|
|
|
};
|
|
|
|
|
|
|
|
/* "snoop" file header (minus magic number). */
|
|
|
|
struct snoop_hdr {
|
|
|
|
guint32 version; /* version number (should be 2) */
|
|
|
|
guint32 network; /* network type */
|
|
|
|
};
|
|
|
|
|
|
|
|
/* "snoop" record header. */
|
|
|
|
struct snooprec_hdr {
|
|
|
|
guint32 orig_len; /* actual length of packet */
|
|
|
|
guint32 incl_len; /* number of octets captured in file */
|
|
|
|
guint32 rec_len; /* length of record */
|
|
|
|
guint32 cum_drops; /* cumulative number of dropped packets */
|
|
|
|
guint32 ts_sec; /* timestamp seconds */
|
|
|
|
guint32 ts_usec; /* timestamp microseconds */
|
|
|
|
};
|
|
|
|
|
Have the per-capture-file-type open routines "wtap_open_offline()" calls
return 1 on success, -1 if they got an error, and 0 if the file isn't of
the type that file is checking for, and supply an error code if they
return -1; have "wtap_open_offline()" use that error code. Also, have
the per-capture-file-type open routines treat errors accessing the file
as errors, and return -1, rather than just returning 0 so that we try
another file type.
Have the per-capture-file-type read routines "wtap_loop()" calls return
-1 and supply an error code on error (and not, as they did in some
cases, call "g_error()" and abort), and have "wtap_loop()", if the read
routine returned an error, return FALSE (and pass an error-code-pointer
argument onto the read routines, so they fill it in), and return TRUE on
success.
Add some new error codes for them to return.
Now that "wtap_loop()" can return a success/failure indication and an
error code, in "read_cap_file()" put up a message box if we get an error
reading the file, and return the error code.
Handle the additional errors we can get when opening a capture file.
If the attempt to open a capture file succeeds, but the attempt to read
it fails, don't treat that as a complete failure - we may have managed
to read some of the capture file, and we should display what we managed
to read.
svn path=/trunk/; revision=516
1999-08-19 05:31:38 +00:00
|
|
|
static int snoop_read(wtap *wth, int *err);
|
2000-05-18 09:09:50 +00:00
|
|
|
static int snoop_seek_read(wtap *wth, int seek_off,
|
|
|
|
union pseudo_header *pseudo_header, u_char *pd, int length);
|
|
|
|
static int snoop_read_atm_pseudoheader(FILE_T *fh,
|
|
|
|
union pseudo_header *pseudo_header, int *err);
|
|
|
|
static int snoop_read_rec_data(FILE_T *fh, char *pd, int length, int *err);
|
1999-12-04 05:14:39 +00:00
|
|
|
static gboolean snoop_dump(wtap_dumper *wdh, const struct wtap_pkthdr *phdr,
|
2000-05-18 09:09:50 +00:00
|
|
|
const union pseudo_header *pseudo_header, const u_char *pd, int *err);
|
Have the per-capture-file-type open routines "wtap_open_offline()" calls
return 1 on success, -1 if they got an error, and 0 if the file isn't of
the type that file is checking for, and supply an error code if they
return -1; have "wtap_open_offline()" use that error code. Also, have
the per-capture-file-type open routines treat errors accessing the file
as errors, and return -1, rather than just returning 0 so that we try
another file type.
Have the per-capture-file-type read routines "wtap_loop()" calls return
-1 and supply an error code on error (and not, as they did in some
cases, call "g_error()" and abort), and have "wtap_loop()", if the read
routine returned an error, return FALSE (and pass an error-code-pointer
argument onto the read routines, so they fill it in), and return TRUE on
success.
Add some new error codes for them to return.
Now that "wtap_loop()" can return a success/failure indication and an
error code, in "read_cap_file()" put up a message box if we get an error
reading the file, and return the error code.
Handle the additional errors we can get when opening a capture file.
If the attempt to open a capture file succeeds, but the attempt to read
it fails, don't treat that as a complete failure - we may have managed
to read some of the capture file, and we should display what we managed
to read.
svn path=/trunk/; revision=516
1999-08-19 05:31:38 +00:00
|
|
|
|
1999-11-26 11:18:12 +00:00
|
|
|
/*
|
|
|
|
* See
|
|
|
|
*
|
|
|
|
* http://www.opengroup.org/onlinepubs/9638599/apdxf.htm
|
|
|
|
*
|
|
|
|
* for the "dlpi.h" header file specified by The Open Group, which lists
|
1999-11-27 06:03:46 +00:00
|
|
|
* the DL_ values for various protocols; Solaris 7 uses the same values.
|
1999-11-26 11:18:12 +00:00
|
|
|
*
|
1999-11-27 06:03:46 +00:00
|
|
|
* The page at
|
1999-11-26 11:18:12 +00:00
|
|
|
*
|
1999-11-27 06:03:46 +00:00
|
|
|
* http://mrpink.lerc.nasa.gov/118x/support.html
|
Move the "guess what type of ATM traffic this is" stuff into the ATM
dissector; I don't think it's guaranteed that even a Sniffer will tell
you that (there may be situations where it can't figure it out, and
where the user didn't tell it), we may need it for "atmsnoop" traffic
and other types of ATM traffic as well, we will probably want to add to
it the ability to let the user specify "virtual circuit X.Y is this kind
of traffic", and we may also have Ethereal try to intuit it based on
previous traffic in the capture (Q.2931 call setup, LANE traffic, etc.).
Don't show the cell count if it's zero - assume that means we don't know
how many cells made up the packet. Also don't show the AAL5 trailer if
the cell count is zero - the ATM Sniffer *might* sometimes supply a cell
count of 0 even if it has the AAL5 trailer, I guess, and we *might* see
some other capture file format that has the AAL5 trailer but no cell
count, but we'll cross that bridge when we come to it.
Add support for "atmsnoop" captures to the code to handle "snoop"
captures.
Use the field in "iptrace" headers that appears to be, in ATM captures,
a direction indicator - we may have the direction backwards, but, as an
STP packet was tagged as a DCE->DTE packet, and as the capturing
machine, which also was presumably the recipient of the packet, was an
AIX box, not a switch or bridge or some piece of networking equipment
such as that, it *probably* wasn't sending the STP packet, it was
probably receiving it.
svn path=/trunk/; revision=1120
1999-11-27 01:55:44 +00:00
|
|
|
*
|
1999-11-27 06:03:46 +00:00
|
|
|
* has links to modified versions of "tcpdump" and "libpcap" for SUNatm
|
|
|
|
* DLPI support; they suggest the 3.0 verson of SUNatm uses those
|
|
|
|
* values.
|
Move the "guess what type of ATM traffic this is" stuff into the ATM
dissector; I don't think it's guaranteed that even a Sniffer will tell
you that (there may be situations where it can't figure it out, and
where the user didn't tell it), we may need it for "atmsnoop" traffic
and other types of ATM traffic as well, we will probably want to add to
it the ability to let the user specify "virtual circuit X.Y is this kind
of traffic", and we may also have Ethereal try to intuit it based on
previous traffic in the capture (Q.2931 call setup, LANE traffic, etc.).
Don't show the cell count if it's zero - assume that means we don't know
how many cells made up the packet. Also don't show the AAL5 trailer if
the cell count is zero - the ATM Sniffer *might* sometimes supply a cell
count of 0 even if it has the AAL5 trailer, I guess, and we *might* see
some other capture file format that has the AAL5 trailer but no cell
count, but we'll cross that bridge when we come to it.
Add support for "atmsnoop" captures to the code to handle "snoop"
captures.
Use the field in "iptrace" headers that appears to be, in ATM captures,
a direction indicator - we may have the direction backwards, but, as an
STP packet was tagged as a DCE->DTE packet, and as the capturing
machine, which also was presumably the recipient of the packet, was an
AIX box, not a switch or bridge or some piece of networking equipment
such as that, it *probably* wasn't sending the STP packet, it was
probably receiving it.
svn path=/trunk/; revision=1120
1999-11-27 01:55:44 +00:00
|
|
|
*
|
1999-11-27 06:03:46 +00:00
|
|
|
* It also has a link to "convert.c", which is a program to convert files
|
|
|
|
* from the format written by the "atmsnoop" program that comes with the
|
|
|
|
* SunATM package to regular "snoop" format, claims that "SunATM 2.1 claimed
|
|
|
|
* to be DL_FDDI (don't ask why). SunATM 3.0 claims to be DL_IPATM, which
|
|
|
|
* is 0x12".
|
Move the "guess what type of ATM traffic this is" stuff into the ATM
dissector; I don't think it's guaranteed that even a Sniffer will tell
you that (there may be situations where it can't figure it out, and
where the user didn't tell it), we may need it for "atmsnoop" traffic
and other types of ATM traffic as well, we will probably want to add to
it the ability to let the user specify "virtual circuit X.Y is this kind
of traffic", and we may also have Ethereal try to intuit it based on
previous traffic in the capture (Q.2931 call setup, LANE traffic, etc.).
Don't show the cell count if it's zero - assume that means we don't know
how many cells made up the packet. Also don't show the AAL5 trailer if
the cell count is zero - the ATM Sniffer *might* sometimes supply a cell
count of 0 even if it has the AAL5 trailer, I guess, and we *might* see
some other capture file format that has the AAL5 trailer but no cell
count, but we'll cross that bridge when we come to it.
Add support for "atmsnoop" captures to the code to handle "snoop"
captures.
Use the field in "iptrace" headers that appears to be, in ATM captures,
a direction indicator - we may have the direction backwards, but, as an
STP packet was tagged as a DCE->DTE packet, and as the capturing
machine, which also was presumably the recipient of the packet, was an
AIX box, not a switch or bridge or some piece of networking equipment
such as that, it *probably* wasn't sending the STP packet, it was
probably receiving it.
svn path=/trunk/; revision=1120
1999-11-27 01:55:44 +00:00
|
|
|
*
|
|
|
|
* It also says that "ATM Mac header is 12 bytes long.", and seems to imply
|
|
|
|
* that in an "atmsnoop" file, the header contains 2 bytes (direction and
|
|
|
|
* VPI?), 2 bytes of VCI, 6 bytes of something, and 2 bytes of Ethernet
|
|
|
|
* type; if those 6 bytes are 2 bytes of DSAP, 2 bytes of LSAP, 1 byte
|
|
|
|
* of LLC control, and 3 bytes of SNAP OUI, that'd mean that an ATM
|
|
|
|
* pseudo-header in an "atmsnoop" file is probably 1 byte of direction,
|
|
|
|
* 1 byte of VPI, and 2 bytes of VCI.
|
1999-11-27 06:03:46 +00:00
|
|
|
*
|
|
|
|
* The aforementioned page also has a link to some capture files from
|
|
|
|
* "atmsnoop"; this version of "snoop.c" appears to be able to read them.
|
|
|
|
*
|
|
|
|
* Source to an "atmdump" package, which includes a modified version of
|
|
|
|
* "libpcap" to handle SunATM DLPI and an ATM driver for FreeBSD, and
|
|
|
|
* also includes "atmdump", which is a modified "tcpdump", says that an
|
|
|
|
* ATM packet handed up from the Sun driver for the Sun SBus ATM card on
|
|
|
|
* Solaris 2.5.1 has 1 byte of direction, 1 byte of VPI, 2 bytes of VCI,
|
|
|
|
* and then the ATM PDU, and suggests that the direction byte is 0x80 for
|
|
|
|
* "transmitted" (presumably meaning DTE->DCE) and presumably not 0x80 for
|
|
|
|
* "received" (presumably meaning DCE->DTE).
|
|
|
|
*
|
|
|
|
* In fact, the "direction" byte appears to have some other stuff, perhaps
|
|
|
|
* a traffic type, in the lower 7 bits, with the 8th bit indicating the
|
|
|
|
* direction.
|
|
|
|
*
|
|
|
|
* I don't know what the encapsulation of any of the other types is, so I
|
|
|
|
* leave them all as WTAP_ENCAP_UNKNOWN. I also don't know whether "snoop"
|
|
|
|
* can handle any of them (it presumably can't handle ATM, otherwise Sun
|
|
|
|
* wouldn't have supplied "atmsnoop"; even if it can't, this may be useful
|
|
|
|
* reference information for anybody doing code to use DLPI to do raw packet
|
|
|
|
* captures on those network types.
|
1999-11-26 11:18:12 +00:00
|
|
|
*/
|
Have the per-capture-file-type open routines "wtap_open_offline()" calls
return 1 on success, -1 if they got an error, and 0 if the file isn't of
the type that file is checking for, and supply an error code if they
return -1; have "wtap_open_offline()" use that error code. Also, have
the per-capture-file-type open routines treat errors accessing the file
as errors, and return -1, rather than just returning 0 so that we try
another file type.
Have the per-capture-file-type read routines "wtap_loop()" calls return
-1 and supply an error code on error (and not, as they did in some
cases, call "g_error()" and abort), and have "wtap_loop()", if the read
routine returned an error, return FALSE (and pass an error-code-pointer
argument onto the read routines, so they fill it in), and return TRUE on
success.
Add some new error codes for them to return.
Now that "wtap_loop()" can return a success/failure indication and an
error code, in "read_cap_file()" put up a message box if we get an error
reading the file, and return the error code.
Handle the additional errors we can get when opening a capture file.
If the attempt to open a capture file succeeds, but the attempt to read
it fails, don't treat that as a complete failure - we may have managed
to read some of the capture file, and we should display what we managed
to read.
svn path=/trunk/; revision=516
1999-08-19 05:31:38 +00:00
|
|
|
int snoop_open(wtap *wth, int *err)
|
1998-11-15 05:29:17 +00:00
|
|
|
{
|
|
|
|
int bytes_read;
|
|
|
|
char magic[sizeof snoop_magic];
|
|
|
|
struct snoop_hdr hdr;
|
|
|
|
static const int snoop_encap[] = {
|
1999-09-28 01:19:01 +00:00
|
|
|
WTAP_ENCAP_ETHERNET, /* IEEE 802.3 */
|
1999-08-22 02:29:40 +00:00
|
|
|
WTAP_ENCAP_UNKNOWN, /* IEEE 802.4 Token Bus */
|
1998-11-15 05:29:17 +00:00
|
|
|
WTAP_ENCAP_TR,
|
1999-08-22 02:29:40 +00:00
|
|
|
WTAP_ENCAP_UNKNOWN, /* IEEE 802.6 Metro Net */
|
1998-11-15 05:29:17 +00:00
|
|
|
WTAP_ENCAP_ETHERNET,
|
1999-08-22 02:29:40 +00:00
|
|
|
WTAP_ENCAP_UNKNOWN, /* HDLC */
|
1999-11-26 11:18:12 +00:00
|
|
|
WTAP_ENCAP_UNKNOWN, /* Character Synchronous, e.g. bisync */
|
1999-08-22 02:29:40 +00:00
|
|
|
WTAP_ENCAP_UNKNOWN, /* IBM Channel-to-Channel */
|
Add a new Wiretap encapsulation type WTAP_ENCAP_FDDI_BITSWAPPED, meaning
"FDDI with the MAC addresses bit-swapped"; whether the MAC addresses are
bit-swapped is a property of the machine on which the capture was taken,
not of the machine on which the capture is being read - right now, none
of the capture file formats we read indicate whether FDDI MAC addresses
are bit-swapped, but this does let us treat non-"libpcap" captures as
being bit-swapped or not bit-swapped independent of the machine on which
they're being read (and of the machine on which they were captured, but
I have the impression they're bit-swapped on most platforms), and allows
us to, if, as, and when we implement packet capture in Wiretap, mark
packets in a capture file written in Wiretap-native format based on the
machine on which they are captured (assuming the rule "Ultrix, Alpha,
and BSD/OS are the only platforms that don't bit-swap", or some other
compile-time rule, gets the right answer, or that some platform has
drivers that can tell us whether the addresses are bit-swapped).
(NOTE: if, for any of the capture file formats used only on one
platform, FDDI MAC addresses aren't bit-swapped, the code to read that
capture file format should be fixed to flag them as not bit-swapped.)
Use the encapsulation type to decide whether to bit-swap addresses in
"dissect_fddi()".
svn path=/trunk/; revision=557
1999-08-24 03:19:34 +00:00
|
|
|
WTAP_ENCAP_FDDI_BITSWAPPED,
|
1999-11-26 11:18:12 +00:00
|
|
|
WTAP_ENCAP_UNKNOWN, /* Other */
|
|
|
|
WTAP_ENCAP_UNKNOWN, /* Frame Relay LAPF */
|
|
|
|
WTAP_ENCAP_UNKNOWN, /* Multi-protocol over Frame Relay */
|
|
|
|
WTAP_ENCAP_UNKNOWN, /* Character Async (e.g., SLIP and PPP?) */
|
|
|
|
WTAP_ENCAP_UNKNOWN, /* X.25 Classical IP */
|
|
|
|
WTAP_ENCAP_UNKNOWN, /* software loopback */
|
|
|
|
WTAP_ENCAP_UNKNOWN, /* not defined in "dlpi.h" */
|
|
|
|
WTAP_ENCAP_UNKNOWN, /* Fibre Channel */
|
|
|
|
WTAP_ENCAP_UNKNOWN, /* ATM */
|
Move the "guess what type of ATM traffic this is" stuff into the ATM
dissector; I don't think it's guaranteed that even a Sniffer will tell
you that (there may be situations where it can't figure it out, and
where the user didn't tell it), we may need it for "atmsnoop" traffic
and other types of ATM traffic as well, we will probably want to add to
it the ability to let the user specify "virtual circuit X.Y is this kind
of traffic", and we may also have Ethereal try to intuit it based on
previous traffic in the capture (Q.2931 call setup, LANE traffic, etc.).
Don't show the cell count if it's zero - assume that means we don't know
how many cells made up the packet. Also don't show the AAL5 trailer if
the cell count is zero - the ATM Sniffer *might* sometimes supply a cell
count of 0 even if it has the AAL5 trailer, I guess, and we *might* see
some other capture file format that has the AAL5 trailer but no cell
count, but we'll cross that bridge when we come to it.
Add support for "atmsnoop" captures to the code to handle "snoop"
captures.
Use the field in "iptrace" headers that appears to be, in ATM captures,
a direction indicator - we may have the direction backwards, but, as an
STP packet was tagged as a DCE->DTE packet, and as the capturing
machine, which also was presumably the recipient of the packet, was an
AIX box, not a switch or bridge or some piece of networking equipment
such as that, it *probably* wasn't sending the STP packet, it was
probably receiving it.
svn path=/trunk/; revision=1120
1999-11-27 01:55:44 +00:00
|
|
|
WTAP_ENCAP_ATM_SNIFFER, /* ATM Classical IP */
|
1999-11-26 11:18:12 +00:00
|
|
|
WTAP_ENCAP_UNKNOWN, /* X.25 LAPB */
|
|
|
|
WTAP_ENCAP_UNKNOWN, /* ISDN */
|
|
|
|
WTAP_ENCAP_UNKNOWN, /* HIPPI */
|
|
|
|
WTAP_ENCAP_UNKNOWN, /* 100VG-AnyLAN Ethernet */
|
|
|
|
WTAP_ENCAP_UNKNOWN, /* 100VG-AnyLAN Token Ring */
|
|
|
|
WTAP_ENCAP_UNKNOWN, /* "ISO 8802/3 and Ethernet" */
|
|
|
|
WTAP_ENCAP_UNKNOWN, /* 100BaseT (but that's just Ethernet) */
|
1998-11-15 05:29:17 +00:00
|
|
|
};
|
|
|
|
#define NUM_SNOOP_ENCAPS (sizeof snoop_encap / sizeof snoop_encap[0])
|
|
|
|
|
|
|
|
/* Read in the string that should be at the start of a "snoop" file */
|
1999-09-22 01:26:50 +00:00
|
|
|
file_seek(wth->fh, 0, SEEK_SET);
|
1999-08-28 01:19:45 +00:00
|
|
|
wth->data_offset = 0;
|
Have the per-capture-file-type open routines "wtap_open_offline()" calls
return 1 on success, -1 if they got an error, and 0 if the file isn't of
the type that file is checking for, and supply an error code if they
return -1; have "wtap_open_offline()" use that error code. Also, have
the per-capture-file-type open routines treat errors accessing the file
as errors, and return -1, rather than just returning 0 so that we try
another file type.
Have the per-capture-file-type read routines "wtap_loop()" calls return
-1 and supply an error code on error (and not, as they did in some
cases, call "g_error()" and abort), and have "wtap_loop()", if the read
routine returned an error, return FALSE (and pass an error-code-pointer
argument onto the read routines, so they fill it in), and return TRUE on
success.
Add some new error codes for them to return.
Now that "wtap_loop()" can return a success/failure indication and an
error code, in "read_cap_file()" put up a message box if we get an error
reading the file, and return the error code.
Handle the additional errors we can get when opening a capture file.
If the attempt to open a capture file succeeds, but the attempt to read
it fails, don't treat that as a complete failure - we may have managed
to read some of the capture file, and we should display what we managed
to read.
svn path=/trunk/; revision=516
1999-08-19 05:31:38 +00:00
|
|
|
errno = WTAP_ERR_CANT_READ;
|
1999-09-22 01:26:50 +00:00
|
|
|
bytes_read = file_read(magic, 1, sizeof magic, wth->fh);
|
1998-11-15 05:29:17 +00:00
|
|
|
if (bytes_read != sizeof magic) {
|
1999-10-05 07:06:08 +00:00
|
|
|
*err = file_error(wth->fh);
|
|
|
|
if (*err != 0)
|
Have the per-capture-file-type open routines "wtap_open_offline()" calls
return 1 on success, -1 if they got an error, and 0 if the file isn't of
the type that file is checking for, and supply an error code if they
return -1; have "wtap_open_offline()" use that error code. Also, have
the per-capture-file-type open routines treat errors accessing the file
as errors, and return -1, rather than just returning 0 so that we try
another file type.
Have the per-capture-file-type read routines "wtap_loop()" calls return
-1 and supply an error code on error (and not, as they did in some
cases, call "g_error()" and abort), and have "wtap_loop()", if the read
routine returned an error, return FALSE (and pass an error-code-pointer
argument onto the read routines, so they fill it in), and return TRUE on
success.
Add some new error codes for them to return.
Now that "wtap_loop()" can return a success/failure indication and an
error code, in "read_cap_file()" put up a message box if we get an error
reading the file, and return the error code.
Handle the additional errors we can get when opening a capture file.
If the attempt to open a capture file succeeds, but the attempt to read
it fails, don't treat that as a complete failure - we may have managed
to read some of the capture file, and we should display what we managed
to read.
svn path=/trunk/; revision=516
1999-08-19 05:31:38 +00:00
|
|
|
return -1;
|
|
|
|
return 0;
|
1998-11-15 05:29:17 +00:00
|
|
|
}
|
1999-08-28 01:19:45 +00:00
|
|
|
wth->data_offset += sizeof magic;
|
1998-11-15 05:29:17 +00:00
|
|
|
|
|
|
|
if (memcmp(magic, snoop_magic, sizeof snoop_magic) != 0) {
|
Have the per-capture-file-type open routines "wtap_open_offline()" calls
return 1 on success, -1 if they got an error, and 0 if the file isn't of
the type that file is checking for, and supply an error code if they
return -1; have "wtap_open_offline()" use that error code. Also, have
the per-capture-file-type open routines treat errors accessing the file
as errors, and return -1, rather than just returning 0 so that we try
another file type.
Have the per-capture-file-type read routines "wtap_loop()" calls return
-1 and supply an error code on error (and not, as they did in some
cases, call "g_error()" and abort), and have "wtap_loop()", if the read
routine returned an error, return FALSE (and pass an error-code-pointer
argument onto the read routines, so they fill it in), and return TRUE on
success.
Add some new error codes for them to return.
Now that "wtap_loop()" can return a success/failure indication and an
error code, in "read_cap_file()" put up a message box if we get an error
reading the file, and return the error code.
Handle the additional errors we can get when opening a capture file.
If the attempt to open a capture file succeeds, but the attempt to read
it fails, don't treat that as a complete failure - we may have managed
to read some of the capture file, and we should display what we managed
to read.
svn path=/trunk/; revision=516
1999-08-19 05:31:38 +00:00
|
|
|
return 0;
|
1998-11-15 05:29:17 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
/* Read the rest of the header. */
|
Have the per-capture-file-type open routines "wtap_open_offline()" calls
return 1 on success, -1 if they got an error, and 0 if the file isn't of
the type that file is checking for, and supply an error code if they
return -1; have "wtap_open_offline()" use that error code. Also, have
the per-capture-file-type open routines treat errors accessing the file
as errors, and return -1, rather than just returning 0 so that we try
another file type.
Have the per-capture-file-type read routines "wtap_loop()" calls return
-1 and supply an error code on error (and not, as they did in some
cases, call "g_error()" and abort), and have "wtap_loop()", if the read
routine returned an error, return FALSE (and pass an error-code-pointer
argument onto the read routines, so they fill it in), and return TRUE on
success.
Add some new error codes for them to return.
Now that "wtap_loop()" can return a success/failure indication and an
error code, in "read_cap_file()" put up a message box if we get an error
reading the file, and return the error code.
Handle the additional errors we can get when opening a capture file.
If the attempt to open a capture file succeeds, but the attempt to read
it fails, don't treat that as a complete failure - we may have managed
to read some of the capture file, and we should display what we managed
to read.
svn path=/trunk/; revision=516
1999-08-19 05:31:38 +00:00
|
|
|
errno = WTAP_ERR_CANT_READ;
|
1999-09-22 01:26:50 +00:00
|
|
|
bytes_read = file_read(&hdr, 1, sizeof hdr, wth->fh);
|
1998-11-15 05:29:17 +00:00
|
|
|
if (bytes_read != sizeof hdr) {
|
1999-10-05 07:06:08 +00:00
|
|
|
*err = file_error(wth->fh);
|
|
|
|
if (*err != 0)
|
Have the per-capture-file-type open routines "wtap_open_offline()" calls
return 1 on success, -1 if they got an error, and 0 if the file isn't of
the type that file is checking for, and supply an error code if they
return -1; have "wtap_open_offline()" use that error code. Also, have
the per-capture-file-type open routines treat errors accessing the file
as errors, and return -1, rather than just returning 0 so that we try
another file type.
Have the per-capture-file-type read routines "wtap_loop()" calls return
-1 and supply an error code on error (and not, as they did in some
cases, call "g_error()" and abort), and have "wtap_loop()", if the read
routine returned an error, return FALSE (and pass an error-code-pointer
argument onto the read routines, so they fill it in), and return TRUE on
success.
Add some new error codes for them to return.
Now that "wtap_loop()" can return a success/failure indication and an
error code, in "read_cap_file()" put up a message box if we get an error
reading the file, and return the error code.
Handle the additional errors we can get when opening a capture file.
If the attempt to open a capture file succeeds, but the attempt to read
it fails, don't treat that as a complete failure - we may have managed
to read some of the capture file, and we should display what we managed
to read.
svn path=/trunk/; revision=516
1999-08-19 05:31:38 +00:00
|
|
|
return -1;
|
|
|
|
return 0;
|
1998-11-15 05:29:17 +00:00
|
|
|
}
|
1999-08-28 01:19:45 +00:00
|
|
|
wth->data_offset += sizeof hdr;
|
1998-11-15 05:29:17 +00:00
|
|
|
|
|
|
|
hdr.version = ntohl(hdr.version);
|
|
|
|
if (hdr.version != 2) {
|
|
|
|
/* We only support version 2. */
|
1999-08-22 02:29:40 +00:00
|
|
|
g_message("snoop: version %u unsupported", hdr.version);
|
Have the per-capture-file-type open routines "wtap_open_offline()" calls
return 1 on success, -1 if they got an error, and 0 if the file isn't of
the type that file is checking for, and supply an error code if they
return -1; have "wtap_open_offline()" use that error code. Also, have
the per-capture-file-type open routines treat errors accessing the file
as errors, and return -1, rather than just returning 0 so that we try
another file type.
Have the per-capture-file-type read routines "wtap_loop()" calls return
-1 and supply an error code on error (and not, as they did in some
cases, call "g_error()" and abort), and have "wtap_loop()", if the read
routine returned an error, return FALSE (and pass an error-code-pointer
argument onto the read routines, so they fill it in), and return TRUE on
success.
Add some new error codes for them to return.
Now that "wtap_loop()" can return a success/failure indication and an
error code, in "read_cap_file()" put up a message box if we get an error
reading the file, and return the error code.
Handle the additional errors we can get when opening a capture file.
If the attempt to open a capture file succeeds, but the attempt to read
it fails, don't treat that as a complete failure - we may have managed
to read some of the capture file, and we should display what we managed
to read.
svn path=/trunk/; revision=516
1999-08-19 05:31:38 +00:00
|
|
|
*err = WTAP_ERR_UNSUPPORTED;
|
|
|
|
return -1;
|
1998-11-15 05:29:17 +00:00
|
|
|
}
|
|
|
|
hdr.network = ntohl(hdr.network);
|
1999-08-22 02:29:40 +00:00
|
|
|
if (hdr.network >= NUM_SNOOP_ENCAPS
|
|
|
|
|| snoop_encap[hdr.network] == WTAP_ENCAP_UNKNOWN) {
|
|
|
|
g_message("snoop: network type %u unknown or unsupported",
|
|
|
|
hdr.network);
|
2000-02-19 08:00:08 +00:00
|
|
|
*err = WTAP_ERR_UNSUPPORTED_ENCAP;
|
Have the per-capture-file-type open routines "wtap_open_offline()" calls
return 1 on success, -1 if they got an error, and 0 if the file isn't of
the type that file is checking for, and supply an error code if they
return -1; have "wtap_open_offline()" use that error code. Also, have
the per-capture-file-type open routines treat errors accessing the file
as errors, and return -1, rather than just returning 0 so that we try
another file type.
Have the per-capture-file-type read routines "wtap_loop()" calls return
-1 and supply an error code on error (and not, as they did in some
cases, call "g_error()" and abort), and have "wtap_loop()", if the read
routine returned an error, return FALSE (and pass an error-code-pointer
argument onto the read routines, so they fill it in), and return TRUE on
success.
Add some new error codes for them to return.
Now that "wtap_loop()" can return a success/failure indication and an
error code, in "read_cap_file()" put up a message box if we get an error
reading the file, and return the error code.
Handle the additional errors we can get when opening a capture file.
If the attempt to open a capture file succeeds, but the attempt to read
it fails, don't treat that as a complete failure - we may have managed
to read some of the capture file, and we should display what we managed
to read.
svn path=/trunk/; revision=516
1999-08-19 05:31:38 +00:00
|
|
|
return -1;
|
1998-11-15 05:29:17 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
/* This is a snoop file */
|
Have the per-capture-file-type open routines "wtap_open_offline()" calls
return 1 on success, -1 if they got an error, and 0 if the file isn't of
the type that file is checking for, and supply an error code if they
return -1; have "wtap_open_offline()" use that error code. Also, have
the per-capture-file-type open routines treat errors accessing the file
as errors, and return -1, rather than just returning 0 so that we try
another file type.
Have the per-capture-file-type read routines "wtap_loop()" calls return
-1 and supply an error code on error (and not, as they did in some
cases, call "g_error()" and abort), and have "wtap_loop()", if the read
routine returned an error, return FALSE (and pass an error-code-pointer
argument onto the read routines, so they fill it in), and return TRUE on
success.
Add some new error codes for them to return.
Now that "wtap_loop()" can return a success/failure indication and an
error code, in "read_cap_file()" put up a message box if we get an error
reading the file, and return the error code.
Handle the additional errors we can get when opening a capture file.
If the attempt to open a capture file succeeds, but the attempt to read
it fails, don't treat that as a complete failure - we may have managed
to read some of the capture file, and we should display what we managed
to read.
svn path=/trunk/; revision=516
1999-08-19 05:31:38 +00:00
|
|
|
wth->file_type = WTAP_FILE_SNOOP;
|
1998-11-15 05:29:17 +00:00
|
|
|
wth->subtype_read = snoop_read;
|
2000-05-18 09:09:50 +00:00
|
|
|
wth->subtype_seek_read = snoop_seek_read;
|
1999-03-01 18:57:07 +00:00
|
|
|
wth->file_encap = snoop_encap[hdr.network];
|
1998-11-15 05:29:17 +00:00
|
|
|
wth->snapshot_length = 16384; /* XXX - not available in header */
|
Have the per-capture-file-type open routines "wtap_open_offline()" calls
return 1 on success, -1 if they got an error, and 0 if the file isn't of
the type that file is checking for, and supply an error code if they
return -1; have "wtap_open_offline()" use that error code. Also, have
the per-capture-file-type open routines treat errors accessing the file
as errors, and return -1, rather than just returning 0 so that we try
another file type.
Have the per-capture-file-type read routines "wtap_loop()" calls return
-1 and supply an error code on error (and not, as they did in some
cases, call "g_error()" and abort), and have "wtap_loop()", if the read
routine returned an error, return FALSE (and pass an error-code-pointer
argument onto the read routines, so they fill it in), and return TRUE on
success.
Add some new error codes for them to return.
Now that "wtap_loop()" can return a success/failure indication and an
error code, in "read_cap_file()" put up a message box if we get an error
reading the file, and return the error code.
Handle the additional errors we can get when opening a capture file.
If the attempt to open a capture file succeeds, but the attempt to read
it fails, don't treat that as a complete failure - we may have managed
to read some of the capture file, and we should display what we managed
to read.
svn path=/trunk/; revision=516
1999-08-19 05:31:38 +00:00
|
|
|
return 1;
|
1998-11-15 05:29:17 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
/* Read the next packet */
|
Have the per-capture-file-type open routines "wtap_open_offline()" calls
return 1 on success, -1 if they got an error, and 0 if the file isn't of
the type that file is checking for, and supply an error code if they
return -1; have "wtap_open_offline()" use that error code. Also, have
the per-capture-file-type open routines treat errors accessing the file
as errors, and return -1, rather than just returning 0 so that we try
another file type.
Have the per-capture-file-type read routines "wtap_loop()" calls return
-1 and supply an error code on error (and not, as they did in some
cases, call "g_error()" and abort), and have "wtap_loop()", if the read
routine returned an error, return FALSE (and pass an error-code-pointer
argument onto the read routines, so they fill it in), and return TRUE on
success.
Add some new error codes for them to return.
Now that "wtap_loop()" can return a success/failure indication and an
error code, in "read_cap_file()" put up a message box if we get an error
reading the file, and return the error code.
Handle the additional errors we can get when opening a capture file.
If the attempt to open a capture file succeeds, but the attempt to read
it fails, don't treat that as a complete failure - we may have managed
to read some of the capture file, and we should display what we managed
to read.
svn path=/trunk/; revision=516
1999-08-19 05:31:38 +00:00
|
|
|
static int snoop_read(wtap *wth, int *err)
|
1998-11-15 05:29:17 +00:00
|
|
|
{
|
Move the "guess what type of ATM traffic this is" stuff into the ATM
dissector; I don't think it's guaranteed that even a Sniffer will tell
you that (there may be situations where it can't figure it out, and
where the user didn't tell it), we may need it for "atmsnoop" traffic
and other types of ATM traffic as well, we will probably want to add to
it the ability to let the user specify "virtual circuit X.Y is this kind
of traffic", and we may also have Ethereal try to intuit it based on
previous traffic in the capture (Q.2931 call setup, LANE traffic, etc.).
Don't show the cell count if it's zero - assume that means we don't know
how many cells made up the packet. Also don't show the AAL5 trailer if
the cell count is zero - the ATM Sniffer *might* sometimes supply a cell
count of 0 even if it has the AAL5 trailer, I guess, and we *might* see
some other capture file format that has the AAL5 trailer but no cell
count, but we'll cross that bridge when we come to it.
Add support for "atmsnoop" captures to the code to handle "snoop"
captures.
Use the field in "iptrace" headers that appears to be, in ATM captures,
a direction indicator - we may have the direction backwards, but, as an
STP packet was tagged as a DCE->DTE packet, and as the capturing
machine, which also was presumably the recipient of the packet, was an
AIX box, not a switch or bridge or some piece of networking equipment
such as that, it *probably* wasn't sending the STP packet, it was
probably receiving it.
svn path=/trunk/; revision=1120
1999-11-27 01:55:44 +00:00
|
|
|
guint32 rec_size;
|
1999-08-22 02:29:40 +00:00
|
|
|
guint32 packet_size;
|
Move the "guess what type of ATM traffic this is" stuff into the ATM
dissector; I don't think it's guaranteed that even a Sniffer will tell
you that (there may be situations where it can't figure it out, and
where the user didn't tell it), we may need it for "atmsnoop" traffic
and other types of ATM traffic as well, we will probably want to add to
it the ability to let the user specify "virtual circuit X.Y is this kind
of traffic", and we may also have Ethereal try to intuit it based on
previous traffic in the capture (Q.2931 call setup, LANE traffic, etc.).
Don't show the cell count if it's zero - assume that means we don't know
how many cells made up the packet. Also don't show the AAL5 trailer if
the cell count is zero - the ATM Sniffer *might* sometimes supply a cell
count of 0 even if it has the AAL5 trailer, I guess, and we *might* see
some other capture file format that has the AAL5 trailer but no cell
count, but we'll cross that bridge when we come to it.
Add support for "atmsnoop" captures to the code to handle "snoop"
captures.
Use the field in "iptrace" headers that appears to be, in ATM captures,
a direction indicator - we may have the direction backwards, but, as an
STP packet was tagged as a DCE->DTE packet, and as the capturing
machine, which also was presumably the recipient of the packet, was an
AIX box, not a switch or bridge or some piece of networking equipment
such as that, it *probably* wasn't sending the STP packet, it was
probably receiving it.
svn path=/trunk/; revision=1120
1999-11-27 01:55:44 +00:00
|
|
|
guint32 orig_size;
|
2000-05-18 09:09:50 +00:00
|
|
|
int data_offset;
|
1998-11-15 05:29:17 +00:00
|
|
|
int bytes_read;
|
|
|
|
struct snooprec_hdr hdr;
|
1999-09-02 00:14:06 +00:00
|
|
|
char padbuf[4];
|
|
|
|
int padbytes;
|
|
|
|
int bytes_to_read;
|
1998-11-15 05:29:17 +00:00
|
|
|
|
|
|
|
/* Read record header. */
|
Have the per-capture-file-type open routines "wtap_open_offline()" calls
return 1 on success, -1 if they got an error, and 0 if the file isn't of
the type that file is checking for, and supply an error code if they
return -1; have "wtap_open_offline()" use that error code. Also, have
the per-capture-file-type open routines treat errors accessing the file
as errors, and return -1, rather than just returning 0 so that we try
another file type.
Have the per-capture-file-type read routines "wtap_loop()" calls return
-1 and supply an error code on error (and not, as they did in some
cases, call "g_error()" and abort), and have "wtap_loop()", if the read
routine returned an error, return FALSE (and pass an error-code-pointer
argument onto the read routines, so they fill it in), and return TRUE on
success.
Add some new error codes for them to return.
Now that "wtap_loop()" can return a success/failure indication and an
error code, in "read_cap_file()" put up a message box if we get an error
reading the file, and return the error code.
Handle the additional errors we can get when opening a capture file.
If the attempt to open a capture file succeeds, but the attempt to read
it fails, don't treat that as a complete failure - we may have managed
to read some of the capture file, and we should display what we managed
to read.
svn path=/trunk/; revision=516
1999-08-19 05:31:38 +00:00
|
|
|
errno = WTAP_ERR_CANT_READ;
|
1999-09-22 01:26:50 +00:00
|
|
|
bytes_read = file_read(&hdr, 1, sizeof hdr, wth->fh);
|
1998-11-15 05:29:17 +00:00
|
|
|
if (bytes_read != sizeof hdr) {
|
1999-10-05 07:06:08 +00:00
|
|
|
*err = file_error(wth->fh);
|
|
|
|
if (*err != 0)
|
Have the per-capture-file-type open routines "wtap_open_offline()" calls
return 1 on success, -1 if they got an error, and 0 if the file isn't of
the type that file is checking for, and supply an error code if they
return -1; have "wtap_open_offline()" use that error code. Also, have
the per-capture-file-type open routines treat errors accessing the file
as errors, and return -1, rather than just returning 0 so that we try
another file type.
Have the per-capture-file-type read routines "wtap_loop()" calls return
-1 and supply an error code on error (and not, as they did in some
cases, call "g_error()" and abort), and have "wtap_loop()", if the read
routine returned an error, return FALSE (and pass an error-code-pointer
argument onto the read routines, so they fill it in), and return TRUE on
success.
Add some new error codes for them to return.
Now that "wtap_loop()" can return a success/failure indication and an
error code, in "read_cap_file()" put up a message box if we get an error
reading the file, and return the error code.
Handle the additional errors we can get when opening a capture file.
If the attempt to open a capture file succeeds, but the attempt to read
it fails, don't treat that as a complete failure - we may have managed
to read some of the capture file, and we should display what we managed
to read.
svn path=/trunk/; revision=516
1999-08-19 05:31:38 +00:00
|
|
|
return -1;
|
1998-11-15 05:29:17 +00:00
|
|
|
if (bytes_read != 0) {
|
Have the per-capture-file-type open routines "wtap_open_offline()" calls
return 1 on success, -1 if they got an error, and 0 if the file isn't of
the type that file is checking for, and supply an error code if they
return -1; have "wtap_open_offline()" use that error code. Also, have
the per-capture-file-type open routines treat errors accessing the file
as errors, and return -1, rather than just returning 0 so that we try
another file type.
Have the per-capture-file-type read routines "wtap_loop()" calls return
-1 and supply an error code on error (and not, as they did in some
cases, call "g_error()" and abort), and have "wtap_loop()", if the read
routine returned an error, return FALSE (and pass an error-code-pointer
argument onto the read routines, so they fill it in), and return TRUE on
success.
Add some new error codes for them to return.
Now that "wtap_loop()" can return a success/failure indication and an
error code, in "read_cap_file()" put up a message box if we get an error
reading the file, and return the error code.
Handle the additional errors we can get when opening a capture file.
If the attempt to open a capture file succeeds, but the attempt to read
it fails, don't treat that as a complete failure - we may have managed
to read some of the capture file, and we should display what we managed
to read.
svn path=/trunk/; revision=516
1999-08-19 05:31:38 +00:00
|
|
|
*err = WTAP_ERR_SHORT_READ;
|
1998-11-15 05:29:17 +00:00
|
|
|
return -1;
|
|
|
|
}
|
|
|
|
return 0;
|
|
|
|
}
|
1999-08-28 01:19:45 +00:00
|
|
|
wth->data_offset += sizeof hdr;
|
1998-11-15 05:29:17 +00:00
|
|
|
|
Move the "guess what type of ATM traffic this is" stuff into the ATM
dissector; I don't think it's guaranteed that even a Sniffer will tell
you that (there may be situations where it can't figure it out, and
where the user didn't tell it), we may need it for "atmsnoop" traffic
and other types of ATM traffic as well, we will probably want to add to
it the ability to let the user specify "virtual circuit X.Y is this kind
of traffic", and we may also have Ethereal try to intuit it based on
previous traffic in the capture (Q.2931 call setup, LANE traffic, etc.).
Don't show the cell count if it's zero - assume that means we don't know
how many cells made up the packet. Also don't show the AAL5 trailer if
the cell count is zero - the ATM Sniffer *might* sometimes supply a cell
count of 0 even if it has the AAL5 trailer, I guess, and we *might* see
some other capture file format that has the AAL5 trailer but no cell
count, but we'll cross that bridge when we come to it.
Add support for "atmsnoop" captures to the code to handle "snoop"
captures.
Use the field in "iptrace" headers that appears to be, in ATM captures,
a direction indicator - we may have the direction backwards, but, as an
STP packet was tagged as a DCE->DTE packet, and as the capturing
machine, which also was presumably the recipient of the packet, was an
AIX box, not a switch or bridge or some piece of networking equipment
such as that, it *probably* wasn't sending the STP packet, it was
probably receiving it.
svn path=/trunk/; revision=1120
1999-11-27 01:55:44 +00:00
|
|
|
rec_size = ntohl(hdr.rec_len);
|
|
|
|
orig_size = ntohl(hdr.orig_len);
|
1998-11-15 05:29:17 +00:00
|
|
|
packet_size = ntohl(hdr.incl_len);
|
1999-08-22 02:29:40 +00:00
|
|
|
if (packet_size > WTAP_MAX_PACKET_SIZE) {
|
|
|
|
/*
|
|
|
|
* Probably a corrupt capture file; don't blow up trying
|
|
|
|
* to allocate space for an immensely-large packet.
|
|
|
|
*/
|
|
|
|
g_message("snoop: File has %u-byte packet, bigger than maximum of %u",
|
|
|
|
packet_size, WTAP_MAX_PACKET_SIZE);
|
|
|
|
*err = WTAP_ERR_BAD_RECORD;
|
|
|
|
return -1;
|
|
|
|
}
|
Move the "guess what type of ATM traffic this is" stuff into the ATM
dissector; I don't think it's guaranteed that even a Sniffer will tell
you that (there may be situations where it can't figure it out, and
where the user didn't tell it), we may need it for "atmsnoop" traffic
and other types of ATM traffic as well, we will probably want to add to
it the ability to let the user specify "virtual circuit X.Y is this kind
of traffic", and we may also have Ethereal try to intuit it based on
previous traffic in the capture (Q.2931 call setup, LANE traffic, etc.).
Don't show the cell count if it's zero - assume that means we don't know
how many cells made up the packet. Also don't show the AAL5 trailer if
the cell count is zero - the ATM Sniffer *might* sometimes supply a cell
count of 0 even if it has the AAL5 trailer, I guess, and we *might* see
some other capture file format that has the AAL5 trailer but no cell
count, but we'll cross that bridge when we come to it.
Add support for "atmsnoop" captures to the code to handle "snoop"
captures.
Use the field in "iptrace" headers that appears to be, in ATM captures,
a direction indicator - we may have the direction backwards, but, as an
STP packet was tagged as a DCE->DTE packet, and as the capturing
machine, which also was presumably the recipient of the packet, was an
AIX box, not a switch or bridge or some piece of networking equipment
such as that, it *probably* wasn't sending the STP packet, it was
probably receiving it.
svn path=/trunk/; revision=1120
1999-11-27 01:55:44 +00:00
|
|
|
|
2000-05-18 09:09:50 +00:00
|
|
|
data_offset = wth->data_offset;
|
|
|
|
|
Move the "guess what type of ATM traffic this is" stuff into the ATM
dissector; I don't think it's guaranteed that even a Sniffer will tell
you that (there may be situations where it can't figure it out, and
where the user didn't tell it), we may need it for "atmsnoop" traffic
and other types of ATM traffic as well, we will probably want to add to
it the ability to let the user specify "virtual circuit X.Y is this kind
of traffic", and we may also have Ethereal try to intuit it based on
previous traffic in the capture (Q.2931 call setup, LANE traffic, etc.).
Don't show the cell count if it's zero - assume that means we don't know
how many cells made up the packet. Also don't show the AAL5 trailer if
the cell count is zero - the ATM Sniffer *might* sometimes supply a cell
count of 0 even if it has the AAL5 trailer, I guess, and we *might* see
some other capture file format that has the AAL5 trailer but no cell
count, but we'll cross that bridge when we come to it.
Add support for "atmsnoop" captures to the code to handle "snoop"
captures.
Use the field in "iptrace" headers that appears to be, in ATM captures,
a direction indicator - we may have the direction backwards, but, as an
STP packet was tagged as a DCE->DTE packet, and as the capturing
machine, which also was presumably the recipient of the packet, was an
AIX box, not a switch or bridge or some piece of networking equipment
such as that, it *probably* wasn't sending the STP packet, it was
probably receiving it.
svn path=/trunk/; revision=1120
1999-11-27 01:55:44 +00:00
|
|
|
/*
|
|
|
|
* If this is an ATM packet, the first four bytes are the
|
|
|
|
* direction of the packet (transmit/receive), the VPI, and
|
|
|
|
* the VCI; read them and generate the pseudo-header from
|
|
|
|
* them.
|
|
|
|
*/
|
|
|
|
if (wth->file_encap == WTAP_ENCAP_ATM_SNIFFER) {
|
|
|
|
if (packet_size < 4) {
|
|
|
|
/*
|
|
|
|
* Uh-oh, the packet isn't big enough to even
|
|
|
|
* have a pseudo-header.
|
|
|
|
*/
|
|
|
|
g_message("snoop: atmsnoop file has a %u-byte packet, too small to have even an ATM pseudo-header\n",
|
|
|
|
packet_size);
|
|
|
|
*err = WTAP_ERR_BAD_RECORD;
|
|
|
|
return -1;
|
|
|
|
}
|
2000-05-18 09:09:50 +00:00
|
|
|
if (snoop_read_atm_pseudoheader(wth->fh, &wth->pseudo_header,
|
|
|
|
err) < 0)
|
|
|
|
return -1; /* Read error */
|
Move the "guess what type of ATM traffic this is" stuff into the ATM
dissector; I don't think it's guaranteed that even a Sniffer will tell
you that (there may be situations where it can't figure it out, and
where the user didn't tell it), we may need it for "atmsnoop" traffic
and other types of ATM traffic as well, we will probably want to add to
it the ability to let the user specify "virtual circuit X.Y is this kind
of traffic", and we may also have Ethereal try to intuit it based on
previous traffic in the capture (Q.2931 call setup, LANE traffic, etc.).
Don't show the cell count if it's zero - assume that means we don't know
how many cells made up the packet. Also don't show the AAL5 trailer if
the cell count is zero - the ATM Sniffer *might* sometimes supply a cell
count of 0 even if it has the AAL5 trailer, I guess, and we *might* see
some other capture file format that has the AAL5 trailer but no cell
count, but we'll cross that bridge when we come to it.
Add support for "atmsnoop" captures to the code to handle "snoop"
captures.
Use the field in "iptrace" headers that appears to be, in ATM captures,
a direction indicator - we may have the direction backwards, but, as an
STP packet was tagged as a DCE->DTE packet, and as the capturing
machine, which also was presumably the recipient of the packet, was an
AIX box, not a switch or bridge or some piece of networking equipment
such as that, it *probably* wasn't sending the STP packet, it was
probably receiving it.
svn path=/trunk/; revision=1120
1999-11-27 01:55:44 +00:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Don't count the pseudo-header as part of the packet.
|
|
|
|
*/
|
|
|
|
rec_size -= 4;
|
|
|
|
orig_size -= 4;
|
|
|
|
packet_size -= 4;
|
|
|
|
wth->data_offset += 4;
|
|
|
|
}
|
|
|
|
|
1999-03-01 18:57:07 +00:00
|
|
|
buffer_assure_space(wth->frame_buffer, packet_size);
|
2000-05-18 09:09:50 +00:00
|
|
|
if (snoop_read_rec_data(wth->fh, buffer_start_ptr(wth->frame_buffer),
|
|
|
|
packet_size, err) < 0)
|
|
|
|
return -1; /* Read error */
|
1999-08-28 01:19:45 +00:00
|
|
|
wth->data_offset += packet_size;
|
1998-11-15 05:29:17 +00:00
|
|
|
|
|
|
|
wth->phdr.ts.tv_sec = ntohl(hdr.ts_sec);
|
|
|
|
wth->phdr.ts.tv_usec = ntohl(hdr.ts_usec);
|
|
|
|
wth->phdr.caplen = packet_size;
|
Move the "guess what type of ATM traffic this is" stuff into the ATM
dissector; I don't think it's guaranteed that even a Sniffer will tell
you that (there may be situations where it can't figure it out, and
where the user didn't tell it), we may need it for "atmsnoop" traffic
and other types of ATM traffic as well, we will probably want to add to
it the ability to let the user specify "virtual circuit X.Y is this kind
of traffic", and we may also have Ethereal try to intuit it based on
previous traffic in the capture (Q.2931 call setup, LANE traffic, etc.).
Don't show the cell count if it's zero - assume that means we don't know
how many cells made up the packet. Also don't show the AAL5 trailer if
the cell count is zero - the ATM Sniffer *might* sometimes supply a cell
count of 0 even if it has the AAL5 trailer, I guess, and we *might* see
some other capture file format that has the AAL5 trailer but no cell
count, but we'll cross that bridge when we come to it.
Add support for "atmsnoop" captures to the code to handle "snoop"
captures.
Use the field in "iptrace" headers that appears to be, in ATM captures,
a direction indicator - we may have the direction backwards, but, as an
STP packet was tagged as a DCE->DTE packet, and as the capturing
machine, which also was presumably the recipient of the packet, was an
AIX box, not a switch or bridge or some piece of networking equipment
such as that, it *probably* wasn't sending the STP packet, it was
probably receiving it.
svn path=/trunk/; revision=1120
1999-11-27 01:55:44 +00:00
|
|
|
wth->phdr.len = orig_size;
|
1999-03-01 18:57:07 +00:00
|
|
|
wth->phdr.pkt_encap = wth->file_encap;
|
1998-11-15 05:29:17 +00:00
|
|
|
|
1999-09-02 00:14:06 +00:00
|
|
|
/*
|
|
|
|
* Skip over the padding (don't "fseek()", as the standard
|
|
|
|
* I/O library on some platforms discards buffered data if
|
|
|
|
* you do that, which means it does a lot more reads).
|
|
|
|
* There's probably not much padding (it's probably padded only
|
|
|
|
* to a 4-byte boundary), so we probably need only do one read.
|
|
|
|
*/
|
Move the "guess what type of ATM traffic this is" stuff into the ATM
dissector; I don't think it's guaranteed that even a Sniffer will tell
you that (there may be situations where it can't figure it out, and
where the user didn't tell it), we may need it for "atmsnoop" traffic
and other types of ATM traffic as well, we will probably want to add to
it the ability to let the user specify "virtual circuit X.Y is this kind
of traffic", and we may also have Ethereal try to intuit it based on
previous traffic in the capture (Q.2931 call setup, LANE traffic, etc.).
Don't show the cell count if it's zero - assume that means we don't know
how many cells made up the packet. Also don't show the AAL5 trailer if
the cell count is zero - the ATM Sniffer *might* sometimes supply a cell
count of 0 even if it has the AAL5 trailer, I guess, and we *might* see
some other capture file format that has the AAL5 trailer but no cell
count, but we'll cross that bridge when we come to it.
Add support for "atmsnoop" captures to the code to handle "snoop"
captures.
Use the field in "iptrace" headers that appears to be, in ATM captures,
a direction indicator - we may have the direction backwards, but, as an
STP packet was tagged as a DCE->DTE packet, and as the capturing
machine, which also was presumably the recipient of the packet, was an
AIX box, not a switch or bridge or some piece of networking equipment
such as that, it *probably* wasn't sending the STP packet, it was
probably receiving it.
svn path=/trunk/; revision=1120
1999-11-27 01:55:44 +00:00
|
|
|
padbytes = rec_size - (sizeof hdr + packet_size);
|
1999-09-02 00:14:06 +00:00
|
|
|
while (padbytes != 0) {
|
|
|
|
bytes_to_read = padbytes;
|
|
|
|
if (bytes_to_read > sizeof padbuf)
|
|
|
|
bytes_to_read = sizeof padbuf;
|
|
|
|
errno = WTAP_ERR_CANT_READ;
|
1999-09-22 01:26:50 +00:00
|
|
|
bytes_read = file_read(padbuf, 1, bytes_to_read, wth->fh);
|
1999-09-02 00:14:06 +00:00
|
|
|
if (bytes_read != bytes_to_read) {
|
1999-10-05 07:06:08 +00:00
|
|
|
*err = file_error(wth->fh);
|
|
|
|
if (*err == 0)
|
1999-09-02 00:14:06 +00:00
|
|
|
*err = WTAP_ERR_SHORT_READ;
|
|
|
|
return -1;
|
|
|
|
}
|
|
|
|
wth->data_offset += bytes_read;
|
|
|
|
padbytes -= bytes_read;
|
|
|
|
}
|
1998-11-15 05:29:17 +00:00
|
|
|
|
|
|
|
return data_offset;
|
|
|
|
}
|
1999-12-04 03:36:22 +00:00
|
|
|
|
2000-05-18 09:09:50 +00:00
|
|
|
static int
|
|
|
|
snoop_seek_read(wtap *wth, int seek_off,
|
|
|
|
union pseudo_header *pseudo_header, u_char *pd, int length)
|
|
|
|
{
|
|
|
|
int ret;
|
|
|
|
int err; /* XXX - return this */
|
|
|
|
|
|
|
|
file_seek(wth->random_fh, seek_off, SEEK_SET);
|
|
|
|
|
|
|
|
if (wth->file_encap == WTAP_ENCAP_ATM_SNIFFER) {
|
|
|
|
ret = snoop_read_atm_pseudoheader(wth->random_fh, pseudo_header,
|
|
|
|
&err);
|
|
|
|
if (ret < 0) {
|
|
|
|
/* Read error */
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Read the packet data.
|
|
|
|
*/
|
|
|
|
return snoop_read_rec_data(wth->random_fh, pd, length, &err);
|
|
|
|
}
|
|
|
|
|
|
|
|
static int
|
|
|
|
snoop_read_atm_pseudoheader(FILE_T *fh, union pseudo_header *pseudo_header,
|
|
|
|
int *err)
|
|
|
|
{
|
|
|
|
char atm_phdr[4];
|
|
|
|
int bytes_read;
|
|
|
|
|
|
|
|
errno = WTAP_ERR_CANT_READ;
|
|
|
|
bytes_read = file_read(atm_phdr, 1, 4, fh);
|
|
|
|
if (bytes_read != 4) {
|
|
|
|
*err = file_error(fh);
|
|
|
|
if (*err == 0)
|
|
|
|
*err = WTAP_ERR_SHORT_READ;
|
|
|
|
return -1;
|
|
|
|
}
|
|
|
|
|
|
|
|
pseudo_header->ngsniffer_atm.channel = (atm_phdr[0] & 0x80) ? 1 : 0;
|
|
|
|
pseudo_header->ngsniffer_atm.Vpi = atm_phdr[1];
|
|
|
|
pseudo_header->ngsniffer_atm.Vci = pntohs(&atm_phdr[2]);
|
|
|
|
|
|
|
|
/* We don't have this information */
|
|
|
|
pseudo_header->ngsniffer_atm.cells = 0;
|
|
|
|
pseudo_header->ngsniffer_atm.aal5t_u2u = 0;
|
|
|
|
pseudo_header->ngsniffer_atm.aal5t_len = 0;
|
|
|
|
pseudo_header->ngsniffer_atm.aal5t_chksum = 0;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Assume it's AAL5; we know nothing more about it.
|
|
|
|
*
|
|
|
|
* For what it's worth, in one "atmsnoop" capture,
|
|
|
|
* the lower 7 bits of the first byte of the header
|
|
|
|
* were 0x05 for ILMI traffic, 0x06 for Signalling
|
|
|
|
* AAL traffic, and 0x02 for at least some RFC 1483-style
|
|
|
|
* LLC multiplexed traffic.
|
|
|
|
*/
|
|
|
|
pseudo_header->ngsniffer_atm.AppTrafType = ATT_AAL5|ATT_HL_UNKNOWN;
|
|
|
|
pseudo_header->ngsniffer_atm.AppHLType = AHLT_UNKNOWN;
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
static int
|
|
|
|
snoop_read_rec_data(FILE_T *fh, char *pd, int length, int *err)
|
|
|
|
{
|
|
|
|
int bytes_read;
|
|
|
|
|
|
|
|
errno = WTAP_ERR_CANT_READ;
|
|
|
|
bytes_read = file_read(pd, 1, length, fh);
|
|
|
|
|
|
|
|
if (bytes_read != length) {
|
|
|
|
*err = file_error(fh);
|
|
|
|
if (*err == 0)
|
|
|
|
*err = WTAP_ERR_SHORT_READ;
|
|
|
|
return -1;
|
|
|
|
}
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
1999-12-04 08:32:14 +00:00
|
|
|
static const int wtap_encap[] = {
|
|
|
|
-1, /* WTAP_ENCAP_UNKNOWN -> unsupported */
|
|
|
|
0x04, /* WTAP_ENCAP_ETHERNET -> DL_ETHER */
|
|
|
|
0x02, /* WTAP_ENCAP_TR -> DL_TPR */
|
|
|
|
-1, /* WTAP_ENCAP_SLIP -> unsupported */
|
|
|
|
-1, /* WTAP_ENCAP_PPP -> unsupported */
|
|
|
|
0x08, /* WTAP_ENCAP_FDDI -> DL_FDDI */
|
|
|
|
0x08, /* WTAP_ENCAP_FDDI_BITSWAPPED -> DL_FDDI */
|
|
|
|
-1, /* WTAP_ENCAP_RAW_IP -> unsupported */
|
|
|
|
-1, /* WTAP_ENCAP_ARCNET -> unsupported */
|
|
|
|
-1, /* WTAP_ENCAP_ATM_RFC1483 -> unsupported */
|
|
|
|
-1, /* WTAP_ENCAP_LINUX_ATM_CLIP -> unsupported */
|
|
|
|
-1, /* WTAP_ENCAP_LAPB -> unsupported*/
|
|
|
|
-1, /* WTAP_ENCAP_ATM_SNIFFER -> unsupported */
|
|
|
|
0 /* WTAP_ENCAP_NULL -> DLT_NULL */
|
|
|
|
};
|
|
|
|
#define NUM_WTAP_ENCAPS (sizeof wtap_encap / sizeof wtap_encap[0])
|
|
|
|
|
|
|
|
/* Returns 0 if we could write the specified encapsulation type,
|
|
|
|
an error indication otherwise. */
|
1999-12-04 09:38:38 +00:00
|
|
|
int snoop_dump_can_write_encap(int filetype, int encap)
|
1999-12-04 08:32:14 +00:00
|
|
|
{
|
|
|
|
/* Per-packet encapsulations aren't supported. */
|
|
|
|
if (encap == WTAP_ENCAP_PER_PACKET)
|
|
|
|
return WTAP_ERR_ENCAP_PER_PACKET_UNSUPPORTED;
|
|
|
|
|
|
|
|
if (encap < 0 || encap >= NUM_WTAP_ENCAPS || wtap_encap[encap] == -1)
|
|
|
|
return WTAP_ERR_UNSUPPORTED_ENCAP;
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
1999-12-04 05:14:39 +00:00
|
|
|
/* Returns TRUE on success, FALSE on failure; sets "*err" to an error code on
|
1999-12-04 03:36:22 +00:00
|
|
|
failure */
|
1999-12-04 05:14:39 +00:00
|
|
|
gboolean snoop_dump_open(wtap_dumper *wdh, int *err)
|
1999-12-04 03:36:22 +00:00
|
|
|
{
|
|
|
|
struct snoop_hdr file_hdr;
|
|
|
|
int nwritten;
|
|
|
|
|
|
|
|
/* This is a snoop file */
|
|
|
|
wdh->subtype_write = snoop_dump;
|
1999-12-04 08:32:14 +00:00
|
|
|
wdh->subtype_close = NULL;
|
1999-12-04 03:36:22 +00:00
|
|
|
|
|
|
|
/* Write the file header. */
|
|
|
|
nwritten = fwrite(&snoop_magic, 1, sizeof snoop_magic, wdh->fh);
|
|
|
|
if (nwritten != sizeof snoop_magic) {
|
|
|
|
if (nwritten < 0)
|
|
|
|
*err = errno;
|
|
|
|
else
|
|
|
|
*err = WTAP_ERR_SHORT_WRITE;
|
1999-12-04 05:14:39 +00:00
|
|
|
return FALSE;
|
1999-12-04 03:36:22 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
/* current "snoop" format is 2 */
|
1999-12-04 11:19:04 +00:00
|
|
|
file_hdr.version = htonl(2);
|
|
|
|
file_hdr.network = htonl(wtap_encap[wdh->encap]);
|
1999-12-04 03:36:22 +00:00
|
|
|
nwritten = fwrite(&file_hdr, 1, sizeof file_hdr, wdh->fh);
|
|
|
|
if (nwritten != sizeof file_hdr) {
|
|
|
|
if (nwritten < 0)
|
|
|
|
*err = errno;
|
|
|
|
else
|
|
|
|
*err = WTAP_ERR_SHORT_WRITE;
|
1999-12-04 05:14:39 +00:00
|
|
|
return FALSE;
|
1999-12-04 03:36:22 +00:00
|
|
|
}
|
|
|
|
|
1999-12-04 05:14:39 +00:00
|
|
|
return TRUE;
|
1999-12-04 03:36:22 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
/* Write a record for a packet to a dump file.
|
1999-12-04 05:14:39 +00:00
|
|
|
Returns TRUE on success, FALSE on failure. */
|
|
|
|
static gboolean snoop_dump(wtap_dumper *wdh, const struct wtap_pkthdr *phdr,
|
2000-05-18 09:09:50 +00:00
|
|
|
const union pseudo_header *pseudo_header, const u_char *pd, int *err)
|
1999-12-04 03:36:22 +00:00
|
|
|
{
|
|
|
|
struct snooprec_hdr rec_hdr;
|
|
|
|
int nwritten;
|
|
|
|
int reclen;
|
|
|
|
int padlen;
|
|
|
|
static char zeroes[4];
|
|
|
|
|
|
|
|
/* Record length = header length plus data length... */
|
|
|
|
reclen = sizeof rec_hdr + phdr->caplen;
|
|
|
|
|
|
|
|
/* ... plus enough bytes to pad it to a 4-byte boundary. */
|
|
|
|
padlen = ((reclen + 3) & ~3) - reclen;
|
|
|
|
reclen += padlen;
|
|
|
|
|
|
|
|
rec_hdr.orig_len = htonl(phdr->len);
|
|
|
|
rec_hdr.incl_len = htonl(phdr->caplen);
|
|
|
|
rec_hdr.rec_len = htonl(reclen);
|
|
|
|
rec_hdr.cum_drops = 0;
|
|
|
|
rec_hdr.ts_sec = htonl(phdr->ts.tv_sec);
|
|
|
|
rec_hdr.ts_usec = htonl(phdr->ts.tv_usec);
|
|
|
|
nwritten = fwrite(&rec_hdr, 1, sizeof rec_hdr, wdh->fh);
|
|
|
|
if (nwritten != sizeof rec_hdr) {
|
|
|
|
if (nwritten < 0)
|
|
|
|
*err = errno;
|
|
|
|
else
|
|
|
|
*err = WTAP_ERR_SHORT_WRITE;
|
1999-12-04 05:14:39 +00:00
|
|
|
return FALSE;
|
1999-12-04 03:36:22 +00:00
|
|
|
}
|
|
|
|
nwritten = fwrite(pd, 1, phdr->caplen, wdh->fh);
|
|
|
|
if (nwritten != phdr->caplen) {
|
|
|
|
if (nwritten < 0)
|
|
|
|
*err = errno;
|
|
|
|
else
|
|
|
|
*err = WTAP_ERR_SHORT_WRITE;
|
1999-12-04 05:14:39 +00:00
|
|
|
return FALSE;
|
1999-12-04 03:36:22 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
/* Now write the padding. */
|
|
|
|
nwritten = fwrite(zeroes, 1, padlen, wdh->fh);
|
|
|
|
if (nwritten != padlen) {
|
|
|
|
if (nwritten < 0)
|
|
|
|
*err = errno;
|
|
|
|
else
|
|
|
|
*err = WTAP_ERR_SHORT_WRITE;
|
1999-12-04 05:14:39 +00:00
|
|
|
return FALSE;
|
1999-12-04 03:36:22 +00:00
|
|
|
}
|
1999-12-04 05:14:39 +00:00
|
|
|
return TRUE;
|
1999-12-04 03:36:22 +00:00
|
|
|
}
|