1998-11-15 05:29:17 +00:00
|
|
|
/* snoop.c
|
|
|
|
*
|
2004-07-18 00:24:25 +00:00
|
|
|
* $Id$
|
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>
|
2002-08-28 20:30:45 +00:00
|
|
|
*
|
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.
|
2002-08-28 20:30:45 +00:00
|
|
|
*
|
1998-11-15 05:29:17 +00:00
|
|
|
* 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.
|
2002-08-28 20:30:45 +00:00
|
|
|
*
|
1998-11-15 05:29:17 +00:00
|
|
|
* 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"
|
|
|
|
/* 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 */
|
|
|
|
};
|
|
|
|
|
2003-11-04 22:14:50 +00:00
|
|
|
/*
|
|
|
|
* Extra information stuffed into the padding in Shomiti/Finisar Surveyor
|
|
|
|
* captures.
|
|
|
|
*/
|
|
|
|
struct shomiti_trailer {
|
|
|
|
guint16 phy_rx_length; /* length on the wire, including FCS? */
|
|
|
|
guint16 phy_rx_status; /* status flags */
|
|
|
|
guint32 ts_40_ns_lsb; /* 40 ns time stamp, low-order bytes? */
|
|
|
|
guint32 ts_40_ns_msb; /* 40 ns time stamp, low-order bytes? */
|
|
|
|
gint32 frame_id; /* "FrameID"? */
|
|
|
|
};
|
|
|
|
|
|
|
|
/*
|
|
|
|
* phy_rx_status flags.
|
|
|
|
*/
|
|
|
|
#define RX_STATUS_OVERFLOW 0x8000 /* overflow error */
|
|
|
|
#define RX_STATUS_BAD_CRC 0x4000 /* CRC error */
|
|
|
|
#define RX_STATUS_DRIBBLE_NIBBLE 0x2000 /* dribble/nibble bits? */
|
|
|
|
#define RX_STATUS_SHORT_FRAME 0x1000 /* frame < 64 bytes */
|
|
|
|
#define RX_STATUS_OVERSIZE_FRAME 0x0800 /* frame > 1518 bytes */
|
|
|
|
#define RX_STATUS_GOOD_FRAME 0x0400 /* frame OK */
|
|
|
|
#define RX_STATUS_N12_BYTES_RECEIVED 0x0200 /* first 12 bytes of frame received? */
|
|
|
|
#define RX_STATUS_RXABORT 0x0100 /* RXABORT during reception */
|
|
|
|
#define RX_STATUS_FIFO_ERROR 0x0080 /* receive FIFO error */
|
|
|
|
#define RX_STATUS_TRIGGERED 0x0001 /* frame did trigger */
|
|
|
|
|
Have the Wiretap open, read, and seek-and-read routines return, in
addition to an error code, an error info string, for
WTAP_ERR_UNSUPPORTED, WTAP_ERR_UNSUPPORTED_ENCAP, and
WTAP_ERR_BAD_RECORD errors. Replace the error messages logged with
"g_message()" for those errors with g_strdup()ed or g_strdup_printf()ed
strings returned as the error info string, and change the callers of
those routines to, for those errors, put the info string into the
printed message or alert box for the error.
Add messages for cases where those errors were returned without printing
an additional message.
Nobody uses the error code from "cf_read()" - "cf_read()" puts up the
alert box itself for failures; get rid of the error code, so it just
returns a success/failure indication.
Rename "file_read_error_message()" to "cf_read_error_message()", as it
handles read errors from Wiretap, and have it take an error info string
as an argument. (That handles a lot of the work of putting the info
string into the error message.)
Make some variables in "ascend-grammar.y" static.
Check the return value of "erf_read_header()" in "erf_seek_read()".
Get rid of an unused #define in "i4btrace.c".
svn path=/trunk/; revision=9852
2004-01-25 21:55:17 +00:00
|
|
|
static gboolean snoop_read(wtap *wth, int *err, gchar **err_info,
|
2006-11-05 22:46:44 +00:00
|
|
|
gint64 *data_offset);
|
|
|
|
static gboolean snoop_seek_read(wtap *wth, gint64 seek_off,
|
Have the Wiretap open, read, and seek-and-read routines return, in
addition to an error code, an error info string, for
WTAP_ERR_UNSUPPORTED, WTAP_ERR_UNSUPPORTED_ENCAP, and
WTAP_ERR_BAD_RECORD errors. Replace the error messages logged with
"g_message()" for those errors with g_strdup()ed or g_strdup_printf()ed
strings returned as the error info string, and change the callers of
those routines to, for those errors, put the info string into the
printed message or alert box for the error.
Add messages for cases where those errors were returned without printing
an additional message.
Nobody uses the error code from "cf_read()" - "cf_read()" puts up the
alert box itself for failures; get rid of the error code, so it just
returns a success/failure indication.
Rename "file_read_error_message()" to "cf_read_error_message()", as it
handles read errors from Wiretap, and have it take an error info string
as an argument. (That handles a lot of the work of putting the info
string into the error message.)
Make some variables in "ascend-grammar.y" static.
Check the return value of "erf_read_header()" in "erf_seek_read()".
Get rid of an unused #define in "i4btrace.c".
svn path=/trunk/; revision=9852
2004-01-25 21:55:17 +00:00
|
|
|
union wtap_pseudo_header *pseudo_header, guchar *pd, int length,
|
|
|
|
int *err, gchar **err_info);
|
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);
|
2007-01-18 12:19:17 +00:00
|
|
|
static gboolean snoop_read_shomiti_wireless_pseudoheader(FILE_T fh,
|
2009-09-17 02:59:26 +00:00
|
|
|
union wtap_pseudo_header *pseudo_header, int *err, gchar **err_info,
|
|
|
|
int *header_size);
|
2002-07-29 06:09:59 +00:00
|
|
|
static gboolean snoop_read_rec_data(FILE_T fh, guchar *pd, int length,
|
2002-03-05 08:40:27 +00:00
|
|
|
int *err);
|
1999-12-04 05:14:39 +00:00
|
|
|
static gboolean snoop_dump(wtap_dumper *wdh, const struct wtap_pkthdr *phdr,
|
2002-07-29 06:09:59 +00:00
|
|
|
const union wtap_pseudo_header *pseudo_header, const guchar *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
|
2002-08-28 20:30:45 +00:00
|
|
|
*
|
1999-11-26 11:18:12 +00:00
|
|
|
* 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
|
|
|
*
|
2002-09-04 19:29:59 +00:00
|
|
|
* had links to modified versions of "tcpdump" and "libpcap" for SUNatm
|
|
|
|
* DLPI support; they suggested that the 3.0 verson of SUNatm uses those
|
|
|
|
* values. The Wayback Machine archived that page, but not the stuff
|
|
|
|
* to which it linked, unfortunately.
|
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
|
2002-09-04 19:29:59 +00:00
|
|
|
* also includes "atmdump", which is a modified "tcpdump", is available
|
|
|
|
* at
|
|
|
|
*
|
|
|
|
* ftp://ftp.cs.ndsu.nodak.edu/pub/freebsd/atm/atm-bpf.tgz
|
|
|
|
*
|
|
|
|
* and that code also indicates that DL_IPATM is used, and that an
|
1999-11-27 06:03:46 +00:00
|
|
|
* 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,
|
2002-09-04 19:29:59 +00:00
|
|
|
* and then the ATM PDU, and suggests that the direction flag is 0x80 for
|
1999-11-27 06:03:46 +00:00
|
|
|
* "transmitted" (presumably meaning DTE->DCE) and presumably not 0x80 for
|
2002-09-04 19:29:59 +00:00
|
|
|
* "received" (presumably meaning DCE->DTE). That code was used as the
|
|
|
|
* basis for the SunATM support in current CVS versions of libpcap and
|
|
|
|
* tcpdump, and it works.
|
1999-11-27 06:03:46 +00:00
|
|
|
*
|
|
|
|
* 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
|
2002-09-04 19:29:59 +00:00
|
|
|
* direction. That appears to be the case.
|
1999-11-27 06:03:46 +00:00
|
|
|
*
|
|
|
|
* I don't know what the encapsulation of any of the other types is, so I
|
2002-12-05 22:33:11 +00:00
|
|
|
* leave them all as WTAP_ENCAP_UNKNOWN, except for those for which Brian
|
|
|
|
* Ginsbach has supplied information about the way UNICOS/mp uses them.
|
|
|
|
* 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
|
|
|
|
*
|
2002-09-04 19:29:59 +00:00
|
|
|
* http://web.archive.org/web/20010906213807/http://www.shomiti.com/support/TNCapFileFormat.htm
|
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
|
|
|
*
|
|
|
|
* 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 Wiretap open, read, and seek-and-read routines return, in
addition to an error code, an error info string, for
WTAP_ERR_UNSUPPORTED, WTAP_ERR_UNSUPPORTED_ENCAP, and
WTAP_ERR_BAD_RECORD errors. Replace the error messages logged with
"g_message()" for those errors with g_strdup()ed or g_strdup_printf()ed
strings returned as the error info string, and change the callers of
those routines to, for those errors, put the info string into the
printed message or alert box for the error.
Add messages for cases where those errors were returned without printing
an additional message.
Nobody uses the error code from "cf_read()" - "cf_read()" puts up the
alert box itself for failures; get rid of the error code, so it just
returns a success/failure indication.
Rename "file_read_error_message()" to "cf_read_error_message()", as it
handles read errors from Wiretap, and have it take an error info string
as an argument. (That handles a lot of the work of putting the info
string into the error message.)
Make some variables in "ascend-grammar.y" static.
Check the return value of "erf_read_header()" in "erf_seek_read()".
Get rid of an unused #define in "i4btrace.c".
svn path=/trunk/; revision=9852
2004-01-25 21:55:17 +00:00
|
|
|
int snoop_open(wtap *wth, int *err, gchar **err_info)
|
1998-11-15 05:29:17 +00:00
|
|
|
{
|
|
|
|
int bytes_read;
|
|
|
|
char magic[sizeof snoop_magic];
|
|
|
|
struct snoop_hdr hdr;
|
2002-12-05 22:33:11 +00:00
|
|
|
struct snooprec_hdr rec_hdr;
|
2003-11-04 22:14:50 +00:00
|
|
|
guint padbytes;
|
2002-12-05 22:33:11 +00:00
|
|
|
gboolean is_shomiti;
|
1998-11-15 05:29:17 +00:00
|
|
|
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,
|
2003-11-11 20:49:46 +00:00
|
|
|
WTAP_ENCAP_NULL, /* Other */
|
1999-11-26 11:18:12 +00:00
|
|
|
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 */
|
2003-11-11 20:49:46 +00:00
|
|
|
WTAP_ENCAP_NULL, /* software loopback */
|
1999-11-26 11:18:12 +00:00
|
|
|
WTAP_ENCAP_UNKNOWN, /* not defined in "dlpi.h" */
|
2002-11-13 21:49:58 +00:00
|
|
|
WTAP_ENCAP_IP_OVER_FC, /* Fibre Channel */
|
1999-11-26 11:18:12 +00:00
|
|
|
WTAP_ENCAP_UNKNOWN, /* ATM */
|
Rename WTAP_ENCAP_ATM_SNIFFER to WTAP_ENCAP_ATM_PDUS, as it's not just
used for the DOS-based ATM Sniffer. (That's not a great name, but I
couldn't think of a better one.)
Add a new WTAP_ENCAP_ATM_PDUS_UNTRUNCATED encapsulation type for capture
files where reassembled frames don't have trailers, such as the AAL5
trailer, chopped off. That's what at least some versions of the
Windows-based ATM Sniffer appear to have.
Map the ATM capture file type for NetXRay captures to
WTAP_ENCAP_ATM_PDUS_UNTRUNCATED, and put in stuff to fill in what we've
reverse-engineered, so far, for the pseudo-header; there's more that
needs to be done on it, e.g. getting the channel, AAL type, and traffic
type (or inferring them if they're not in the packet header).
svn path=/trunk/; revision=6840
2003-01-03 06:45:45 +00:00
|
|
|
WTAP_ENCAP_ATM_PDUS, /* 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])
|
2009-12-03 15:27:39 +00:00
|
|
|
#define SNOOP_PRIVATE_BIT 0x80000000
|
|
|
|
static const int snoop_private_encap[] = {
|
|
|
|
WTAP_ENCAP_UNKNOWN, /* Not Used */
|
|
|
|
WTAP_ENCAP_UNKNOWN, /* IPv4 Tunnel Link */
|
|
|
|
WTAP_ENCAP_UNKNOWN, /* IPv6 Tunnel Link */
|
|
|
|
WTAP_ENCAP_UNKNOWN, /* Virtual network interface */
|
|
|
|
WTAP_ENCAP_UNKNOWN, /* IEEE 802.11 */
|
|
|
|
WTAP_ENCAP_IPNET, /* ipnet(7D) link */
|
|
|
|
WTAP_ENCAP_UNKNOWN, /* IPMP stub interface */
|
|
|
|
WTAP_ENCAP_UNKNOWN, /* 6to4 Tunnel Link */
|
|
|
|
};
|
|
|
|
#define NUM_SNOOP_PRIVATE_ENCAPS (sizeof snoop_private_encap / sizeof snoop_private_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" */
|
2007-01-18 12:19:17 +00:00
|
|
|
WTAP_ENCAP_UNKNOWN, /* Other */
|
|
|
|
WTAP_ENCAP_UNKNOWN, /* Other */
|
|
|
|
WTAP_ENCAP_UNKNOWN, /* Other */
|
|
|
|
WTAP_ENCAP_IEEE_802_11_WITH_RADIO,
|
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
|
|
|
};
|
|
|
|
#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
|
|
|
|
2002-12-05 22:33:11 +00:00
|
|
|
/*
|
|
|
|
* Make sure it's a version we support.
|
|
|
|
*/
|
|
|
|
hdr.version = g_ntohl(hdr.version);
|
|
|
|
switch (hdr.version) {
|
|
|
|
|
|
|
|
case 2: /* Solaris 2.x and later snoop, and Shomiti
|
|
|
|
Surveyor prior to 3.0, or 3.0 and later
|
|
|
|
with NDIS card */
|
|
|
|
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 */
|
|
|
|
break;
|
|
|
|
|
|
|
|
default:
|
|
|
|
*err = WTAP_ERR_UNSUPPORTED;
|
Have the Wiretap open, read, and seek-and-read routines return, in
addition to an error code, an error info string, for
WTAP_ERR_UNSUPPORTED, WTAP_ERR_UNSUPPORTED_ENCAP, and
WTAP_ERR_BAD_RECORD errors. Replace the error messages logged with
"g_message()" for those errors with g_strdup()ed or g_strdup_printf()ed
strings returned as the error info string, and change the callers of
those routines to, for those errors, put the info string into the
printed message or alert box for the error.
Add messages for cases where those errors were returned without printing
an additional message.
Nobody uses the error code from "cf_read()" - "cf_read()" puts up the
alert box itself for failures; get rid of the error code, so it just
returns a success/failure indication.
Rename "file_read_error_message()" to "cf_read_error_message()", as it
handles read errors from Wiretap, and have it take an error info string
as an argument. (That handles a lot of the work of putting the info
string into the error message.)
Make some variables in "ascend-grammar.y" static.
Check the return value of "erf_read_header()" in "erf_seek_read()".
Get rid of an unused #define in "i4btrace.c".
svn path=/trunk/; revision=9852
2004-01-25 21:55:17 +00:00
|
|
|
*err_info = g_strdup_printf("snoop: version %u unsupported", hdr.version);
|
2002-12-05 22:33:11 +00:00
|
|
|
return -1;
|
|
|
|
}
|
|
|
|
|
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.
|
|
|
|
*
|
2002-12-05 22:33:11 +00:00
|
|
|
* We can't determine whether it's a Shomiti capture based on
|
|
|
|
* the version number, as, according to their documentation on
|
|
|
|
* their capture file format, Shomiti uses a version number of 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".
|
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
|
|
|
*
|
2002-12-05 22:33:11 +00:00
|
|
|
* The only way I can see to determine that is to check how much
|
2003-11-04 22:14:50 +00:00
|
|
|
* padding there is in the first packet - if there's enough
|
|
|
|
* padding for a Shomiti trailer, it's probably a Shomiti
|
|
|
|
* capture, and otherwise, it's probably from Snoop.
|
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
|
|
|
*/
|
2000-09-19 05:12:11 +00:00
|
|
|
|
2003-11-04 22:14:50 +00:00
|
|
|
/*
|
|
|
|
* Start out assuming it's not a Shomiti capture.
|
|
|
|
*/
|
|
|
|
is_shomiti = FALSE;
|
|
|
|
|
2002-12-05 22:33:11 +00:00
|
|
|
/* Read first record header. */
|
|
|
|
errno = WTAP_ERR_CANT_READ;
|
|
|
|
bytes_read = file_read(&rec_hdr, 1, sizeof rec_hdr, wth->fh);
|
|
|
|
if (bytes_read != sizeof rec_hdr) {
|
|
|
|
*err = file_error(wth->fh);
|
|
|
|
if (*err == 0 && bytes_read != 0)
|
|
|
|
*err = WTAP_ERR_SHORT_READ;
|
|
|
|
if (*err != 0) {
|
|
|
|
/*
|
|
|
|
* A real-live error.
|
|
|
|
*/
|
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
|
|
|
return -1;
|
|
|
|
}
|
2003-11-04 22:14:50 +00:00
|
|
|
|
|
|
|
/*
|
|
|
|
* The file ends after the record header, which means this
|
|
|
|
* is a capture with no packets.
|
|
|
|
*
|
|
|
|
* We assume it's a snoop file; the actual type of file is
|
|
|
|
* irrelevant, as there are no records in it, and thus no
|
|
|
|
* extra information if it's a Shomiti capture, and no
|
|
|
|
* link-layer headers whose type we have to know, and no
|
|
|
|
* Ethernet frames that might have an FCS.
|
|
|
|
*/
|
2002-12-05 22:33:11 +00:00
|
|
|
} else {
|
|
|
|
/*
|
|
|
|
* Compute the number of bytes of padding in the
|
2003-11-04 22:14:50 +00:00
|
|
|
* record. If it's at least the size of a Shomiti
|
|
|
|
* trailer record, we assume this is a Shomiti
|
|
|
|
* capture. (Some atmsnoop captures appear
|
|
|
|
* to have 4 bytes of padding, and at least one
|
|
|
|
* snoop capture appears to have 6 bytes of padding;
|
|
|
|
* the Shomiti header is larger than either of those.)
|
2002-12-05 22:33:11 +00:00
|
|
|
*/
|
2003-11-04 22:14:50 +00:00
|
|
|
if (g_ntohl(rec_hdr.rec_len) >
|
|
|
|
(sizeof rec_hdr + g_ntohl(rec_hdr.incl_len))) {
|
|
|
|
/*
|
|
|
|
* Well, we have padding; how much?
|
|
|
|
*/
|
|
|
|
padbytes = g_ntohl(rec_hdr.rec_len) -
|
2009-04-22 03:07:37 +00:00
|
|
|
((guint)sizeof rec_hdr + g_ntohl(rec_hdr.incl_len));
|
2003-11-04 22:14:50 +00:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Is it at least the size of a Shomiti trailer?
|
|
|
|
*/
|
|
|
|
is_shomiti =
|
|
|
|
(padbytes >= sizeof (struct shomiti_trailer));
|
|
|
|
}
|
2002-12-05 22:33:11 +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
|
|
|
|
2002-12-05 22:33:11 +00:00
|
|
|
/*
|
|
|
|
* Seek back to the beginning of the first record.
|
|
|
|
*/
|
|
|
|
if (file_seek(wth->fh, wth->data_offset, SEEK_SET, err) == -1)
|
|
|
|
return -1;
|
|
|
|
|
|
|
|
hdr.network = g_ntohl(hdr.network);
|
|
|
|
if (is_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
|
|
|
if (hdr.network >= NUM_SHOMITI_ENCAPS
|
|
|
|
|| shomiti_encap[hdr.network] == WTAP_ENCAP_UNKNOWN) {
|
|
|
|
*err = WTAP_ERR_UNSUPPORTED_ENCAP;
|
Have the Wiretap open, read, and seek-and-read routines return, in
addition to an error code, an error info string, for
WTAP_ERR_UNSUPPORTED, WTAP_ERR_UNSUPPORTED_ENCAP, and
WTAP_ERR_BAD_RECORD errors. Replace the error messages logged with
"g_message()" for those errors with g_strdup()ed or g_strdup_printf()ed
strings returned as the error info string, and change the callers of
those routines to, for those errors, put the info string into the
printed message or alert box for the error.
Add messages for cases where those errors were returned without printing
an additional message.
Nobody uses the error code from "cf_read()" - "cf_read()" puts up the
alert box itself for failures; get rid of the error code, so it just
returns a success/failure indication.
Rename "file_read_error_message()" to "cf_read_error_message()", as it
handles read errors from Wiretap, and have it take an error info string
as an argument. (That handles a lot of the work of putting the info
string into the error message.)
Make some variables in "ascend-grammar.y" static.
Check the return value of "erf_read_header()" in "erf_seek_read()".
Get rid of an unused #define in "i4btrace.c".
svn path=/trunk/; revision=9852
2004-01-25 21:55:17 +00:00
|
|
|
*err_info = g_strdup_printf("snoop: Shomiti network type %u unknown or unsupported",
|
|
|
|
hdr.network);
|
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
|
|
|
return -1;
|
|
|
|
}
|
|
|
|
file_encap = shomiti_encap[hdr.network];
|
2000-09-19 05:12:11 +00:00
|
|
|
|
2002-12-05 22:33:11 +00:00
|
|
|
/* This is a Shomiti file */
|
|
|
|
wth->file_type = WTAP_FILE_SHOMITI;
|
2009-12-03 15:27:39 +00:00
|
|
|
} else if (hdr.network & SNOOP_PRIVATE_BIT) {
|
|
|
|
if ((hdr.network^SNOOP_PRIVATE_BIT) >= NUM_SNOOP_PRIVATE_ENCAPS
|
|
|
|
|| snoop_private_encap[hdr.network^SNOOP_PRIVATE_BIT] == WTAP_ENCAP_UNKNOWN) {
|
|
|
|
*err = WTAP_ERR_UNSUPPORTED_ENCAP;
|
|
|
|
*err_info = g_strdup_printf("snoop: private network type %u unknown or unsupported",
|
|
|
|
hdr.network);
|
|
|
|
return -1;
|
|
|
|
}
|
|
|
|
file_encap = snoop_private_encap[hdr.network^SNOOP_PRIVATE_BIT];
|
|
|
|
|
|
|
|
/* This is a snoop file */
|
|
|
|
wth->file_type = WTAP_FILE_SNOOP;
|
2002-12-05 22:33:11 +00:00
|
|
|
} else {
|
|
|
|
if (hdr.network >= NUM_SNOOP_ENCAPS
|
|
|
|
|| snoop_encap[hdr.network] == WTAP_ENCAP_UNKNOWN) {
|
|
|
|
*err = WTAP_ERR_UNSUPPORTED_ENCAP;
|
Have the Wiretap open, read, and seek-and-read routines return, in
addition to an error code, an error info string, for
WTAP_ERR_UNSUPPORTED, WTAP_ERR_UNSUPPORTED_ENCAP, and
WTAP_ERR_BAD_RECORD errors. Replace the error messages logged with
"g_message()" for those errors with g_strdup()ed or g_strdup_printf()ed
strings returned as the error info string, and change the callers of
those routines to, for those errors, put the info string into the
printed message or alert box for the error.
Add messages for cases where those errors were returned without printing
an additional message.
Nobody uses the error code from "cf_read()" - "cf_read()" puts up the
alert box itself for failures; get rid of the error code, so it just
returns a success/failure indication.
Rename "file_read_error_message()" to "cf_read_error_message()", as it
handles read errors from Wiretap, and have it take an error info string
as an argument. (That handles a lot of the work of putting the info
string into the error message.)
Make some variables in "ascend-grammar.y" static.
Check the return value of "erf_read_header()" in "erf_seek_read()".
Get rid of an unused #define in "i4btrace.c".
svn path=/trunk/; revision=9852
2004-01-25 21:55:17 +00:00
|
|
|
*err_info = g_strdup_printf("snoop: network type %u unknown or unsupported",
|
|
|
|
hdr.network);
|
2002-12-05 22:33:11 +00:00
|
|
|
return -1;
|
|
|
|
}
|
|
|
|
file_encap = snoop_encap[hdr.network];
|
|
|
|
|
|
|
|
/* This is a snoop file */
|
|
|
|
wth->file_type = WTAP_FILE_SNOOP;
|
1998-11-15 05:29:17 +00:00
|
|
|
}
|
|
|
|
|
2002-12-05 22:33:11 +00:00
|
|
|
/*
|
|
|
|
* We don't currently use the extra information in Shomiti
|
|
|
|
* records, so we use the same routines to read snoop and
|
|
|
|
* Shomiti files.
|
|
|
|
*/
|
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 */
|
2005-08-25 21:29:54 +00:00
|
|
|
wth->tsprecision = WTAP_FILE_TSPREC_USEC;
|
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
|
|
|
}
|
|
|
|
|
2007-01-18 12:19:17 +00:00
|
|
|
typedef struct {
|
|
|
|
guint8 pad[4];
|
|
|
|
guint8 undecrypt[2];
|
|
|
|
guint8 rate;
|
|
|
|
guint8 preamble;
|
|
|
|
guint8 code;
|
|
|
|
guint8 signal;
|
|
|
|
guint8 qual;
|
|
|
|
guint8 channel;
|
|
|
|
} shomiti_wireless_header;
|
|
|
|
|
|
|
|
|
1998-11-15 05:29:17 +00:00
|
|
|
/* Read the next packet */
|
Have the Wiretap open, read, and seek-and-read routines return, in
addition to an error code, an error info string, for
WTAP_ERR_UNSUPPORTED, WTAP_ERR_UNSUPPORTED_ENCAP, and
WTAP_ERR_BAD_RECORD errors. Replace the error messages logged with
"g_message()" for those errors with g_strdup()ed or g_strdup_printf()ed
strings returned as the error info string, and change the callers of
those routines to, for those errors, put the info string into the
printed message or alert box for the error.
Add messages for cases where those errors were returned without printing
an additional message.
Nobody uses the error code from "cf_read()" - "cf_read()" puts up the
alert box itself for failures; get rid of the error code, so it just
returns a success/failure indication.
Rename "file_read_error_message()" to "cf_read_error_message()", as it
handles read errors from Wiretap, and have it take an error info string
as an argument. (That handles a lot of the work of putting the info
string into the error message.)
Make some variables in "ascend-grammar.y" static.
Check the return value of "erf_read_header()" in "erf_seek_read()".
Get rid of an unused #define in "i4btrace.c".
svn path=/trunk/; revision=9852
2004-01-25 21:55:17 +00:00
|
|
|
static gboolean snoop_read(wtap *wth, int *err, gchar **err_info,
|
2006-11-05 22:46:44 +00:00
|
|
|
gint64 *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];
|
2003-11-04 22:14:50 +00:00
|
|
|
guint padbytes;
|
1999-09-02 00:14:06 +00:00
|
|
|
int bytes_to_read;
|
2009-09-17 02:12:08 +00:00
|
|
|
int header_size;
|
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);
|
2002-12-05 22:33:11 +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;
|
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
|
|
|
|
2002-07-29 06:09:59 +00:00
|
|
|
rec_size = g_ntohl(hdr.rec_len);
|
|
|
|
orig_size = g_ntohl(hdr.orig_len);
|
|
|
|
packet_size = g_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.
|
|
|
|
*/
|
|
|
|
*err = WTAP_ERR_BAD_RECORD;
|
Have the Wiretap open, read, and seek-and-read routines return, in
addition to an error code, an error info string, for
WTAP_ERR_UNSUPPORTED, WTAP_ERR_UNSUPPORTED_ENCAP, and
WTAP_ERR_BAD_RECORD errors. Replace the error messages logged with
"g_message()" for those errors with g_strdup()ed or g_strdup_printf()ed
strings returned as the error info string, and change the callers of
those routines to, for those errors, put the info string into the
printed message or alert box for the error.
Add messages for cases where those errors were returned without printing
an additional message.
Nobody uses the error code from "cf_read()" - "cf_read()" puts up the
alert box itself for failures; get rid of the error code, so it just
returns a success/failure indication.
Rename "file_read_error_message()" to "cf_read_error_message()", as it
handles read errors from Wiretap, and have it take an error info string
as an argument. (That handles a lot of the work of putting the info
string into the error message.)
Make some variables in "ascend-grammar.y" static.
Check the return value of "erf_read_header()" in "erf_seek_read()".
Get rid of an unused #define in "i4btrace.c".
svn path=/trunk/; revision=9852
2004-01-25 21:55:17 +00:00
|
|
|
*err_info = g_strdup_printf("snoop: File has %u-byte packet, bigger than maximum of %u",
|
|
|
|
packet_size, WTAP_MAX_PACKET_SIZE);
|
2000-09-07 05:34:23 +00:00
|
|
|
return FALSE;
|
1999-08-22 02:29:40 +00:00
|
|
|
}
|
2003-12-19 22:23:05 +00:00
|
|
|
if (packet_size > rec_size) {
|
|
|
|
/*
|
|
|
|
* Probably a corrupt capture file.
|
|
|
|
*/
|
|
|
|
*err = WTAP_ERR_BAD_RECORD;
|
Have the Wiretap open, read, and seek-and-read routines return, in
addition to an error code, an error info string, for
WTAP_ERR_UNSUPPORTED, WTAP_ERR_UNSUPPORTED_ENCAP, and
WTAP_ERR_BAD_RECORD errors. Replace the error messages logged with
"g_message()" for those errors with g_strdup()ed or g_strdup_printf()ed
strings returned as the error info string, and change the callers of
those routines to, for those errors, put the info string into the
printed message or alert box for the error.
Add messages for cases where those errors were returned without printing
an additional message.
Nobody uses the error code from "cf_read()" - "cf_read()" puts up the
alert box itself for failures; get rid of the error code, so it just
returns a success/failure indication.
Rename "file_read_error_message()" to "cf_read_error_message()", as it
handles read errors from Wiretap, and have it take an error info string
as an argument. (That handles a lot of the work of putting the info
string into the error message.)
Make some variables in "ascend-grammar.y" static.
Check the return value of "erf_read_header()" in "erf_seek_read()".
Get rid of an unused #define in "i4btrace.c".
svn path=/trunk/; revision=9852
2004-01-25 21:55:17 +00:00
|
|
|
*err_info = g_strdup_printf("snoop: File has %u-byte packet, bigger than record size %u",
|
|
|
|
packet_size, rec_size);
|
2003-12-19 22:23:05 +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
|
|
|
|
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.
|
|
|
|
*/
|
2003-10-01 07:11:49 +00:00
|
|
|
switch (wth->file_encap) {
|
|
|
|
|
|
|
|
case WTAP_ENCAP_ATM_PDUS:
|
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.
|
|
|
|
*/
|
|
|
|
*err = WTAP_ERR_BAD_RECORD;
|
2009-06-02 07:18:18 +00:00
|
|
|
*err_info = g_strdup_printf("snoop: atmsnoop file has a %u-byte packet, too small to have even an ATM pseudo-header",
|
Have the Wiretap open, read, and seek-and-read routines return, in
addition to an error code, an error info string, for
WTAP_ERR_UNSUPPORTED, WTAP_ERR_UNSUPPORTED_ENCAP, and
WTAP_ERR_BAD_RECORD errors. Replace the error messages logged with
"g_message()" for those errors with g_strdup()ed or g_strdup_printf()ed
strings returned as the error info string, and change the callers of
those routines to, for those errors, put the info string into the
printed message or alert box for the error.
Add messages for cases where those errors were returned without printing
an additional message.
Nobody uses the error code from "cf_read()" - "cf_read()" puts up the
alert box itself for failures; get rid of the error code, so it just
returns a success/failure indication.
Rename "file_read_error_message()" to "cf_read_error_message()", as it
handles read errors from Wiretap, and have it take an error info string
as an argument. (That handles a lot of the work of putting the info
string into the error message.)
Make some variables in "ascend-grammar.y" static.
Check the return value of "erf_read_header()" in "erf_seek_read()".
Get rid of an unused #define in "i4btrace.c".
svn path=/trunk/; revision=9852
2004-01-25 21:55:17 +00:00
|
|
|
packet_size);
|
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.
|
|
|
|
*/
|
2009-04-22 03:07:37 +00:00
|
|
|
rec_size -= (guint32)sizeof (struct snoop_atm_hdr);
|
|
|
|
orig_size -= (guint32)sizeof (struct snoop_atm_hdr);
|
|
|
|
packet_size -= (guint32)sizeof (struct snoop_atm_hdr);
|
2002-04-30 09:23:29 +00:00
|
|
|
wth->data_offset += sizeof (struct snoop_atm_hdr);
|
2003-10-01 07:11:49 +00:00
|
|
|
break;
|
|
|
|
|
|
|
|
case WTAP_ENCAP_ETHERNET:
|
|
|
|
/*
|
|
|
|
* If this is a snoop file, we assume there's no FCS in
|
|
|
|
* this frame; if this is a Shomit file, we assume there
|
|
|
|
* is. (XXX - or should we treat it a "maybe"?)
|
|
|
|
*/
|
|
|
|
if (wth->file_type == WTAP_FILE_SHOMITI)
|
|
|
|
wth->pseudo_header.eth.fcs_len = 4;
|
|
|
|
else
|
|
|
|
wth->pseudo_header.eth.fcs_len = 0;
|
|
|
|
break;
|
2007-01-18 12:19:17 +00:00
|
|
|
|
|
|
|
case WTAP_ENCAP_IEEE_802_11_WITH_RADIO:
|
|
|
|
if (packet_size < sizeof (shomiti_wireless_header)) {
|
|
|
|
/*
|
|
|
|
* Uh-oh, the packet isn't big enough to even
|
|
|
|
* have a pseudo-header.
|
|
|
|
*/
|
|
|
|
*err = WTAP_ERR_BAD_RECORD;
|
2009-06-02 07:18:18 +00:00
|
|
|
*err_info = g_strdup_printf("snoop: Shomiti wireless file has a %u-byte packet, too small to have even a wireless pseudo-header",
|
2007-01-18 12:19:17 +00:00
|
|
|
packet_size);
|
|
|
|
return FALSE;
|
|
|
|
}
|
|
|
|
if (!snoop_read_shomiti_wireless_pseudoheader(wth->fh,
|
2009-09-17 02:59:26 +00:00
|
|
|
&wth->pseudo_header, err, err_info, &header_size))
|
2007-01-18 12:19:17 +00:00
|
|
|
return FALSE; /* Read error */
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Don't count the pseudo-header as part of the packet.
|
|
|
|
*/
|
2009-09-17 02:12:08 +00:00
|
|
|
rec_size -= header_size;
|
|
|
|
orig_size -= header_size;
|
|
|
|
packet_size -= header_size;
|
|
|
|
wth->data_offset += header_size;
|
2007-01-18 12:19:17 +00:00
|
|
|
break;
|
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
|
|
|
|
2005-08-24 21:31:56 +00:00
|
|
|
wth->phdr.ts.secs = g_ntohl(hdr.ts_sec);
|
|
|
|
wth->phdr.ts.nsecs = g_ntohl(hdr.ts_usec) * 1000;
|
1998-11-15 05:29:17 +00:00
|
|
|
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;
|
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.
|
|
|
|
*/
|
Rename WTAP_ENCAP_ATM_SNIFFER to WTAP_ENCAP_ATM_PDUS, as it's not just
used for the DOS-based ATM Sniffer. (That's not a great name, but I
couldn't think of a better one.)
Add a new WTAP_ENCAP_ATM_PDUS_UNTRUNCATED encapsulation type for capture
files where reassembled frames don't have trailers, such as the AAL5
trailer, chopped off. That's what at least some versions of the
Windows-based ATM Sniffer appear to have.
Map the ATM capture file type for NetXRay captures to
WTAP_ENCAP_ATM_PDUS_UNTRUNCATED, and put in stuff to fill in what we've
reverse-engineered, so far, for the pseudo-header; there's more that
needs to be done on it, e.g. getting the channel, AAL type, and traffic
type (or inferring them if they're not in the packet header).
svn path=/trunk/; revision=6840
2003-01-03 06:45:45 +00:00
|
|
|
if (wth->file_encap == WTAP_ENCAP_ATM_PDUS &&
|
2002-04-30 18:58:16 +00:00
|
|
|
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.
|
|
|
|
*/
|
2003-11-04 22:14:50 +00:00
|
|
|
if (rec_size < (sizeof hdr + packet_size)) {
|
|
|
|
/*
|
|
|
|
* What, *negative* padding? Bogus.
|
|
|
|
*/
|
|
|
|
*err = WTAP_ERR_BAD_RECORD;
|
Have the Wiretap open, read, and seek-and-read routines return, in
addition to an error code, an error info string, for
WTAP_ERR_UNSUPPORTED, WTAP_ERR_UNSUPPORTED_ENCAP, and
WTAP_ERR_BAD_RECORD errors. Replace the error messages logged with
"g_message()" for those errors with g_strdup()ed or g_strdup_printf()ed
strings returned as the error info string, and change the callers of
those routines to, for those errors, put the info string into the
printed message or alert box for the error.
Add messages for cases where those errors were returned without printing
an additional message.
Nobody uses the error code from "cf_read()" - "cf_read()" puts up the
alert box itself for failures; get rid of the error code, so it just
returns a success/failure indication.
Rename "file_read_error_message()" to "cf_read_error_message()", as it
handles read errors from Wiretap, and have it take an error info string
as an argument. (That handles a lot of the work of putting the info
string into the error message.)
Make some variables in "ascend-grammar.y" static.
Check the return value of "erf_read_header()" in "erf_seek_read()".
Get rid of an unused #define in "i4btrace.c".
svn path=/trunk/; revision=9852
2004-01-25 21:55:17 +00:00
|
|
|
*err_info = g_strdup_printf("snoop: File has %u-byte record with packet size of %u",
|
|
|
|
rec_size, packet_size);
|
2003-11-04 22:14:50 +00:00
|
|
|
return FALSE;
|
|
|
|
}
|
2009-04-22 03:07:37 +00:00
|
|
|
padbytes = rec_size - ((guint)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
|
2006-11-05 22:46:44 +00:00
|
|
|
snoop_seek_read(wtap *wth, gint64 seek_off,
|
Have the Wiretap open, read, and seek-and-read routines return, in
addition to an error code, an error info string, for
WTAP_ERR_UNSUPPORTED, WTAP_ERR_UNSUPPORTED_ENCAP, and
WTAP_ERR_BAD_RECORD errors. Replace the error messages logged with
"g_message()" for those errors with g_strdup()ed or g_strdup_printf()ed
strings returned as the error info string, and change the callers of
those routines to, for those errors, put the info string into the
printed message or alert box for the error.
Add messages for cases where those errors were returned without printing
an additional message.
Nobody uses the error code from "cf_read()" - "cf_read()" puts up the
alert box itself for failures; get rid of the error code, so it just
returns a success/failure indication.
Rename "file_read_error_message()" to "cf_read_error_message()", as it
handles read errors from Wiretap, and have it take an error info string
as an argument. (That handles a lot of the work of putting the info
string into the error message.)
Make some variables in "ascend-grammar.y" static.
Check the return value of "erf_read_header()" in "erf_seek_read()".
Get rid of an unused #define in "i4btrace.c".
svn path=/trunk/; revision=9852
2004-01-25 21:55:17 +00:00
|
|
|
union wtap_pseudo_header *pseudo_header, guchar *pd, int length,
|
2009-09-17 02:59:26 +00:00
|
|
|
int *err, gchar **err_info)
|
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
|
|
|
|
2003-10-01 07:11:49 +00:00
|
|
|
switch (wth->file_encap) {
|
|
|
|
|
|
|
|
case WTAP_ENCAP_ATM_PDUS:
|
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
|
|
|
}
|
2003-10-01 07:11:49 +00:00
|
|
|
break;
|
|
|
|
|
|
|
|
case WTAP_ENCAP_ETHERNET:
|
|
|
|
/*
|
|
|
|
* If this is a snoop file, we assume there's no FCS in
|
|
|
|
* this frame; if this is a Shomit file, we assume there
|
|
|
|
* is. (XXX - or should we treat it a "maybe"?)
|
|
|
|
*/
|
|
|
|
if (wth->file_type == WTAP_FILE_SHOMITI)
|
|
|
|
pseudo_header->eth.fcs_len = 4;
|
|
|
|
else
|
|
|
|
pseudo_header->eth.fcs_len = 0;
|
|
|
|
break;
|
2007-01-18 12:19:17 +00:00
|
|
|
|
|
|
|
case WTAP_ENCAP_IEEE_802_11_WITH_RADIO:
|
|
|
|
if (!snoop_read_shomiti_wireless_pseudoheader(wth->random_fh,
|
2009-09-17 02:59:26 +00:00
|
|
|
pseudo_header, err, err_info, NULL)) {
|
2007-01-18 12:19:17 +00:00
|
|
|
/* Read error */
|
|
|
|
return FALSE;
|
|
|
|
}
|
|
|
|
break;
|
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.
|
|
|
|
*/
|
Rename WTAP_ENCAP_ATM_SNIFFER to WTAP_ENCAP_ATM_PDUS, as it's not just
used for the DOS-based ATM Sniffer. (That's not a great name, but I
couldn't think of a better one.)
Add a new WTAP_ENCAP_ATM_PDUS_UNTRUNCATED encapsulation type for capture
files where reassembled frames don't have trailers, such as the AAL5
trailer, chopped off. That's what at least some versions of the
Windows-based ATM Sniffer appear to have.
Map the ATM capture file type for NetXRay captures to
WTAP_ENCAP_ATM_PDUS_UNTRUNCATED, and put in stuff to fill in what we've
reverse-engineered, so far, for the pseudo-header; there's more that
needs to be done on it, e.g. getting the channel, AAL type, and traffic
type (or inferring them if they're not in the packet header).
svn path=/trunk/; revision=6840
2003-01-03 06:45:45 +00:00
|
|
|
if (wth->file_encap == WTAP_ENCAP_ATM_PDUS &&
|
2002-05-23 08:17:31 +00:00
|
|
|
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;
|
2003-01-09 01:55:13 +00:00
|
|
|
pseudo_header->atm.channel = (atm_phdr.flags & 0x80) ? 0 : 1;
|
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 */
|
2003-01-10 04:04:42 +00:00
|
|
|
pseudo_header->atm.flags = 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
|
|
|
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
|
|
|
}
|
|
|
|
|
2007-01-18 12:19:17 +00:00
|
|
|
static gboolean
|
|
|
|
snoop_read_shomiti_wireless_pseudoheader(FILE_T fh,
|
2009-09-17 02:59:26 +00:00
|
|
|
union wtap_pseudo_header *pseudo_header, int *err, gchar **err_info,
|
|
|
|
int *header_size)
|
2007-01-18 12:19:17 +00:00
|
|
|
{
|
|
|
|
shomiti_wireless_header whdr;
|
|
|
|
int bytes_read;
|
2009-09-17 02:42:31 +00:00
|
|
|
int rsize;
|
2007-01-18 12:19:17 +00:00
|
|
|
|
|
|
|
errno = WTAP_ERR_CANT_READ;
|
|
|
|
bytes_read = file_read(&whdr, 1, sizeof (shomiti_wireless_header), fh);
|
|
|
|
if (bytes_read != sizeof (shomiti_wireless_header)) {
|
|
|
|
*err = file_error(fh);
|
|
|
|
if (*err == 0)
|
|
|
|
*err = WTAP_ERR_SHORT_READ;
|
|
|
|
return FALSE;
|
|
|
|
}
|
|
|
|
|
2009-09-17 02:12:08 +00:00
|
|
|
/* the 4th byte of the pad is actually a header length,
|
2009-09-17 02:42:31 +00:00
|
|
|
* we've already read 8 bytes of it, and it must never
|
|
|
|
* be less than 8.
|
|
|
|
*
|
|
|
|
* XXX - presumably that means that the header length
|
|
|
|
* doesn't include the length field, as we've read
|
|
|
|
* 12 bytes total.
|
|
|
|
*
|
|
|
|
* XXX - what's in the other 3 bytes of the padding? Is it a
|
|
|
|
* 4-byte length field?
|
|
|
|
* XXX - is there anything in the rest of the header of interest?
|
|
|
|
* XXX - are there any files where the header is shorter than
|
|
|
|
* 4 bytes of length plus 8 bytes of information?
|
2009-09-17 02:12:08 +00:00
|
|
|
*/
|
2009-09-17 02:42:31 +00:00
|
|
|
if (whdr.pad[3] < 8) {
|
|
|
|
*err = WTAP_ERR_BAD_RECORD;
|
|
|
|
*err_info = g_strdup_printf("snoop: Header length in Surveyor record is %u, less than minimum of 8",
|
|
|
|
whdr.pad[3]);
|
2009-09-17 02:12:08 +00:00
|
|
|
return FALSE;
|
|
|
|
}
|
2009-09-17 02:42:31 +00:00
|
|
|
/* Skip the header. */
|
|
|
|
rsize = ((int) whdr.pad[3]) - 8;
|
2009-09-17 03:00:20 +00:00
|
|
|
if (file_seek(fh, rsize, SEEK_CUR, err) == -1)
|
2009-09-17 02:42:31 +00:00
|
|
|
return FALSE;
|
2009-09-17 02:12:08 +00:00
|
|
|
|
2007-01-18 12:19:17 +00:00
|
|
|
pseudo_header->ieee_802_11.fcs_len = 4;
|
|
|
|
pseudo_header->ieee_802_11.channel = whdr.channel;
|
|
|
|
pseudo_header->ieee_802_11.data_rate = whdr.rate;
|
|
|
|
pseudo_header->ieee_802_11.signal_level = whdr.signal;
|
|
|
|
|
2009-09-17 02:12:08 +00:00
|
|
|
/* add back the header and don't forget the pad as well */
|
|
|
|
if(header_size != NULL)
|
|
|
|
*header_size = rsize + 8 + 4;
|
|
|
|
|
|
|
|
return TRUE;
|
2007-01-18 12:19:17 +00:00
|
|
|
}
|
|
|
|
|
2002-03-05 08:40:27 +00:00
|
|
|
static gboolean
|
2002-07-29 06:09:59 +00:00
|
|
|
snoop_read_rec_data(FILE_T fh, guchar *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*/
|
Rename WTAP_ENCAP_ATM_SNIFFER to WTAP_ENCAP_ATM_PDUS, as it's not just
used for the DOS-based ATM Sniffer. (That's not a great name, but I
couldn't think of a better one.)
Add a new WTAP_ENCAP_ATM_PDUS_UNTRUNCATED encapsulation type for capture
files where reassembled frames don't have trailers, such as the AAL5
trailer, chopped off. That's what at least some versions of the
Windows-based ATM Sniffer appear to have.
Map the ATM capture file type for NetXRay captures to
WTAP_ENCAP_ATM_PDUS_UNTRUNCATED, and put in stuff to fill in what we've
reverse-engineered, so far, for the pseudo-header; there's more that
needs to be done on it, e.g. getting the channel, AAL type, and traffic
type (or inferring them if they're not in the packet header).
svn path=/trunk/; revision=6840
2003-01-03 06:45:45 +00:00
|
|
|
0x12, /* WTAP_ENCAP_ATM_PDUS -> DL_IPATM */
|
2002-04-30 09:23:29 +00:00
|
|
|
-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;
|
|
|
|
|
|
|
|
/* 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. */
|
2010-06-06 22:19:30 +00:00
|
|
|
if (!wtap_dump_file_write(wdh, &snoop_magic, sizeof snoop_magic, err))
|
1999-12-04 05:14:39 +00:00
|
|
|
return FALSE;
|
1999-12-04 03:36:22 +00:00
|
|
|
|
|
|
|
/* current "snoop" format is 2 */
|
2002-07-29 06:09:59 +00:00
|
|
|
file_hdr.version = g_htonl(2);
|
|
|
|
file_hdr.network = g_htonl(wtap_encap[wdh->encap]);
|
2010-06-06 22:19:30 +00:00
|
|
|
if (!wtap_dump_file_write(wdh, &file_hdr, sizeof file_hdr, err))
|
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_,
|
2002-07-29 06:09:59 +00:00
|
|
|
const guchar *pd, int *err)
|
1999-12-04 03:36:22 +00:00
|
|
|
{
|
|
|
|
struct snooprec_hdr rec_hdr;
|
|
|
|
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;
|
|
|
|
|
Rename WTAP_ENCAP_ATM_SNIFFER to WTAP_ENCAP_ATM_PDUS, as it's not just
used for the DOS-based ATM Sniffer. (That's not a great name, but I
couldn't think of a better one.)
Add a new WTAP_ENCAP_ATM_PDUS_UNTRUNCATED encapsulation type for capture
files where reassembled frames don't have trailers, such as the AAL5
trailer, chopped off. That's what at least some versions of the
Windows-based ATM Sniffer appear to have.
Map the ATM capture file type for NetXRay captures to
WTAP_ENCAP_ATM_PDUS_UNTRUNCATED, and put in stuff to fill in what we've
reverse-engineered, so far, for the pseudo-header; there's more that
needs to be done on it, e.g. getting the channel, AAL type, and traffic
type (or inferring them if they're not in the packet header).
svn path=/trunk/; revision=6840
2003-01-03 06:45:45 +00:00
|
|
|
if (wdh->encap == WTAP_ENCAP_ATM_PDUS)
|
2002-04-30 09:23:29 +00:00
|
|
|
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... */
|
2009-04-22 03:07:37 +00:00
|
|
|
reclen = (int)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-07-29 06:09:59 +00:00
|
|
|
rec_hdr.orig_len = g_htonl(phdr->len + atm_hdrsize);
|
|
|
|
rec_hdr.incl_len = g_htonl(phdr->caplen + atm_hdrsize);
|
|
|
|
rec_hdr.rec_len = g_htonl(reclen);
|
1999-12-04 03:36:22 +00:00
|
|
|
rec_hdr.cum_drops = 0;
|
2005-08-24 21:31:56 +00:00
|
|
|
rec_hdr.ts_sec = g_htonl(phdr->ts.secs);
|
2005-12-31 11:48:32 +00:00
|
|
|
rec_hdr.ts_usec = g_htonl(phdr->ts.nsecs / 1000);
|
2010-06-06 22:19:30 +00:00
|
|
|
if (!wtap_dump_file_write(wdh, &rec_hdr, sizeof rec_hdr, err))
|
1999-12-04 05:14:39 +00:00
|
|
|
return FALSE;
|
2002-04-30 09:23:29 +00:00
|
|
|
|
Rename WTAP_ENCAP_ATM_SNIFFER to WTAP_ENCAP_ATM_PDUS, as it's not just
used for the DOS-based ATM Sniffer. (That's not a great name, but I
couldn't think of a better one.)
Add a new WTAP_ENCAP_ATM_PDUS_UNTRUNCATED encapsulation type for capture
files where reassembled frames don't have trailers, such as the AAL5
trailer, chopped off. That's what at least some versions of the
Windows-based ATM Sniffer appear to have.
Map the ATM capture file type for NetXRay captures to
WTAP_ENCAP_ATM_PDUS_UNTRUNCATED, and put in stuff to fill in what we've
reverse-engineered, so far, for the pseudo-header; there's more that
needs to be done on it, e.g. getting the channel, AAL type, and traffic
type (or inferring them if they're not in the packet header).
svn path=/trunk/; revision=6840
2003-01-03 06:45:45 +00:00
|
|
|
if (wdh->encap == WTAP_ENCAP_ATM_PDUS) {
|
2002-04-30 09:23:29 +00:00
|
|
|
/*
|
|
|
|
* Write the ATM header.
|
|
|
|
*/
|
|
|
|
atm_hdr.flags =
|
2003-01-09 01:55:13 +00:00
|
|
|
(pseudo_header->atm.channel == 0) ? 0x80 : 0x00;
|
2002-04-30 09:23:29 +00:00
|
|
|
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;
|
|
|
|
}
|
2004-01-05 17:33:28 +00:00
|
|
|
atm_hdr.vpi = (guint8) pseudo_header->atm.vpi;
|
2002-07-29 06:09:59 +00:00
|
|
|
atm_hdr.vci = g_htons(pseudo_header->atm.vci);
|
2010-06-06 22:19:30 +00:00
|
|
|
if (!wtap_dump_file_write(wdh, &atm_hdr, sizeof atm_hdr, err))
|
2002-04-30 09:23:29 +00:00
|
|
|
return FALSE;
|
|
|
|
}
|
|
|
|
|
2010-06-06 22:19:30 +00:00
|
|
|
if (!wtap_dump_file_write(wdh, pd, phdr->caplen, err))
|
1999-12-04 05:14:39 +00:00
|
|
|
return FALSE;
|
1999-12-04 03:36:22 +00:00
|
|
|
|
|
|
|
/* Now write the padding. */
|
2010-06-06 22:19:30 +00:00
|
|
|
if (!wtap_dump_file_write(wdh, zeroes, padlen, err))
|
1999-12-04 05:14:39 +00:00
|
|
|
return FALSE;
|
|
|
|
return TRUE;
|
1999-12-04 03:36:22 +00:00
|
|
|
}
|