1998-11-15 05:29:17 +00:00
|
|
|
/* snoop.c
|
|
|
|
*
|
2002-07-16 07:15:09 +00:00
|
|
|
* $Id: snoop.c,v 1.53 2002/07/16 07:15:09 guy Exp $
|
1998-11-15 05:29:17 +00:00
|
|
|
*
|
|
|
|
* Wiretap Library
|
2001-11-13 23:55:44 +00:00
|
|
|
* Copyright (c) 1998 by Gilbert Ramirez <gram@alumni.rice.edu>
|
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.
|
|
|
|
*/
|
2002-02-27 08:57:25 +00:00
|
|
|
|
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>
|
2000-11-17 21:00:40 +00:00
|
|
|
#include <string.h>
|
2000-05-19 23:07:04 +00:00
|
|
|
#include "wtap-int.h"
|
2000-01-13 07:09:20 +00:00
|
|
|
#include "file_wrappers.h"
|
1999-03-01 18:57:07 +00:00
|
|
|
#include "buffer.h"
|
2002-04-30 18:58:16 +00:00
|
|
|
#include "atm.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 */
|
|
|
|
};
|
|
|
|
|
2002-04-30 09:23:29 +00:00
|
|
|
/*
|
|
|
|
* The link-layer header on ATM packets.
|
|
|
|
*/
|
|
|
|
struct snoop_atm_hdr {
|
|
|
|
guint8 flags; /* destination and traffic type */
|
|
|
|
guint8 vpi; /* VPI */
|
|
|
|
guint16 vci; /* VCI */
|
|
|
|
};
|
|
|
|
|
2001-10-04 08:30:36 +00:00
|
|
|
static gboolean snoop_read(wtap *wth, int *err, long *data_offset);
|
2002-03-05 08:40:27 +00:00
|
|
|
static gboolean snoop_seek_read(wtap *wth, long seek_off,
|
2002-03-05 05:58:41 +00:00
|
|
|
union wtap_pseudo_header *pseudo_header, u_char *pd, int length, int *err);
|
2002-03-05 08:40:27 +00:00
|
|
|
static gboolean snoop_read_atm_pseudoheader(FILE_T fh,
|
2000-05-19 23:07:04 +00:00
|
|
|
union wtap_pseudo_header *pseudo_header, int *err);
|
2002-03-05 08:40:27 +00:00
|
|
|
static gboolean snoop_read_rec_data(FILE_T fh, u_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-19 23:07:04 +00:00
|
|
|
const union wtap_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.
|
Sigh. Shomiti apparently didn't know that the RFC 1761 data link types
were just DLPI data link types, and didn't know that the list had
expanded at some point and that Sun *used* some of the new types (e.g.,
in atmsnoop), or decided on their own to go beyond those types to encode
an Oh-So-Useful link speed indication, or just didn't *care* that they
were just DLPI data link types.
Therefore, we have to map Shomiti link types to wiretap types using a
different mapping table. For now, we assume files with a version number
of 2 are snoop files, and version numbers of 3, 4, and 5 are Shomiti
files; Shomiti claims to use a version number of 2 as well, but to
determine whether a file with a version number of 2 is a snoop file or a
Shomiti file requires that we look at the header of the first packet and
assume that if there's more than 3 bytes of padding it's a Shomiti file.
The return value from "fwrite()" is a "size_t"; make the variable into
which we store it a "size_t", and then fix up the bugs that were
revealed by the compiler warnings that produced - "fwrite()" returns 0,
not a negative number, on an I/O error.
svn path=/trunk/; revision=3866
2001-08-25 02:56:31 +00:00
|
|
|
*
|
|
|
|
* See
|
|
|
|
*
|
|
|
|
* http://www.shomiti.com/support/TNCapFileFormat.htm
|
|
|
|
*
|
|
|
|
* for information on Shomiti's mutant flavor of snoop. For some unknown
|
|
|
|
* unknown reason, they decided not to just Go With The DLPI Flow, and
|
|
|
|
* instead used the types unspecified in RFC 1461 for their own nefarious
|
|
|
|
* purposes, such as distinguishing 10MB from 100MB from 1000MB Ethernet
|
|
|
|
* and distinguishing 4MB from 16MB Token Ring, and distinguishing both
|
|
|
|
* of them from the "Shomiti" versions of same.
|
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 */
|
2000-09-21 04:41:37 +00:00
|
|
|
WTAP_ENCAP_TOKEN_RING,
|
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])
|
Sigh. Shomiti apparently didn't know that the RFC 1761 data link types
were just DLPI data link types, and didn't know that the list had
expanded at some point and that Sun *used* some of the new types (e.g.,
in atmsnoop), or decided on their own to go beyond those types to encode
an Oh-So-Useful link speed indication, or just didn't *care* that they
were just DLPI data link types.
Therefore, we have to map Shomiti link types to wiretap types using a
different mapping table. For now, we assume files with a version number
of 2 are snoop files, and version numbers of 3, 4, and 5 are Shomiti
files; Shomiti claims to use a version number of 2 as well, but to
determine whether a file with a version number of 2 is a snoop file or a
Shomiti file requires that we look at the header of the first packet and
assume that if there's more than 3 bytes of padding it's a Shomiti file.
The return value from "fwrite()" is a "size_t"; make the variable into
which we store it a "size_t", and then fix up the bugs that were
revealed by the compiler warnings that produced - "fwrite()" returns 0,
not a negative number, on an I/O error.
svn path=/trunk/; revision=3866
2001-08-25 02:56:31 +00:00
|
|
|
static const int shomiti_encap[] = {
|
|
|
|
WTAP_ENCAP_ETHERNET, /* IEEE 802.3 */
|
|
|
|
WTAP_ENCAP_UNKNOWN, /* IEEE 802.4 Token Bus */
|
|
|
|
WTAP_ENCAP_TOKEN_RING,
|
|
|
|
WTAP_ENCAP_UNKNOWN, /* IEEE 802.6 Metro Net */
|
|
|
|
WTAP_ENCAP_ETHERNET,
|
|
|
|
WTAP_ENCAP_UNKNOWN, /* HDLC */
|
|
|
|
WTAP_ENCAP_UNKNOWN, /* Character Synchronous, e.g. bisync */
|
|
|
|
WTAP_ENCAP_UNKNOWN, /* IBM Channel-to-Channel */
|
|
|
|
WTAP_ENCAP_FDDI_BITSWAPPED,
|
|
|
|
WTAP_ENCAP_UNKNOWN, /* Other */
|
|
|
|
WTAP_ENCAP_ETHERNET, /* Fast Ethernet */
|
|
|
|
WTAP_ENCAP_TOKEN_RING, /* 4MB 802.5 token ring */
|
|
|
|
WTAP_ENCAP_ETHERNET, /* Gigabit Ethernet */
|
|
|
|
WTAP_ENCAP_TOKEN_RING, /* "IEEE 802.5 Shomiti" */
|
|
|
|
WTAP_ENCAP_TOKEN_RING, /* "4MB IEEE 802.5 Shomiti" */
|
|
|
|
};
|
|
|
|
#define NUM_SHOMITI_ENCAPS (sizeof shomiti_encap / sizeof shomiti_encap[0])
|
|
|
|
int file_encap;
|
1998-11-15 05:29:17 +00:00
|
|
|
|
|
|
|
/* Read in the string that should be at the start of 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
|
|
|
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
|
|
|
|
Sigh. Shomiti apparently didn't know that the RFC 1761 data link types
were just DLPI data link types, and didn't know that the list had
expanded at some point and that Sun *used* some of the new types (e.g.,
in atmsnoop), or decided on their own to go beyond those types to encode
an Oh-So-Useful link speed indication, or just didn't *care* that they
were just DLPI data link types.
Therefore, we have to map Shomiti link types to wiretap types using a
different mapping table. For now, we assume files with a version number
of 2 are snoop files, and version numbers of 3, 4, and 5 are Shomiti
files; Shomiti claims to use a version number of 2 as well, but to
determine whether a file with a version number of 2 is a snoop file or a
Shomiti file requires that we look at the header of the first packet and
assume that if there's more than 3 bytes of padding it's a Shomiti file.
The return value from "fwrite()" is a "size_t"; make the variable into
which we store it a "size_t", and then fix up the bugs that were
revealed by the compiler warnings that produced - "fwrite()" returns 0,
not a negative number, on an I/O error.
svn path=/trunk/; revision=3866
2001-08-25 02:56:31 +00:00
|
|
|
/*
|
|
|
|
* Oh, this is lovely.
|
|
|
|
*
|
|
|
|
* I suppose Shomiti could give a bunch of lawyerly noise about
|
|
|
|
* how "well, RFC 1761 said they were unassigned, and that's
|
|
|
|
* the standard, not the DLPI header file, so it's perfectly OK
|
|
|
|
* for us to use them, blah blah blah", but it's still irritating
|
|
|
|
* as hell that they used the unassigned-in-RFC-1761 values for
|
|
|
|
* their own purposes - especially given that Sun also used
|
|
|
|
* one of them in atmsnoop.
|
|
|
|
*
|
|
|
|
* For now, we treat a version number of 2 as indicating that
|
|
|
|
* this is a Sun snoop file, and version numbers of 3, 4, and 5
|
|
|
|
* as indicating that this is a Shomiti file, even though
|
|
|
|
* their capture file format documentation claims that they
|
|
|
|
* use 2 if the data "was captured using an NDIS card", which
|
|
|
|
* presumably means "captured with an ordinary boring network
|
|
|
|
* card via NDIS" as opposed to "captured with our whizzo
|
|
|
|
* special capture hardware".
|
|
|
|
*
|
|
|
|
* This runs the risk that we may misinterpret the network
|
|
|
|
* type of Shomiti captures not done using their hardware.
|
|
|
|
* Currently, the only not-in-RFC-1761 type we interpret in
|
|
|
|
* Sun snoop files is 18, for atmsnoop, and that's not used
|
|
|
|
* by Shomiti, but if any of the types used by Shomiti are
|
|
|
|
* also used by Snoop or a variant thereof - e.g.:
|
|
|
|
*
|
|
|
|
* value snoop Shomiti
|
|
|
|
* 10 Frame Relay 100MB Ethernet
|
|
|
|
* 11 MP over Frame Relay 4MB 802.5
|
|
|
|
* 12 "Character Async" 1000MB Ethernet
|
|
|
|
* 13 X.25 Classical IP "IEEE 802.5 Shomiti"
|
|
|
|
* 14 "software loopback" "4MB IEEE 802.5 Shomiti"
|
|
|
|
*
|
|
|
|
* then we have a problem that may be resolvable only by checking
|
|
|
|
* how much padding there is in the first packet - if there're 3
|
|
|
|
* bytes or less, it's probably Sun snoop, which uses the padding
|
|
|
|
* only for padding, but if there's more, it's probably a Shomiti
|
|
|
|
* tool, which uses the padding for additional information.
|
|
|
|
*/
|
1998-11-15 05:29:17 +00:00
|
|
|
hdr.version = ntohl(hdr.version);
|
Sigh. Shomiti apparently didn't know that the RFC 1761 data link types
were just DLPI data link types, and didn't know that the list had
expanded at some point and that Sun *used* some of the new types (e.g.,
in atmsnoop), or decided on their own to go beyond those types to encode
an Oh-So-Useful link speed indication, or just didn't *care* that they
were just DLPI data link types.
Therefore, we have to map Shomiti link types to wiretap types using a
different mapping table. For now, we assume files with a version number
of 2 are snoop files, and version numbers of 3, 4, and 5 are Shomiti
files; Shomiti claims to use a version number of 2 as well, but to
determine whether a file with a version number of 2 is a snoop file or a
Shomiti file requires that we look at the header of the first packet and
assume that if there's more than 3 bytes of padding it's a Shomiti file.
The return value from "fwrite()" is a "size_t"; make the variable into
which we store it a "size_t", and then fix up the bugs that were
revealed by the compiler warnings that produced - "fwrite()" returns 0,
not a negative number, on an I/O error.
svn path=/trunk/; revision=3866
2001-08-25 02:56:31 +00:00
|
|
|
hdr.network = ntohl(hdr.network);
|
2000-09-19 05:12:11 +00:00
|
|
|
switch (hdr.version) {
|
|
|
|
|
|
|
|
case 2: /* Solaris 2.x and later snoop, and Shomiti
|
Sigh. Shomiti apparently didn't know that the RFC 1761 data link types
were just DLPI data link types, and didn't know that the list had
expanded at some point and that Sun *used* some of the new types (e.g.,
in atmsnoop), or decided on their own to go beyond those types to encode
an Oh-So-Useful link speed indication, or just didn't *care* that they
were just DLPI data link types.
Therefore, we have to map Shomiti link types to wiretap types using a
different mapping table. For now, we assume files with a version number
of 2 are snoop files, and version numbers of 3, 4, and 5 are Shomiti
files; Shomiti claims to use a version number of 2 as well, but to
determine whether a file with a version number of 2 is a snoop file or a
Shomiti file requires that we look at the header of the first packet and
assume that if there's more than 3 bytes of padding it's a Shomiti file.
The return value from "fwrite()" is a "size_t"; make the variable into
which we store it a "size_t", and then fix up the bugs that were
revealed by the compiler warnings that produced - "fwrite()" returns 0,
not a negative number, on an I/O error.
svn path=/trunk/; revision=3866
2001-08-25 02:56:31 +00:00
|
|
|
Surveyor prior to 3.0 (or 3.x with NDIS card?) */
|
|
|
|
if (hdr.network >= NUM_SNOOP_ENCAPS
|
|
|
|
|| snoop_encap[hdr.network] == WTAP_ENCAP_UNKNOWN) {
|
|
|
|
g_message("snoop: network type %u unknown or unsupported",
|
|
|
|
hdr.network);
|
|
|
|
*err = WTAP_ERR_UNSUPPORTED_ENCAP;
|
|
|
|
return -1;
|
|
|
|
}
|
|
|
|
file_encap = snoop_encap[hdr.network];
|
|
|
|
break;
|
|
|
|
|
|
|
|
case 3: /* Surveyor 3.0 and later, with Shomiti CMM2 hardware */
|
|
|
|
case 4: /* Surveyor 3.0 and later, with Shomiti GAM hardware */
|
|
|
|
case 5: /* Surveyor 3.0 and later, with Shomiti THG hardware */
|
|
|
|
if (hdr.network >= NUM_SHOMITI_ENCAPS
|
|
|
|
|| shomiti_encap[hdr.network] == WTAP_ENCAP_UNKNOWN) {
|
|
|
|
g_message("snoop: Shomiti network type %u unknown or unsupported",
|
|
|
|
hdr.network);
|
|
|
|
*err = WTAP_ERR_UNSUPPORTED_ENCAP;
|
|
|
|
return -1;
|
|
|
|
}
|
|
|
|
file_encap = shomiti_encap[hdr.network];
|
2000-09-19 05:12:11 +00:00
|
|
|
break;
|
|
|
|
|
|
|
|
default:
|
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
|
|
|
}
|
|
|
|
|
|
|
|
/* 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;
|
Sigh. Shomiti apparently didn't know that the RFC 1761 data link types
were just DLPI data link types, and didn't know that the list had
expanded at some point and that Sun *used* some of the new types (e.g.,
in atmsnoop), or decided on their own to go beyond those types to encode
an Oh-So-Useful link speed indication, or just didn't *care* that they
were just DLPI data link types.
Therefore, we have to map Shomiti link types to wiretap types using a
different mapping table. For now, we assume files with a version number
of 2 are snoop files, and version numbers of 3, 4, and 5 are Shomiti
files; Shomiti claims to use a version number of 2 as well, but to
determine whether a file with a version number of 2 is a snoop file or a
Shomiti file requires that we look at the header of the first packet and
assume that if there's more than 3 bytes of padding it's a Shomiti file.
The return value from "fwrite()" is a "size_t"; make the variable into
which we store it a "size_t", and then fix up the bugs that were
revealed by the compiler warnings that produced - "fwrite()" returns 0,
not a negative number, on an I/O error.
svn path=/trunk/; revision=3866
2001-08-25 02:56:31 +00:00
|
|
|
wth->file_encap = file_encap;
|
Have Wiretap set the snapshot length to 0 if it can't be derived from
reading the capture file. Have callers of "wtap_snapshot_length()"
treat a value of 0 as "unknown", and default to WTAP_MAX_PACKET_SIZE (so
that, when writing a capture file in a format that *does* store the
snapshot length, we can at least put *something* in the file).
If we don't know the snapshot length of the current capture file, don't
display a value in the summary window.
Don't use "cfile.snap" as the snapshot length option when capturing -
doing so causes Ethereal to default, when capturing, to the snapshot
length of the last capture file that you read in, rather than to the
snapshot length of the last capture you did (or the initial default of
"no snapshot length").
Redo the "Capture Options" dialog box to group options into sections
with frames around them, and add units to the snapshot length, maximum
file size, and capture duration options, as per a suggestion by Ulf
Lamping. Also add units to the capture count option.
Make the snapshot length, capture count, maximum file size, and capture
duration options into a combination of a check box and a spin button.
If the check box is not checked, the limit in question is inactive
(snapshot length of 65535, no max packet count, no max file size, no max
capture duration); if it's checked, the spinbox specifies the limit.
Default all of the check boxes to "not checked" and all of the spin
boxes to small values.
Use "gtk_toggle_button_get_active()" rather than directly fetching the
state of a check box.
svn path=/trunk/; revision=4709
2002-02-08 10:07:41 +00:00
|
|
|
wth->snapshot_length = 0; /* 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 */
|
2001-10-04 08:30:36 +00:00
|
|
|
static gboolean snoop_read(wtap *wth, int *err, long *data_offset)
|
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;
|
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);
|
2000-09-07 05:34:23 +00:00
|
|
|
if (*err == 0 && 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
|
|
|
}
|
2000-09-07 05:34:23 +00:00
|
|
|
return FALSE;
|
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
|
|
|
|
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;
|
2000-09-07 05:34:23 +00:00
|
|
|
return FALSE;
|
1999-08-22 02:29:40 +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
|
|
|
|
2000-09-07 05:34:23 +00:00
|
|
|
*data_offset = wth->data_offset;
|
2000-05-18 09:09:50 +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
|
|
|
/*
|
|
|
|
* 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) {
|
2002-04-30 09:23:29 +00:00
|
|
|
if (packet_size < sizeof (struct snoop_atm_hdr)) {
|
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
|
|
|
/*
|
|
|
|
* 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;
|
2000-09-07 05:34:23 +00:00
|
|
|
return FALSE;
|
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
|
|
|
}
|
2002-03-05 08:40:27 +00:00
|
|
|
if (!snoop_read_atm_pseudoheader(wth->fh, &wth->pseudo_header,
|
|
|
|
err))
|
2000-09-07 05:34:23 +00:00
|
|
|
return FALSE; /* 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.
|
|
|
|
*/
|
2002-04-30 09:23:29 +00:00
|
|
|
rec_size -= sizeof (struct snoop_atm_hdr);
|
|
|
|
orig_size -= sizeof (struct snoop_atm_hdr);
|
|
|
|
packet_size -= sizeof (struct snoop_atm_hdr);
|
|
|
|
wth->data_offset += sizeof (struct snoop_atm_hdr);
|
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-03-01 18:57:07 +00:00
|
|
|
buffer_assure_space(wth->frame_buffer, packet_size);
|
2002-03-05 08:40:27 +00:00
|
|
|
if (!snoop_read_rec_data(wth->fh, buffer_start_ptr(wth->frame_buffer),
|
|
|
|
packet_size, err))
|
2000-09-07 05:34:23 +00:00
|
|
|
return FALSE; /* 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
|
|
|
|
2002-04-30 18:58:16 +00:00
|
|
|
/*
|
|
|
|
* If this is ATM LANE traffic, try to guess what type of LANE
|
|
|
|
* traffic it is based on the packet contents.
|
|
|
|
*/
|
|
|
|
if (wth->file_encap == WTAP_ENCAP_ATM_SNIFFER &&
|
|
|
|
wth->pseudo_header.atm.type == TRAF_LANE) {
|
|
|
|
atm_guess_lane_type(buffer_start_ptr(wth->frame_buffer),
|
|
|
|
wth->phdr.caplen, &wth->pseudo_header);
|
|
|
|
}
|
|
|
|
|
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;
|
2001-10-25 20:29:24 +00:00
|
|
|
if ((unsigned)bytes_to_read > sizeof padbuf)
|
1999-09-02 00:14:06 +00:00
|
|
|
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;
|
2000-09-07 05:34:23 +00:00
|
|
|
return FALSE;
|
1999-09-02 00:14:06 +00:00
|
|
|
}
|
|
|
|
wth->data_offset += bytes_read;
|
|
|
|
padbytes -= bytes_read;
|
|
|
|
}
|
1998-11-15 05:29:17 +00:00
|
|
|
|
2000-09-07 05:34:23 +00:00
|
|
|
return TRUE;
|
1998-11-15 05:29:17 +00:00
|
|
|
}
|
1999-12-04 03:36:22 +00:00
|
|
|
|
2002-03-05 08:40:27 +00:00
|
|
|
static gboolean
|
2001-10-04 08:30:36 +00:00
|
|
|
snoop_seek_read(wtap *wth, long seek_off,
|
2002-03-05 05:58:41 +00:00
|
|
|
union wtap_pseudo_header *pseudo_header, u_char *pd, int length, int *err)
|
2000-05-18 09:09:50 +00:00
|
|
|
{
|
2002-06-07 07:27:35 +00:00
|
|
|
if (file_seek(wth->random_fh, seek_off, SEEK_SET, err) == -1)
|
2002-03-05 08:40:27 +00:00
|
|
|
return FALSE;
|
2000-05-18 09:09:50 +00:00
|
|
|
|
|
|
|
if (wth->file_encap == WTAP_ENCAP_ATM_SNIFFER) {
|
2002-03-05 08:40:27 +00:00
|
|
|
if (!snoop_read_atm_pseudoheader(wth->random_fh, pseudo_header,
|
|
|
|
err)) {
|
2000-05-18 09:09:50 +00:00
|
|
|
/* Read error */
|
2002-03-05 08:40:27 +00:00
|
|
|
return FALSE;
|
2000-05-18 09:09:50 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Read the packet data.
|
|
|
|
*/
|
2002-05-23 08:17:31 +00:00
|
|
|
if (!snoop_read_rec_data(wth->random_fh, pd, length, err))
|
|
|
|
return FALSE; /* failed */
|
|
|
|
|
|
|
|
/*
|
|
|
|
* If this is ATM LANE traffic, try to guess what type of LANE
|
|
|
|
* traffic it is based on the packet contents.
|
|
|
|
*/
|
|
|
|
if (wth->file_encap == WTAP_ENCAP_ATM_SNIFFER &&
|
|
|
|
pseudo_header->atm.type == TRAF_LANE)
|
|
|
|
atm_guess_lane_type(pd, length, pseudo_header);
|
|
|
|
return TRUE;
|
2000-05-18 09:09:50 +00:00
|
|
|
}
|
|
|
|
|
2002-03-05 08:40:27 +00:00
|
|
|
static gboolean
|
2000-05-19 23:07:04 +00:00
|
|
|
snoop_read_atm_pseudoheader(FILE_T fh, union wtap_pseudo_header *pseudo_header,
|
2000-05-18 09:09:50 +00:00
|
|
|
int *err)
|
|
|
|
{
|
2002-04-30 09:23:29 +00:00
|
|
|
struct snoop_atm_hdr atm_phdr;
|
2000-05-18 09:09:50 +00:00
|
|
|
int bytes_read;
|
Replace the "ngsniffer_atm" with an "atm" pseudo-header, which isn't
just an image of the ATM Sniffer data. This means that Ethereal doesn't
have to know any ATM Sniffer-specific details (that's all hidden in
Wiretap), and allows us to add to that pseudo-header fields, traffic
types, etc. unknown to ATM Sniffers.
Have Wiretap map VPI 0/VCI 5 to the signalling AAL - for some capture
files, this might not be necessary, as they may mark all signalling
traffic as such, but, on other platforms, we don't know the AAL, so we
assume AAL5 except for 0/5 traffic. Doing it in Wiretap lets us hide
those details from Ethereal (and lets Ethereal interpret 0/5 traffic as
non-signalling traffic, in case that happens to be what it is).
We may know that traffic is LANE, but not whether it's LE Control or
emulated 802.3/802.5; handle that case.
svn path=/trunk/; revision=5302
2002-04-30 08:48:27 +00:00
|
|
|
guint8 vpi;
|
|
|
|
guint16 vci;
|
2000-05-18 09:09:50 +00:00
|
|
|
|
|
|
|
errno = WTAP_ERR_CANT_READ;
|
2002-04-30 09:23:29 +00:00
|
|
|
bytes_read = file_read(&atm_phdr, 1, sizeof (struct snoop_atm_hdr), fh);
|
|
|
|
if (bytes_read != sizeof (struct snoop_atm_hdr)) {
|
2000-05-18 09:09:50 +00:00
|
|
|
*err = file_error(fh);
|
|
|
|
if (*err == 0)
|
|
|
|
*err = WTAP_ERR_SHORT_READ;
|
2002-03-05 08:40:27 +00:00
|
|
|
return FALSE;
|
2000-05-18 09:09:50 +00:00
|
|
|
}
|
|
|
|
|
2002-04-30 09:23:29 +00:00
|
|
|
vpi = atm_phdr.vpi;
|
|
|
|
vci = pntohs(&atm_phdr.vci);
|
2000-05-18 09:09:50 +00:00
|
|
|
|
|
|
|
/*
|
2002-04-30 06:04:33 +00:00
|
|
|
* The lower 4 bits of the first byte of the header indicate
|
|
|
|
* the type of traffic, as per the "atmioctl.h" header in
|
|
|
|
* SunATM.
|
2000-05-18 09:09:50 +00:00
|
|
|
*/
|
2002-04-30 09:23:29 +00:00
|
|
|
switch (atm_phdr.flags & 0x0F) {
|
2002-04-30 06:04:33 +00:00
|
|
|
|
|
|
|
case 0x01: /* LANE */
|
Replace the "ngsniffer_atm" with an "atm" pseudo-header, which isn't
just an image of the ATM Sniffer data. This means that Ethereal doesn't
have to know any ATM Sniffer-specific details (that's all hidden in
Wiretap), and allows us to add to that pseudo-header fields, traffic
types, etc. unknown to ATM Sniffers.
Have Wiretap map VPI 0/VCI 5 to the signalling AAL - for some capture
files, this might not be necessary, as they may mark all signalling
traffic as such, but, on other platforms, we don't know the AAL, so we
assume AAL5 except for 0/5 traffic. Doing it in Wiretap lets us hide
those details from Ethereal (and lets Ethereal interpret 0/5 traffic as
non-signalling traffic, in case that happens to be what it is).
We may know that traffic is LANE, but not whether it's LE Control or
emulated 802.3/802.5; handle that case.
svn path=/trunk/; revision=5302
2002-04-30 08:48:27 +00:00
|
|
|
pseudo_header->atm.aal = AAL_5;
|
|
|
|
pseudo_header->atm.type = TRAF_LANE;
|
2002-04-30 06:04:33 +00:00
|
|
|
break;
|
|
|
|
|
|
|
|
case 0x02: /* RFC 1483 LLC multiplexed traffic */
|
Replace the "ngsniffer_atm" with an "atm" pseudo-header, which isn't
just an image of the ATM Sniffer data. This means that Ethereal doesn't
have to know any ATM Sniffer-specific details (that's all hidden in
Wiretap), and allows us to add to that pseudo-header fields, traffic
types, etc. unknown to ATM Sniffers.
Have Wiretap map VPI 0/VCI 5 to the signalling AAL - for some capture
files, this might not be necessary, as they may mark all signalling
traffic as such, but, on other platforms, we don't know the AAL, so we
assume AAL5 except for 0/5 traffic. Doing it in Wiretap lets us hide
those details from Ethereal (and lets Ethereal interpret 0/5 traffic as
non-signalling traffic, in case that happens to be what it is).
We may know that traffic is LANE, but not whether it's LE Control or
emulated 802.3/802.5; handle that case.
svn path=/trunk/; revision=5302
2002-04-30 08:48:27 +00:00
|
|
|
pseudo_header->atm.aal = AAL_5;
|
|
|
|
pseudo_header->atm.type = TRAF_LLCMX;
|
2002-04-30 06:04:33 +00:00
|
|
|
break;
|
|
|
|
|
|
|
|
case 0x05: /* ILMI */
|
Replace the "ngsniffer_atm" with an "atm" pseudo-header, which isn't
just an image of the ATM Sniffer data. This means that Ethereal doesn't
have to know any ATM Sniffer-specific details (that's all hidden in
Wiretap), and allows us to add to that pseudo-header fields, traffic
types, etc. unknown to ATM Sniffers.
Have Wiretap map VPI 0/VCI 5 to the signalling AAL - for some capture
files, this might not be necessary, as they may mark all signalling
traffic as such, but, on other platforms, we don't know the AAL, so we
assume AAL5 except for 0/5 traffic. Doing it in Wiretap lets us hide
those details from Ethereal (and lets Ethereal interpret 0/5 traffic as
non-signalling traffic, in case that happens to be what it is).
We may know that traffic is LANE, but not whether it's LE Control or
emulated 802.3/802.5; handle that case.
svn path=/trunk/; revision=5302
2002-04-30 08:48:27 +00:00
|
|
|
pseudo_header->atm.aal = AAL_5;
|
|
|
|
pseudo_header->atm.type = TRAF_ILMI;
|
2002-04-30 06:04:33 +00:00
|
|
|
break;
|
|
|
|
|
2002-05-07 06:25:30 +00:00
|
|
|
case 0x06: /* Signalling AAL */
|
Replace the "ngsniffer_atm" with an "atm" pseudo-header, which isn't
just an image of the ATM Sniffer data. This means that Ethereal doesn't
have to know any ATM Sniffer-specific details (that's all hidden in
Wiretap), and allows us to add to that pseudo-header fields, traffic
types, etc. unknown to ATM Sniffers.
Have Wiretap map VPI 0/VCI 5 to the signalling AAL - for some capture
files, this might not be necessary, as they may mark all signalling
traffic as such, but, on other platforms, we don't know the AAL, so we
assume AAL5 except for 0/5 traffic. Doing it in Wiretap lets us hide
those details from Ethereal (and lets Ethereal interpret 0/5 traffic as
non-signalling traffic, in case that happens to be what it is).
We may know that traffic is LANE, but not whether it's LE Control or
emulated 802.3/802.5; handle that case.
svn path=/trunk/; revision=5302
2002-04-30 08:48:27 +00:00
|
|
|
pseudo_header->atm.aal = AAL_SIGNALLING;
|
|
|
|
pseudo_header->atm.type = TRAF_UNKNOWN;
|
2002-04-30 06:04:33 +00:00
|
|
|
break;
|
|
|
|
|
|
|
|
case 0x03: /* MARS (RFC 2022) */
|
Replace the "ngsniffer_atm" with an "atm" pseudo-header, which isn't
just an image of the ATM Sniffer data. This means that Ethereal doesn't
have to know any ATM Sniffer-specific details (that's all hidden in
Wiretap), and allows us to add to that pseudo-header fields, traffic
types, etc. unknown to ATM Sniffers.
Have Wiretap map VPI 0/VCI 5 to the signalling AAL - for some capture
files, this might not be necessary, as they may mark all signalling
traffic as such, but, on other platforms, we don't know the AAL, so we
assume AAL5 except for 0/5 traffic. Doing it in Wiretap lets us hide
those details from Ethereal (and lets Ethereal interpret 0/5 traffic as
non-signalling traffic, in case that happens to be what it is).
We may know that traffic is LANE, but not whether it's LE Control or
emulated 802.3/802.5; handle that case.
svn path=/trunk/; revision=5302
2002-04-30 08:48:27 +00:00
|
|
|
pseudo_header->atm.aal = AAL_5;
|
2002-04-30 09:23:29 +00:00
|
|
|
pseudo_header->atm.type = TRAF_UNKNOWN;
|
Replace the "ngsniffer_atm" with an "atm" pseudo-header, which isn't
just an image of the ATM Sniffer data. This means that Ethereal doesn't
have to know any ATM Sniffer-specific details (that's all hidden in
Wiretap), and allows us to add to that pseudo-header fields, traffic
types, etc. unknown to ATM Sniffers.
Have Wiretap map VPI 0/VCI 5 to the signalling AAL - for some capture
files, this might not be necessary, as they may mark all signalling
traffic as such, but, on other platforms, we don't know the AAL, so we
assume AAL5 except for 0/5 traffic. Doing it in Wiretap lets us hide
those details from Ethereal (and lets Ethereal interpret 0/5 traffic as
non-signalling traffic, in case that happens to be what it is).
We may know that traffic is LANE, but not whether it's LE Control or
emulated 802.3/802.5; handle that case.
svn path=/trunk/; revision=5302
2002-04-30 08:48:27 +00:00
|
|
|
break;
|
|
|
|
|
2002-04-30 06:04:33 +00:00
|
|
|
case 0x04: /* IFMP (Ipsilon Flow Management Protocol; see RFC 1954) */
|
Replace the "ngsniffer_atm" with an "atm" pseudo-header, which isn't
just an image of the ATM Sniffer data. This means that Ethereal doesn't
have to know any ATM Sniffer-specific details (that's all hidden in
Wiretap), and allows us to add to that pseudo-header fields, traffic
types, etc. unknown to ATM Sniffers.
Have Wiretap map VPI 0/VCI 5 to the signalling AAL - for some capture
files, this might not be necessary, as they may mark all signalling
traffic as such, but, on other platforms, we don't know the AAL, so we
assume AAL5 except for 0/5 traffic. Doing it in Wiretap lets us hide
those details from Ethereal (and lets Ethereal interpret 0/5 traffic as
non-signalling traffic, in case that happens to be what it is).
We may know that traffic is LANE, but not whether it's LE Control or
emulated 802.3/802.5; handle that case.
svn path=/trunk/; revision=5302
2002-04-30 08:48:27 +00:00
|
|
|
pseudo_header->atm.aal = AAL_5;
|
|
|
|
pseudo_header->atm.type = TRAF_UNKNOWN; /* XXX - TRAF_IPSILON? */
|
|
|
|
break;
|
|
|
|
|
2002-04-30 06:04:33 +00:00
|
|
|
default:
|
|
|
|
/*
|
Replace the "ngsniffer_atm" with an "atm" pseudo-header, which isn't
just an image of the ATM Sniffer data. This means that Ethereal doesn't
have to know any ATM Sniffer-specific details (that's all hidden in
Wiretap), and allows us to add to that pseudo-header fields, traffic
types, etc. unknown to ATM Sniffers.
Have Wiretap map VPI 0/VCI 5 to the signalling AAL - for some capture
files, this might not be necessary, as they may mark all signalling
traffic as such, but, on other platforms, we don't know the AAL, so we
assume AAL5 except for 0/5 traffic. Doing it in Wiretap lets us hide
those details from Ethereal (and lets Ethereal interpret 0/5 traffic as
non-signalling traffic, in case that happens to be what it is).
We may know that traffic is LANE, but not whether it's LE Control or
emulated 802.3/802.5; handle that case.
svn path=/trunk/; revision=5302
2002-04-30 08:48:27 +00:00
|
|
|
* Assume it's AAL5, unless it's VPI 0 and VCI 5, in which
|
|
|
|
* case assume it's AAL_SIGNALLING; we know nothing more
|
|
|
|
* about it.
|
|
|
|
*
|
|
|
|
* XXX - is this necessary? Or are we guaranteed that
|
|
|
|
* all signalling traffic has a type of 0x06?
|
|
|
|
*
|
|
|
|
* XXX - is this guaranteed to be AAL5? Or, if the type is
|
|
|
|
* 0x00 ("raw"), might it be non-AAL5 traffic?
|
2002-04-30 06:04:33 +00:00
|
|
|
*/
|
Replace the "ngsniffer_atm" with an "atm" pseudo-header, which isn't
just an image of the ATM Sniffer data. This means that Ethereal doesn't
have to know any ATM Sniffer-specific details (that's all hidden in
Wiretap), and allows us to add to that pseudo-header fields, traffic
types, etc. unknown to ATM Sniffers.
Have Wiretap map VPI 0/VCI 5 to the signalling AAL - for some capture
files, this might not be necessary, as they may mark all signalling
traffic as such, but, on other platforms, we don't know the AAL, so we
assume AAL5 except for 0/5 traffic. Doing it in Wiretap lets us hide
those details from Ethereal (and lets Ethereal interpret 0/5 traffic as
non-signalling traffic, in case that happens to be what it is).
We may know that traffic is LANE, but not whether it's LE Control or
emulated 802.3/802.5; handle that case.
svn path=/trunk/; revision=5302
2002-04-30 08:48:27 +00:00
|
|
|
if (vpi == 0 && vci == 5)
|
|
|
|
pseudo_header->atm.aal = AAL_SIGNALLING;
|
|
|
|
else
|
|
|
|
pseudo_header->atm.aal = AAL_5;
|
|
|
|
pseudo_header->atm.type = TRAF_UNKNOWN;
|
2002-04-30 06:04:33 +00:00
|
|
|
break;
|
|
|
|
}
|
Replace the "ngsniffer_atm" with an "atm" pseudo-header, which isn't
just an image of the ATM Sniffer data. This means that Ethereal doesn't
have to know any ATM Sniffer-specific details (that's all hidden in
Wiretap), and allows us to add to that pseudo-header fields, traffic
types, etc. unknown to ATM Sniffers.
Have Wiretap map VPI 0/VCI 5 to the signalling AAL - for some capture
files, this might not be necessary, as they may mark all signalling
traffic as such, but, on other platforms, we don't know the AAL, so we
assume AAL5 except for 0/5 traffic. Doing it in Wiretap lets us hide
those details from Ethereal (and lets Ethereal interpret 0/5 traffic as
non-signalling traffic, in case that happens to be what it is).
We may know that traffic is LANE, but not whether it's LE Control or
emulated 802.3/802.5; handle that case.
svn path=/trunk/; revision=5302
2002-04-30 08:48:27 +00:00
|
|
|
pseudo_header->atm.subtype = TRAF_ST_UNKNOWN;
|
|
|
|
|
|
|
|
pseudo_header->atm.vpi = vpi;
|
|
|
|
pseudo_header->atm.vci = vci;
|
2002-04-30 09:23:29 +00:00
|
|
|
pseudo_header->atm.channel = (atm_phdr.flags & 0x80) ? 1 : 0;
|
Replace the "ngsniffer_atm" with an "atm" pseudo-header, which isn't
just an image of the ATM Sniffer data. This means that Ethereal doesn't
have to know any ATM Sniffer-specific details (that's all hidden in
Wiretap), and allows us to add to that pseudo-header fields, traffic
types, etc. unknown to ATM Sniffers.
Have Wiretap map VPI 0/VCI 5 to the signalling AAL - for some capture
files, this might not be necessary, as they may mark all signalling
traffic as such, but, on other platforms, we don't know the AAL, so we
assume AAL5 except for 0/5 traffic. Doing it in Wiretap lets us hide
those details from Ethereal (and lets Ethereal interpret 0/5 traffic as
non-signalling traffic, in case that happens to be what it is).
We may know that traffic is LANE, but not whether it's LE Control or
emulated 802.3/802.5; handle that case.
svn path=/trunk/; revision=5302
2002-04-30 08:48:27 +00:00
|
|
|
|
|
|
|
/* We don't have this information */
|
|
|
|
pseudo_header->atm.cells = 0;
|
|
|
|
pseudo_header->atm.aal5t_u2u = 0;
|
|
|
|
pseudo_header->atm.aal5t_len = 0;
|
|
|
|
pseudo_header->atm.aal5t_chksum = 0;
|
2000-05-18 09:09:50 +00:00
|
|
|
|
2002-03-05 08:40:27 +00:00
|
|
|
return TRUE;
|
2000-05-18 09:09:50 +00:00
|
|
|
}
|
|
|
|
|
2002-03-05 08:40:27 +00:00
|
|
|
static gboolean
|
2000-07-26 00:20:09 +00:00
|
|
|
snoop_read_rec_data(FILE_T fh, u_char *pd, int length, int *err)
|
2000-05-18 09:09:50 +00:00
|
|
|
{
|
|
|
|
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;
|
2002-03-05 08:40:27 +00:00
|
|
|
return FALSE;
|
2000-05-18 09:09:50 +00:00
|
|
|
}
|
2002-03-05 08:40:27 +00:00
|
|
|
return TRUE;
|
2000-05-18 09:09:50 +00:00
|
|
|
}
|
|
|
|
|
1999-12-04 08:32:14 +00:00
|
|
|
static const int wtap_encap[] = {
|
|
|
|
-1, /* WTAP_ENCAP_UNKNOWN -> unsupported */
|
|
|
|
0x04, /* WTAP_ENCAP_ETHERNET -> DL_ETHER */
|
2000-09-21 04:41:37 +00:00
|
|
|
0x02, /* WTAP_ENCAP_TOKEN_RING -> DL_TPR */
|
1999-12-04 08:32:14 +00:00
|
|
|
-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*/
|
2002-04-30 09:23:29 +00:00
|
|
|
0x12, /* WTAP_ENCAP_ATM_SNIFFER -> DL_IPATM */
|
|
|
|
-1 /* WTAP_ENCAP_NULL -> unsupported */
|
1999-12-04 08:32:14 +00:00
|
|
|
};
|
|
|
|
#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. */
|
2002-02-27 08:57:25 +00:00
|
|
|
int snoop_dump_can_write_encap(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;
|
|
|
|
|
2001-10-25 20:29:24 +00:00
|
|
|
if (encap < 0 || (unsigned)encap >= NUM_WTAP_ENCAPS || wtap_encap[encap] == -1)
|
1999-12-04 08:32:14 +00:00
|
|
|
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 */
|
2002-07-16 07:15:09 +00:00
|
|
|
gboolean snoop_dump_open(wtap_dumper *wdh, gboolean cant_seek _U_, int *err)
|
1999-12-04 03:36:22 +00:00
|
|
|
{
|
|
|
|
struct snoop_hdr file_hdr;
|
2001-08-25 03:18:48 +00:00
|
|
|
size_t nwritten;
|
1999-12-04 03:36:22 +00:00
|
|
|
|
|
|
|
/* 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) {
|
2001-08-25 03:18:48 +00:00
|
|
|
if (nwritten == 0 && ferror(wdh->fh))
|
1999-12-04 03:36:22 +00:00
|
|
|
*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) {
|
2001-08-25 03:18:48 +00:00
|
|
|
if (nwritten == 0 && ferror(wdh->fh))
|
1999-12-04 03:36:22 +00:00
|
|
|
*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. */
|
2002-03-02 20:41:08 +00:00
|
|
|
static gboolean snoop_dump(wtap_dumper *wdh,
|
|
|
|
const struct wtap_pkthdr *phdr,
|
|
|
|
const union wtap_pseudo_header *pseudo_header _U_,
|
|
|
|
const u_char *pd, int *err)
|
1999-12-04 03:36:22 +00:00
|
|
|
{
|
|
|
|
struct snooprec_hdr rec_hdr;
|
Sigh. Shomiti apparently didn't know that the RFC 1761 data link types
were just DLPI data link types, and didn't know that the list had
expanded at some point and that Sun *used* some of the new types (e.g.,
in atmsnoop), or decided on their own to go beyond those types to encode
an Oh-So-Useful link speed indication, or just didn't *care* that they
were just DLPI data link types.
Therefore, we have to map Shomiti link types to wiretap types using a
different mapping table. For now, we assume files with a version number
of 2 are snoop files, and version numbers of 3, 4, and 5 are Shomiti
files; Shomiti claims to use a version number of 2 as well, but to
determine whether a file with a version number of 2 is a snoop file or a
Shomiti file requires that we look at the header of the first packet and
assume that if there's more than 3 bytes of padding it's a Shomiti file.
The return value from "fwrite()" is a "size_t"; make the variable into
which we store it a "size_t", and then fix up the bugs that were
revealed by the compiler warnings that produced - "fwrite()" returns 0,
not a negative number, on an I/O error.
svn path=/trunk/; revision=3866
2001-08-25 02:56:31 +00:00
|
|
|
size_t nwritten;
|
1999-12-04 03:36:22 +00:00
|
|
|
int reclen;
|
2001-10-25 20:29:24 +00:00
|
|
|
guint padlen;
|
1999-12-04 03:36:22 +00:00
|
|
|
static char zeroes[4];
|
2002-04-30 09:23:29 +00:00
|
|
|
struct snoop_atm_hdr atm_hdr;
|
|
|
|
int atm_hdrsize;
|
|
|
|
|
|
|
|
if (wdh->encap == WTAP_ENCAP_ATM_SNIFFER)
|
|
|
|
atm_hdrsize = sizeof (struct snoop_atm_hdr);
|
|
|
|
else
|
|
|
|
atm_hdrsize = 0;
|
1999-12-04 03:36:22 +00:00
|
|
|
|
|
|
|
/* Record length = header length plus data length... */
|
2002-04-30 09:23:29 +00:00
|
|
|
reclen = sizeof rec_hdr + phdr->caplen + atm_hdrsize;
|
1999-12-04 03:36:22 +00:00
|
|
|
|
|
|
|
/* ... plus enough bytes to pad it to a 4-byte boundary. */
|
|
|
|
padlen = ((reclen + 3) & ~3) - reclen;
|
|
|
|
reclen += padlen;
|
|
|
|
|
2002-04-30 09:23:29 +00:00
|
|
|
rec_hdr.orig_len = htonl(phdr->len + atm_hdrsize);
|
|
|
|
rec_hdr.incl_len = htonl(phdr->caplen + atm_hdrsize);
|
1999-12-04 03:36:22 +00:00
|
|
|
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) {
|
Sigh. Shomiti apparently didn't know that the RFC 1761 data link types
were just DLPI data link types, and didn't know that the list had
expanded at some point and that Sun *used* some of the new types (e.g.,
in atmsnoop), or decided on their own to go beyond those types to encode
an Oh-So-Useful link speed indication, or just didn't *care* that they
were just DLPI data link types.
Therefore, we have to map Shomiti link types to wiretap types using a
different mapping table. For now, we assume files with a version number
of 2 are snoop files, and version numbers of 3, 4, and 5 are Shomiti
files; Shomiti claims to use a version number of 2 as well, but to
determine whether a file with a version number of 2 is a snoop file or a
Shomiti file requires that we look at the header of the first packet and
assume that if there's more than 3 bytes of padding it's a Shomiti file.
The return value from "fwrite()" is a "size_t"; make the variable into
which we store it a "size_t", and then fix up the bugs that were
revealed by the compiler warnings that produced - "fwrite()" returns 0,
not a negative number, on an I/O error.
svn path=/trunk/; revision=3866
2001-08-25 02:56:31 +00:00
|
|
|
if (nwritten == 0 && ferror(wdh->fh))
|
1999-12-04 03:36:22 +00:00
|
|
|
*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
|
|
|
}
|
2002-04-30 09:23:29 +00:00
|
|
|
|
|
|
|
if (wdh->encap == WTAP_ENCAP_ATM_SNIFFER) {
|
|
|
|
/*
|
|
|
|
* Write the ATM header.
|
|
|
|
*/
|
|
|
|
atm_hdr.flags =
|
|
|
|
(pseudo_header->atm.channel != 0) ? 0x80 : 0x00;
|
|
|
|
switch (pseudo_header->atm.aal) {
|
|
|
|
|
|
|
|
case AAL_SIGNALLING:
|
2002-05-07 06:25:30 +00:00
|
|
|
/* Signalling AAL */
|
2002-04-30 09:23:29 +00:00
|
|
|
atm_hdr.flags |= 0x06;
|
|
|
|
break;
|
|
|
|
|
|
|
|
case AAL_5:
|
|
|
|
switch (pseudo_header->atm.type) {
|
|
|
|
|
|
|
|
case TRAF_LANE:
|
|
|
|
/* LANE */
|
|
|
|
atm_hdr.flags |= 0x01;
|
|
|
|
break;
|
|
|
|
|
|
|
|
case TRAF_LLCMX:
|
|
|
|
/* RFC 1483 LLC multiplexed traffic */
|
|
|
|
atm_hdr.flags |= 0x02;
|
|
|
|
break;
|
|
|
|
|
|
|
|
case TRAF_ILMI:
|
|
|
|
/* ILMI */
|
|
|
|
atm_hdr.flags |= 0x05;
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
atm_hdr.vpi = pseudo_header->atm.vpi;
|
|
|
|
atm_hdr.vci = htons(pseudo_header->atm.vci);
|
|
|
|
nwritten = fwrite(&atm_hdr, 1, sizeof atm_hdr, wdh->fh);
|
|
|
|
if (nwritten != sizeof atm_hdr) {
|
|
|
|
if (nwritten == 0 && ferror(wdh->fh))
|
|
|
|
*err = errno;
|
|
|
|
else
|
|
|
|
*err = WTAP_ERR_SHORT_WRITE;
|
|
|
|
return FALSE;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
1999-12-04 03:36:22 +00:00
|
|
|
nwritten = fwrite(pd, 1, phdr->caplen, wdh->fh);
|
|
|
|
if (nwritten != phdr->caplen) {
|
Sigh. Shomiti apparently didn't know that the RFC 1761 data link types
were just DLPI data link types, and didn't know that the list had
expanded at some point and that Sun *used* some of the new types (e.g.,
in atmsnoop), or decided on their own to go beyond those types to encode
an Oh-So-Useful link speed indication, or just didn't *care* that they
were just DLPI data link types.
Therefore, we have to map Shomiti link types to wiretap types using a
different mapping table. For now, we assume files with a version number
of 2 are snoop files, and version numbers of 3, 4, and 5 are Shomiti
files; Shomiti claims to use a version number of 2 as well, but to
determine whether a file with a version number of 2 is a snoop file or a
Shomiti file requires that we look at the header of the first packet and
assume that if there's more than 3 bytes of padding it's a Shomiti file.
The return value from "fwrite()" is a "size_t"; make the variable into
which we store it a "size_t", and then fix up the bugs that were
revealed by the compiler warnings that produced - "fwrite()" returns 0,
not a negative number, on an I/O error.
svn path=/trunk/; revision=3866
2001-08-25 02:56:31 +00:00
|
|
|
if (nwritten == 0 && ferror(wdh->fh))
|
1999-12-04 03:36:22 +00:00
|
|
|
*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) {
|
Sigh. Shomiti apparently didn't know that the RFC 1761 data link types
were just DLPI data link types, and didn't know that the list had
expanded at some point and that Sun *used* some of the new types (e.g.,
in atmsnoop), or decided on their own to go beyond those types to encode
an Oh-So-Useful link speed indication, or just didn't *care* that they
were just DLPI data link types.
Therefore, we have to map Shomiti link types to wiretap types using a
different mapping table. For now, we assume files with a version number
of 2 are snoop files, and version numbers of 3, 4, and 5 are Shomiti
files; Shomiti claims to use a version number of 2 as well, but to
determine whether a file with a version number of 2 is a snoop file or a
Shomiti file requires that we look at the header of the first packet and
assume that if there's more than 3 bytes of padding it's a Shomiti file.
The return value from "fwrite()" is a "size_t"; make the variable into
which we store it a "size_t", and then fix up the bugs that were
revealed by the compiler warnings that produced - "fwrite()" returns 0,
not a negative number, on an I/O error.
svn path=/trunk/; revision=3866
2001-08-25 02:56:31 +00:00
|
|
|
if (nwritten == 0 && ferror(wdh->fh))
|
1999-12-04 03:36:22 +00:00
|
|
|
*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
|
|
|
}
|