1998-11-15 05:29:17 +00:00
|
|
|
/* snoop.c
|
|
|
|
|
*
|
|
|
|
|
* 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
|
|
|
*
|
2018-02-07 11:26:45 +00:00
|
|
|
* SPDX-License-Identifier: GPL-2.0-or-later
|
1998-11-15 05:29:17 +00:00
|
|
|
*/
|
2002-02-27 08:57:25 +00:00
|
|
|
|
1999-07-13 02:53:26 +00:00
|
|
|
#include "config.h"
|
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"
|
2002-04-30 18:58:16 +00:00
|
|
|
#include "atm.h"
|
1998-11-15 05:29:17 +00:00
|
|
|
#include "snoop.h"
|
2021-03-10 09:42:51 +00:00
|
|
|
#include <wsutil/802_11-utils.h>
|
2021-06-16 09:01:23 +00:00
|
|
|
#include <wsutil/ws_roundup.h>
|
2021-03-10 09:42:51 +00:00
|
|
|
|
1998-11-15 05:29:17 +00:00
|
|
|
/* See RFC 1761 for a description of the "snoop" file format. */
|
|
|
|
|
|
wiretap: register most built-in file types from its module.
Remove most of the built-in file types from the table in
wiretap/file_access.c and, instead, have the file types register
themselves, using wtap_register_file_type_subtypes().
This reduces the source code changes needed to add a new file type from
three (add the handler, add the file type to the table in file_access.c,
add a #define for the file type in wiretap/wtap.h) to one (add the
handler). (It also requires adding the handler's source file to
wiretap/CMakeLists.txt, but that's required in both cases.)
A few remain because the WTAP_FILE_TYPE_SUBTYPE_ #define is used
elsewhere; that needs to be fixed.
Fix the wiretap/CMakefile.txt file to scan k12text.l, as that now
contains a registration routine. In the process, avoid scanning files
that don't implement a file type and won't ever have a registration
routine.
Add a Lua routine to fetch the total number of file types; we use that
in some code to construct the wtap_filetypes table, which we need to do
in order to continue to have all the values that used to come from the
WTAP_FILE_TYPE_SUBTYPE_ types.
While we're at it, add modelines to a file that lacked them.
2021-02-14 08:34:10 +00:00
|
|
|
typedef struct {
|
|
|
|
|
gboolean is_shomiti;
|
|
|
|
|
} snoop_t;
|
|
|
|
|
|
1998-11-15 05:29:17 +00:00
|
|
|
/* 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 */
|
|
|
|
|
|
2019-04-05 01:56:27 +00:00
|
|
|
static gboolean snoop_read(wtap *wth, wtap_rec *rec, Buffer *buf,
|
|
|
|
|
int *err, gchar **err_info, gint64 *data_offset);
|
2014-05-23 10:50:02 +00:00
|
|
|
static gboolean snoop_seek_read(wtap *wth, gint64 seek_off,
|
2018-02-09 00:19:12 +00:00
|
|
|
wtap_rec *rec, Buffer *buf, int *err, gchar **err_info);
|
|
|
|
|
static int snoop_read_packet(wtap *wth, FILE_T fh, wtap_rec *rec,
|
2013-06-17 21:18:47 +00:00
|
|
|
Buffer *buf, int *err, gchar **err_info);
|
2002-03-05 08:40:27 +00:00
|
|
|
static gboolean snoop_read_atm_pseudoheader(FILE_T fh,
|
2011-04-21 09:41:52 +00:00
|
|
|
union wtap_pseudo_header *pseudo_header, int *err, gchar **err_info);
|
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);
|
2018-02-09 00:19:12 +00:00
|
|
|
static gboolean snoop_dump(wtap_dumper *wdh, const wtap_rec *rec,
|
2014-12-18 00:02:50 +00:00
|
|
|
const guint8 *pd, int *err, gchar **err_info);
|
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
|
|
|
|
wiretap: register most built-in file types from its module.
Remove most of the built-in file types from the table in
wiretap/file_access.c and, instead, have the file types register
themselves, using wtap_register_file_type_subtypes().
This reduces the source code changes needed to add a new file type from
three (add the handler, add the file type to the table in file_access.c,
add a #define for the file type in wiretap/wtap.h) to one (add the
handler). (It also requires adding the handler's source file to
wiretap/CMakeLists.txt, but that's required in both cases.)
A few remain because the WTAP_FILE_TYPE_SUBTYPE_ #define is used
elsewhere; that needs to be fixed.
Fix the wiretap/CMakefile.txt file to scan k12text.l, as that now
contains a registration routine. In the process, avoid scanning files
that don't implement a file type and won't ever have a registration
routine.
Add a Lua routine to fetch the total number of file types; we use that
in some code to construct the wtap_filetypes table, which we need to do
in order to continue to have all the values that used to come from the
WTAP_FILE_TYPE_SUBTYPE_ types.
While we're at it, add modelines to a file that lacked them.
2021-02-14 08:34:10 +00:00
|
|
|
static int snoop_file_type_subtype = -1;
|
|
|
|
|
static int shomiti_file_type_subtype = -1;
|
|
|
|
|
|
|
|
|
|
void register_snoop(void);
|
|
|
|
|
|
1999-11-26 11:18:12 +00:00
|
|
|
/*
|
|
|
|
|
* See
|
2002-08-28 20:30:45 +00:00
|
|
|
*
|
2019-07-28 04:20:27 +00:00
|
|
|
* https://pubs.opengroup.org/onlinepubs/9638599/apdxf.htm
|
1999-11-26 11:18:12 +00:00
|
|
|
*
|
|
|
|
|
* 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
|
|
|
*
|
2011-12-03 07:16:56 +00:00
|
|
|
* See
|
|
|
|
|
*
|
2019-07-28 04:20:27 +00:00
|
|
|
* https://www.iana.org/assignments/snoop-datalink-types
|
2011-12-03 07:16:56 +00:00
|
|
|
*
|
|
|
|
|
* for the IETF list of snoop datalink types.
|
|
|
|
|
*
|
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
|
2020-10-10 23:42:05 +00:00
|
|
|
* DLPI support; they suggested that the 3.0 version of SUNatm uses those
|
2002-09-04 19:29:59 +00:00
|
|
|
* 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
|
2011-12-03 07:16:56 +00:00
|
|
|
* also includes "atmdump", which is a modified "tcpdump", was available
|
2002-09-04 19:29:59 +00:00
|
|
|
* at
|
|
|
|
|
*
|
|
|
|
|
* ftp://ftp.cs.ndsu.nodak.edu/pub/freebsd/atm/atm-bpf.tgz
|
|
|
|
|
*
|
2011-12-03 07:16:56 +00:00
|
|
|
* (the host name is no longer valid) and that code also indicated that
|
|
|
|
|
* DL_IPATM is used, and that an ATM packet handed up from the Sun driver
|
|
|
|
|
* for the Sun SBus ATM card on Solaris 2.5.1 has 1 byte of direction,
|
|
|
|
|
* 1 byte of VPI, 2 bytes of VCI, and then the ATM PDU, and suggests that
|
|
|
|
|
* the direction flag is 0x80 for "transmitted" (presumably meaning
|
|
|
|
|
* DTE->DCE) and presumably not 0x80 for "received" (presumably meaning
|
|
|
|
|
* DCE->DTE). That code was used as the basis for the SunATM support in
|
|
|
|
|
* later versions of libpcap and tcpdump, and it worked at the time the
|
|
|
|
|
* development was done with the SunATM code on the system on which the
|
|
|
|
|
* development was done.
|
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
|
|
|
*
|
2019-07-28 04:20:27 +00:00
|
|
|
* https://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
|
|
|
*
|
2014-09-20 09:15:44 +00:00
|
|
|
* gives information on Shomiti's mutant flavor of snoop. For some 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
|
2011-12-03 07:16:56 +00:00
|
|
|
* 4MB from 16MB Token Ring, and distinguishing both of them from the
|
|
|
|
|
* "Shomiti" versions of same.
|
1999-11-26 11:18:12 +00:00
|
|
|
*/
|
2014-10-09 23:44:15 +00:00
|
|
|
wtap_open_return_val snoop_open(wtap *wth, int *err, gchar **err_info)
|
1998-11-15 05:29:17 +00:00
|
|
|
{
|
|
|
|
|
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) */
|
2016-03-23 09:02:34 +00:00
|
|
|
WTAP_ENCAP_IP_OVER_IB_SNOOP, /* Infiniband */
|
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 */
|
2011-06-16 08:04:31 +00:00
|
|
|
WTAP_ENCAP_IEEE_802_11_WITH_RADIO, /* IEEE 802.11 with Radio Header */
|
|
|
|
|
WTAP_ENCAP_ETHERNET, /* 10 Gigabit Ethernet */
|
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;
|
2012-05-04 16:56:18 +00:00
|
|
|
gint64 saved_offset;
|
wiretap: register most built-in file types from its module.
Remove most of the built-in file types from the table in
wiretap/file_access.c and, instead, have the file types register
themselves, using wtap_register_file_type_subtypes().
This reduces the source code changes needed to add a new file type from
three (add the handler, add the file type to the table in file_access.c,
add a #define for the file type in wiretap/wtap.h) to one (add the
handler). (It also requires adding the handler's source file to
wiretap/CMakeLists.txt, but that's required in both cases.)
A few remain because the WTAP_FILE_TYPE_SUBTYPE_ #define is used
elsewhere; that needs to be fixed.
Fix the wiretap/CMakefile.txt file to scan k12text.l, as that now
contains a registration routine. In the process, avoid scanning files
that don't implement a file type and won't ever have a registration
routine.
Add a Lua routine to fetch the total number of file types; we use that
in some code to construct the wtap_filetypes table, which we need to do
in order to continue to have all the values that used to come from the
WTAP_FILE_TYPE_SUBTYPE_ types.
While we're at it, add modelines to a file that lacked them.
2021-02-14 08:34:10 +00:00
|
|
|
snoop_t *snoop;
|
1998-11-15 05:29:17 +00:00
|
|
|
|
|
|
|
|
/* Read in the string that should be at the start of a "snoop" file */
|
Add some higher-level file-read APIs and use them.
Add wtap_read_bytes(), which takes a FILE_T, a pointer, a byte count, an
error number pointer, and an error string pointer as arguments, and that
treats a short read of any sort, including a read that returns 0 bytes,
as a WTAP_ERR_SHORT_READ error, and that returns the error number and
string through its last two arguments.
Add wtap_read_bytes_or_eof(), which is similar, but that treats a read
that returns 0 bytes as an EOF, supplying an error number of 0 as an EOF
indication.
Use those in file readers; that simplifies the code and makes it less
likely that somebody will fail to supply the error number and error
string on a file read error.
Change-Id: Ia5dba2a6f81151e87b614461349d611cffc16210
Reviewed-on: https://code.wireshark.org/review/4512
Reviewed-by: Guy Harris <guy@alum.mit.edu>
2014-10-07 01:00:57 +00:00
|
|
|
if (!wtap_read_bytes(wth->fh, magic, sizeof magic, err, err_info)) {
|
|
|
|
|
if (*err != WTAP_ERR_SHORT_READ)
|
2014-10-09 23:44:15 +00:00
|
|
|
return WTAP_OPEN_ERROR;
|
|
|
|
|
return WTAP_OPEN_NOT_MINE;
|
1998-11-15 05:29:17 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
if (memcmp(magic, snoop_magic, sizeof snoop_magic) != 0) {
|
2014-10-09 23:44:15 +00:00
|
|
|
return WTAP_OPEN_NOT_MINE;
|
1998-11-15 05:29:17 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* Read the rest of the header. */
|
Add some higher-level file-read APIs and use them.
Add wtap_read_bytes(), which takes a FILE_T, a pointer, a byte count, an
error number pointer, and an error string pointer as arguments, and that
treats a short read of any sort, including a read that returns 0 bytes,
as a WTAP_ERR_SHORT_READ error, and that returns the error number and
string through its last two arguments.
Add wtap_read_bytes_or_eof(), which is similar, but that treats a read
that returns 0 bytes as an EOF, supplying an error number of 0 as an EOF
indication.
Use those in file readers; that simplifies the code and makes it less
likely that somebody will fail to supply the error number and error
string on a file read error.
Change-Id: Ia5dba2a6f81151e87b614461349d611cffc16210
Reviewed-on: https://code.wireshark.org/review/4512
Reviewed-by: Guy Harris <guy@alum.mit.edu>
2014-10-07 01:00:57 +00:00
|
|
|
if (!wtap_read_bytes(wth->fh, &hdr, sizeof hdr, err, err_info))
|
2014-10-09 23:44:15 +00:00
|
|
|
return WTAP_OPEN_ERROR;
|
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;
|
2021-12-18 18:48:20 +00:00
|
|
|
*err_info = ws_strdup_printf("snoop: version %u unsupported", hdr.version);
|
2014-10-09 23:44:15 +00:00
|
|
|
return WTAP_OPEN_ERROR;
|
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
|
|
|
/*
|
|
|
|
|
* 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. */
|
2014-05-09 05:18:49 +00:00
|
|
|
saved_offset = file_tell(wth->fh);
|
Add some higher-level file-read APIs and use them.
Add wtap_read_bytes(), which takes a FILE_T, a pointer, a byte count, an
error number pointer, and an error string pointer as arguments, and that
treats a short read of any sort, including a read that returns 0 bytes,
as a WTAP_ERR_SHORT_READ error, and that returns the error number and
string through its last two arguments.
Add wtap_read_bytes_or_eof(), which is similar, but that treats a read
that returns 0 bytes as an EOF, supplying an error number of 0 as an EOF
indication.
Use those in file readers; that simplifies the code and makes it less
likely that somebody will fail to supply the error number and error
string on a file read error.
Change-Id: Ia5dba2a6f81151e87b614461349d611cffc16210
Reviewed-on: https://code.wireshark.org/review/4512
Reviewed-by: Guy Harris <guy@alum.mit.edu>
2014-10-07 01:00:57 +00:00
|
|
|
if (!wtap_read_bytes_or_eof(wth->fh, &rec_hdr, sizeof rec_hdr, err, err_info)) {
|
|
|
|
|
if (*err != 0)
|
2014-10-09 23:44:15 +00:00
|
|
|
return WTAP_OPEN_ERROR;
|
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.
|
|
|
|
|
*/
|
2014-05-09 05:18:49 +00:00
|
|
|
if (file_seek(wth->fh, saved_offset, SEEK_SET, err) == -1)
|
2014-10-09 23:44:15 +00:00
|
|
|
return WTAP_OPEN_ERROR;
|
2002-12-05 22:33:11 +00:00
|
|
|
|
|
|
|
|
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) {
|
2014-12-17 06:22:29 +00:00
|
|
|
*err = WTAP_ERR_UNSUPPORTED;
|
2021-12-18 18:48:20 +00:00
|
|
|
*err_info = ws_strdup_printf("snoop: Shomiti network type %u unknown or 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
|
|
|
hdr.network);
|
2014-10-09 23:44:15 +00:00
|
|
|
return WTAP_OPEN_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
|
|
|
}
|
|
|
|
|
file_encap = shomiti_encap[hdr.network];
|
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) {
|
2014-12-17 06:22:29 +00:00
|
|
|
*err = WTAP_ERR_UNSUPPORTED;
|
2021-12-18 18:48:20 +00:00
|
|
|
*err_info = ws_strdup_printf("snoop: private network type %u unknown or unsupported",
|
2009-12-03 15:27:39 +00:00
|
|
|
hdr.network);
|
2014-10-09 23:44:15 +00:00
|
|
|
return WTAP_OPEN_ERROR;
|
2009-12-03 15:27:39 +00:00
|
|
|
}
|
|
|
|
|
file_encap = snoop_private_encap[hdr.network^SNOOP_PRIVATE_BIT];
|
2002-12-05 22:33:11 +00:00
|
|
|
} else {
|
|
|
|
|
if (hdr.network >= NUM_SNOOP_ENCAPS
|
|
|
|
|
|| snoop_encap[hdr.network] == WTAP_ENCAP_UNKNOWN) {
|
2014-12-17 06:22:29 +00:00
|
|
|
*err = WTAP_ERR_UNSUPPORTED;
|
2021-12-18 18:48:20 +00:00
|
|
|
*err_info = ws_strdup_printf("snoop: network type %u unknown or 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
|
|
|
hdr.network);
|
2014-10-09 23:44:15 +00:00
|
|
|
return WTAP_OPEN_ERROR;
|
2002-12-05 22:33:11 +00:00
|
|
|
}
|
|
|
|
|
file_encap = snoop_encap[hdr.network];
|
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.
|
|
|
|
|
*/
|
wiretap: register most built-in file types from its module.
Remove most of the built-in file types from the table in
wiretap/file_access.c and, instead, have the file types register
themselves, using wtap_register_file_type_subtypes().
This reduces the source code changes needed to add a new file type from
three (add the handler, add the file type to the table in file_access.c,
add a #define for the file type in wiretap/wtap.h) to one (add the
handler). (It also requires adding the handler's source file to
wiretap/CMakeLists.txt, but that's required in both cases.)
A few remain because the WTAP_FILE_TYPE_SUBTYPE_ #define is used
elsewhere; that needs to be fixed.
Fix the wiretap/CMakefile.txt file to scan k12text.l, as that now
contains a registration routine. In the process, avoid scanning files
that don't implement a file type and won't ever have a registration
routine.
Add a Lua routine to fetch the total number of file types; we use that
in some code to construct the wtap_filetypes table, which we need to do
in order to continue to have all the values that used to come from the
WTAP_FILE_TYPE_SUBTYPE_ types.
While we're at it, add modelines to a file that lacked them.
2021-02-14 08:34:10 +00:00
|
|
|
wth->file_type_subtype = is_shomiti ? shomiti_file_type_subtype : snoop_file_type_subtype;
|
|
|
|
|
snoop = g_new0(snoop_t, 1);
|
|
|
|
|
wth->priv = (void *)snoop;
|
2014-05-09 05:18:49 +00:00
|
|
|
wth->subtype_read = snoop_read;
|
|
|
|
|
wth->subtype_seek_read = snoop_seek_read;
|
|
|
|
|
wth->file_encap = file_encap;
|
|
|
|
|
wth->snapshot_length = 0; /* not available in header */
|
2014-09-28 18:37:06 +00:00
|
|
|
wth->file_tsprec = WTAP_TSPREC_USEC;
|
wiretap: register most built-in file types from its module.
Remove most of the built-in file types from the table in
wiretap/file_access.c and, instead, have the file types register
themselves, using wtap_register_file_type_subtypes().
This reduces the source code changes needed to add a new file type from
three (add the handler, add the file type to the table in file_access.c,
add a #define for the file type in wiretap/wtap.h) to one (add the
handler). (It also requires adding the handler's source file to
wiretap/CMakeLists.txt, but that's required in both cases.)
A few remain because the WTAP_FILE_TYPE_SUBTYPE_ #define is used
elsewhere; that needs to be fixed.
Fix the wiretap/CMakefile.txt file to scan k12text.l, as that now
contains a registration routine. In the process, avoid scanning files
that don't implement a file type and won't ever have a registration
routine.
Add a Lua routine to fetch the total number of file types; we use that
in some code to construct the wtap_filetypes table, which we need to do
in order to continue to have all the values that used to come from the
WTAP_FILE_TYPE_SUBTYPE_ types.
While we're at it, add modelines to a file that lacked them.
2021-02-14 08:34:10 +00:00
|
|
|
snoop->is_shomiti = is_shomiti;
|
2020-07-29 08:30:54 +00:00
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* Add an IDB; we don't know how many interfaces were
|
|
|
|
|
* involved, so we just say one interface, about which
|
|
|
|
|
* we only know the link-layer type, snapshot length,
|
|
|
|
|
* and time stamp resolution.
|
|
|
|
|
*/
|
|
|
|
|
wtap_add_generated_idb(wth);
|
|
|
|
|
|
2014-10-09 23:44:15 +00:00
|
|
|
return WTAP_OPEN_MINE;
|
1998-11-15 05:29:17 +00:00
|
|
|
}
|
|
|
|
|
|
2021-03-05 04:40:30 +00:00
|
|
|
/*
|
|
|
|
|
* XXX - pad[3] is the length of the header, not including
|
|
|
|
|
* the length of the pad field; is it a 1-byte field, a 2-byte
|
|
|
|
|
* field with pad[2] usually being 0, a 3-byte field with
|
|
|
|
|
* pad[1] and pad[2] usually being 0, or a 4-byte field?
|
|
|
|
|
*
|
|
|
|
|
* If it's not a 4-byte field, is there anything significant
|
|
|
|
|
* in the other bytes?
|
|
|
|
|
*
|
|
|
|
|
* Can the header length ever be less than 8, so that not
|
|
|
|
|
* all the fields following pad are present?
|
|
|
|
|
*
|
|
|
|
|
* What's in undecrypt? In captures I've seen, undecrypt[0]
|
|
|
|
|
* is usually 0x00 but sometimes 0x02 or 0x06, and undecrypt[1]
|
|
|
|
|
* is either 0x00 or 0x02.
|
|
|
|
|
*
|
|
|
|
|
* What's in preamble? In captures I've seen, it's 0x00.
|
|
|
|
|
*
|
|
|
|
|
* What's in code? In captures I've seen, it's 0x01 or 0x03.
|
|
|
|
|
*
|
|
|
|
|
* If the header is longer than 8 bytes, what are the other fields?
|
|
|
|
|
*/
|
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 */
|
2019-04-05 01:56:27 +00:00
|
|
|
static gboolean snoop_read(wtap *wth, wtap_rec *rec, Buffer *buf,
|
|
|
|
|
int *err, gchar **err_info, gint64 *data_offset)
|
1998-11-15 05:29:17 +00:00
|
|
|
{
|
2013-06-17 21:18:47 +00:00
|
|
|
int padbytes;
|
2013-06-06 08:14:44 +00:00
|
|
|
|
2014-05-09 05:18:49 +00:00
|
|
|
*data_offset = file_tell(wth->fh);
|
2013-06-06 08:14:44 +00:00
|
|
|
|
2019-04-05 01:56:27 +00:00
|
|
|
padbytes = snoop_read_packet(wth, wth->fh, rec, buf, err, err_info);
|
2013-06-17 21:18:47 +00:00
|
|
|
if (padbytes == -1)
|
2014-05-23 10:50:02 +00:00
|
|
|
return FALSE;
|
2013-06-06 08:14:44 +00:00
|
|
|
|
|
|
|
|
/*
|
Add some higher-level file-read APIs and use them.
Add wtap_read_bytes(), which takes a FILE_T, a pointer, a byte count, an
error number pointer, and an error string pointer as arguments, and that
treats a short read of any sort, including a read that returns 0 bytes,
as a WTAP_ERR_SHORT_READ error, and that returns the error number and
string through its last two arguments.
Add wtap_read_bytes_or_eof(), which is similar, but that treats a read
that returns 0 bytes as an EOF, supplying an error number of 0 as an EOF
indication.
Use those in file readers; that simplifies the code and makes it less
likely that somebody will fail to supply the error number and error
string on a file read error.
Change-Id: Ia5dba2a6f81151e87b614461349d611cffc16210
Reviewed-on: https://code.wireshark.org/review/4512
Reviewed-by: Guy Harris <guy@alum.mit.edu>
2014-10-07 01:00:57 +00:00
|
|
|
* Skip over the padding, if any.
|
2013-06-06 08:14:44 +00:00
|
|
|
*/
|
Add some higher-level file-read APIs and use them.
Add wtap_read_bytes(), which takes a FILE_T, a pointer, a byte count, an
error number pointer, and an error string pointer as arguments, and that
treats a short read of any sort, including a read that returns 0 bytes,
as a WTAP_ERR_SHORT_READ error, and that returns the error number and
string through its last two arguments.
Add wtap_read_bytes_or_eof(), which is similar, but that treats a read
that returns 0 bytes as an EOF, supplying an error number of 0 as an EOF
indication.
Use those in file readers; that simplifies the code and makes it less
likely that somebody will fail to supply the error number and error
string on a file read error.
Change-Id: Ia5dba2a6f81151e87b614461349d611cffc16210
Reviewed-on: https://code.wireshark.org/review/4512
Reviewed-by: Guy Harris <guy@alum.mit.edu>
2014-10-07 01:00:57 +00:00
|
|
|
if (padbytes != 0) {
|
2016-09-28 23:45:23 +00:00
|
|
|
if (!wtap_read_bytes(wth->fh, NULL, padbytes, err, err_info))
|
2014-05-23 10:50:02 +00:00
|
|
|
return FALSE;
|
2013-06-06 08:14:44 +00:00
|
|
|
}
|
|
|
|
|
|
2014-05-23 10:50:02 +00:00
|
|
|
return TRUE;
|
2013-06-06 08:14:44 +00:00
|
|
|
}
|
|
|
|
|
|
2014-05-23 10:50:02 +00:00
|
|
|
static gboolean
|
2014-05-09 05:18:49 +00:00
|
|
|
snoop_seek_read(wtap *wth, gint64 seek_off,
|
2018-02-09 00:19:12 +00:00
|
|
|
wtap_rec *rec, Buffer *buf, int *err, gchar **err_info)
|
2013-06-06 08:14:44 +00:00
|
|
|
{
|
2014-05-09 05:18:49 +00:00
|
|
|
if (file_seek(wth->random_fh, seek_off, SEEK_SET, err) == -1)
|
2014-05-23 10:50:02 +00:00
|
|
|
return FALSE;
|
2013-06-06 08:14:44 +00:00
|
|
|
|
2018-02-09 00:19:12 +00:00
|
|
|
if (snoop_read_packet(wth, wth->random_fh, rec, buf, err, err_info) == -1) {
|
2013-06-17 21:18:47 +00:00
|
|
|
if (*err == 0)
|
|
|
|
|
*err = WTAP_ERR_SHORT_READ;
|
2014-05-23 10:50:02 +00:00
|
|
|
return FALSE;
|
2013-06-17 21:18:47 +00:00
|
|
|
}
|
2014-05-23 10:50:02 +00:00
|
|
|
return TRUE;
|
2013-06-06 08:14:44 +00:00
|
|
|
}
|
|
|
|
|
|
2013-06-17 21:18:47 +00:00
|
|
|
static int
|
2018-02-09 00:19:12 +00:00
|
|
|
snoop_read_packet(wtap *wth, FILE_T fh, wtap_rec *rec,
|
2013-06-17 21:18:47 +00:00
|
|
|
Buffer *buf, int *err, gchar **err_info)
|
2013-06-06 08:14:44 +00:00
|
|
|
{
|
wiretap: register most built-in file types from its module.
Remove most of the built-in file types from the table in
wiretap/file_access.c and, instead, have the file types register
themselves, using wtap_register_file_type_subtypes().
This reduces the source code changes needed to add a new file type from
three (add the handler, add the file type to the table in file_access.c,
add a #define for the file type in wiretap/wtap.h) to one (add the
handler). (It also requires adding the handler's source file to
wiretap/CMakeLists.txt, but that's required in both cases.)
A few remain because the WTAP_FILE_TYPE_SUBTYPE_ #define is used
elsewhere; that needs to be fixed.
Fix the wiretap/CMakefile.txt file to scan k12text.l, as that now
contains a registration routine. In the process, avoid scanning files
that don't implement a file type and won't ever have a registration
routine.
Add a Lua routine to fetch the total number of file types; we use that
in some code to construct the wtap_filetypes table, which we need to do
in order to continue to have all the values that used to come from the
WTAP_FILE_TYPE_SUBTYPE_ types.
While we're at it, add modelines to a file that lacked them.
2021-02-14 08:34:10 +00:00
|
|
|
snoop_t *snoop = (snoop_t *)wth->priv;
|
2013-06-06 08:14:44 +00:00
|
|
|
struct snooprec_hdr hdr;
|
|
|
|
|
guint32 rec_size;
|
|
|
|
|
guint32 packet_size;
|
|
|
|
|
guint32 orig_size;
|
2009-09-17 02:12:08 +00:00
|
|
|
int header_size;
|
1998-11-15 05:29:17 +00:00
|
|
|
|
|
|
|
|
/* Read record header. */
|
Add some higher-level file-read APIs and use them.
Add wtap_read_bytes(), which takes a FILE_T, a pointer, a byte count, an
error number pointer, and an error string pointer as arguments, and that
treats a short read of any sort, including a read that returns 0 bytes,
as a WTAP_ERR_SHORT_READ error, and that returns the error number and
string through its last two arguments.
Add wtap_read_bytes_or_eof(), which is similar, but that treats a read
that returns 0 bytes as an EOF, supplying an error number of 0 as an EOF
indication.
Use those in file readers; that simplifies the code and makes it less
likely that somebody will fail to supply the error number and error
string on a file read error.
Change-Id: Ia5dba2a6f81151e87b614461349d611cffc16210
Reviewed-on: https://code.wireshark.org/review/4512
Reviewed-by: Guy Harris <guy@alum.mit.edu>
2014-10-07 01:00:57 +00:00
|
|
|
if (!wtap_read_bytes_or_eof(fh, &hdr, sizeof hdr, err, err_info))
|
2013-06-17 21:18:47 +00:00
|
|
|
return -1;
|
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);
|
Allow bigger snapshot lengths for D-Bus captures.
Use WTAP_MAX_PACKET_SIZE_STANDARD, set to 256KB, for everything except
for D-Bus captures. Use WTAP_MAX_PACKET_SIZE_DBUS, set to 128MB, for
them, because that's the largest possible D-Bus message size. See
https://bugs.freedesktop.org/show_bug.cgi?id=100220
for an example of the problems caused by limiting the snapshot length to
256KB for D-Bus.
Have a snapshot length of 0 in a capture_file structure mean "there is
no snapshot length for the file"; we don't need the has_snap field in
that case, a value of 0 mean "no, we don't have a snapshot length".
In dumpcap, start out with a pipe buffer size of 2KB, and grow it as
necessary. When checking for a too-big packet from a pipe, check
against the appropriate maximum - 128MB for DLT_DBUS, 256KB for
everything else.
Change-Id: Ib2ce7a0cf37b971fbc0318024fd011e18add8b20
Reviewed-on: https://code.wireshark.org/review/21952
Petri-Dish: Guy Harris <guy@alum.mit.edu>
Tested-by: Petri Dish Buildbot <buildbot-no-reply@wireshark.org>
Reviewed-by: Guy Harris <guy@alum.mit.edu>
2017-06-05 01:58:40 +00:00
|
|
|
if (orig_size > WTAP_MAX_PACKET_SIZE_STANDARD) {
|
2011-05-11 22:36:59 +00:00
|
|
|
/*
|
|
|
|
|
* Probably a corrupt capture file; don't blow up trying
|
|
|
|
|
* to allocate space for an immensely-large packet.
|
|
|
|
|
*/
|
2011-12-13 09:53:50 +00:00
|
|
|
*err = WTAP_ERR_BAD_FILE;
|
2021-12-18 18:48:20 +00:00
|
|
|
*err_info = ws_strdup_printf("snoop: File has %u-byte original length, bigger than maximum of %u",
|
Allow bigger snapshot lengths for D-Bus captures.
Use WTAP_MAX_PACKET_SIZE_STANDARD, set to 256KB, for everything except
for D-Bus captures. Use WTAP_MAX_PACKET_SIZE_DBUS, set to 128MB, for
them, because that's the largest possible D-Bus message size. See
https://bugs.freedesktop.org/show_bug.cgi?id=100220
for an example of the problems caused by limiting the snapshot length to
256KB for D-Bus.
Have a snapshot length of 0 in a capture_file structure mean "there is
no snapshot length for the file"; we don't need the has_snap field in
that case, a value of 0 mean "no, we don't have a snapshot length".
In dumpcap, start out with a pipe buffer size of 2KB, and grow it as
necessary. When checking for a too-big packet from a pipe, check
against the appropriate maximum - 128MB for DLT_DBUS, 256KB for
everything else.
Change-Id: Ib2ce7a0cf37b971fbc0318024fd011e18add8b20
Reviewed-on: https://code.wireshark.org/review/21952
Petri-Dish: Guy Harris <guy@alum.mit.edu>
Tested-by: Petri Dish Buildbot <buildbot-no-reply@wireshark.org>
Reviewed-by: Guy Harris <guy@alum.mit.edu>
2017-06-05 01:58:40 +00:00
|
|
|
orig_size, WTAP_MAX_PACKET_SIZE_STANDARD);
|
2013-06-17 21:18:47 +00:00
|
|
|
return -1;
|
2011-05-11 22:36:59 +00:00
|
|
|
}
|
Allow bigger snapshot lengths for D-Bus captures.
Use WTAP_MAX_PACKET_SIZE_STANDARD, set to 256KB, for everything except
for D-Bus captures. Use WTAP_MAX_PACKET_SIZE_DBUS, set to 128MB, for
them, because that's the largest possible D-Bus message size. See
https://bugs.freedesktop.org/show_bug.cgi?id=100220
for an example of the problems caused by limiting the snapshot length to
256KB for D-Bus.
Have a snapshot length of 0 in a capture_file structure mean "there is
no snapshot length for the file"; we don't need the has_snap field in
that case, a value of 0 mean "no, we don't have a snapshot length".
In dumpcap, start out with a pipe buffer size of 2KB, and grow it as
necessary. When checking for a too-big packet from a pipe, check
against the appropriate maximum - 128MB for DLT_DBUS, 256KB for
everything else.
Change-Id: Ib2ce7a0cf37b971fbc0318024fd011e18add8b20
Reviewed-on: https://code.wireshark.org/review/21952
Petri-Dish: Guy Harris <guy@alum.mit.edu>
Tested-by: Petri Dish Buildbot <buildbot-no-reply@wireshark.org>
Reviewed-by: Guy Harris <guy@alum.mit.edu>
2017-06-05 01:58:40 +00:00
|
|
|
if (packet_size > WTAP_MAX_PACKET_SIZE_STANDARD) {
|
1999-08-22 02:29:40 +00:00
|
|
|
/*
|
|
|
|
|
* Probably a corrupt capture file; don't blow up trying
|
|
|
|
|
* to allocate space for an immensely-large packet.
|
|
|
|
|
*/
|
2011-12-13 09:53:50 +00:00
|
|
|
*err = WTAP_ERR_BAD_FILE;
|
2021-12-18 18:48:20 +00:00
|
|
|
*err_info = ws_strdup_printf("snoop: File has %u-byte packet, bigger than maximum of %u",
|
Allow bigger snapshot lengths for D-Bus captures.
Use WTAP_MAX_PACKET_SIZE_STANDARD, set to 256KB, for everything except
for D-Bus captures. Use WTAP_MAX_PACKET_SIZE_DBUS, set to 128MB, for
them, because that's the largest possible D-Bus message size. See
https://bugs.freedesktop.org/show_bug.cgi?id=100220
for an example of the problems caused by limiting the snapshot length to
256KB for D-Bus.
Have a snapshot length of 0 in a capture_file structure mean "there is
no snapshot length for the file"; we don't need the has_snap field in
that case, a value of 0 mean "no, we don't have a snapshot length".
In dumpcap, start out with a pipe buffer size of 2KB, and grow it as
necessary. When checking for a too-big packet from a pipe, check
against the appropriate maximum - 128MB for DLT_DBUS, 256KB for
everything else.
Change-Id: Ib2ce7a0cf37b971fbc0318024fd011e18add8b20
Reviewed-on: https://code.wireshark.org/review/21952
Petri-Dish: Guy Harris <guy@alum.mit.edu>
Tested-by: Petri Dish Buildbot <buildbot-no-reply@wireshark.org>
Reviewed-by: Guy Harris <guy@alum.mit.edu>
2017-06-05 01:58:40 +00:00
|
|
|
packet_size, WTAP_MAX_PACKET_SIZE_STANDARD);
|
2013-06-17 21:18:47 +00:00
|
|
|
return -1;
|
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.
|
|
|
|
|
*/
|
2011-12-13 09:53:50 +00:00
|
|
|
*err = WTAP_ERR_BAD_FILE;
|
2021-12-18 18:48:20 +00:00
|
|
|
*err_info = ws_strdup_printf("snoop: File has %u-byte packet, bigger than record size %u",
|
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, rec_size);
|
2013-06-17 21:18:47 +00:00
|
|
|
return -1;
|
2003-12-19 22:23:05 +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
|
|
|
|
2014-05-09 05:18:49 +00:00
|
|
|
switch (wth->file_encap) {
|
2003-10-01 07:11:49 +00:00
|
|
|
|
|
|
|
|
case WTAP_ENCAP_ATM_PDUS:
|
2013-06-06 08:14:44 +00:00
|
|
|
/*
|
|
|
|
|
* This is an ATM packet, so 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.
|
|
|
|
|
*/
|
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.
|
|
|
|
|
*/
|
2011-12-13 09:53:50 +00:00
|
|
|
*err = WTAP_ERR_BAD_FILE;
|
2021-12-18 18:48:20 +00:00
|
|
|
*err_info = ws_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);
|
2013-06-17 21:18:47 +00:00
|
|
|
return -1;
|
Move the "guess what type of ATM traffic this is" stuff into the ATM
dissector; I don't think it's guaranteed that even a Sniffer will tell
you that (there may be situations where it can't figure it out, and
where the user didn't tell it), we may need it for "atmsnoop" traffic
and other types of ATM traffic as well, we will probably want to add to
it the ability to let the user specify "virtual circuit X.Y is this kind
of traffic", and we may also have Ethereal try to intuit it based on
previous traffic in the capture (Q.2931 call setup, LANE traffic, etc.).
Don't show the cell count if it's zero - assume that means we don't know
how many cells made up the packet. Also don't show the AAL5 trailer if
the cell count is zero - the ATM Sniffer *might* sometimes supply a cell
count of 0 even if it has the AAL5 trailer, I guess, and we *might* see
some other capture file format that has the AAL5 trailer but no cell
count, but we'll cross that bridge when we come to it.
Add support for "atmsnoop" captures to the code to handle "snoop"
captures.
Use the field in "iptrace" headers that appears to be, in ATM captures,
a direction indicator - we may have the direction backwards, but, as an
STP packet was tagged as a DCE->DTE packet, and as the capturing
machine, which also was presumably the recipient of the packet, was an
AIX box, not a switch or bridge or some piece of networking equipment
such as that, it *probably* wasn't sending the STP packet, it was
probably receiving it.
svn path=/trunk/; revision=1120
1999-11-27 01:55:44 +00:00
|
|
|
}
|
2018-02-09 00:19:12 +00:00
|
|
|
if (!snoop_read_atm_pseudoheader(fh, &rec->rec_header.packet_header.pseudo_header,
|
2011-04-21 09:41:52 +00:00
|
|
|
err, err_info))
|
2013-06-17 21:18:47 +00:00
|
|
|
return -1; /* Read error */
|
Move the "guess what type of ATM traffic this is" stuff into the ATM
dissector; I don't think it's guaranteed that even a Sniffer will tell
you that (there may be situations where it can't figure it out, and
where the user didn't tell it), we may need it for "atmsnoop" traffic
and other types of ATM traffic as well, we will probably want to add to
it the ability to let the user specify "virtual circuit X.Y is this kind
of traffic", and we may also have Ethereal try to intuit it based on
previous traffic in the capture (Q.2931 call setup, LANE traffic, etc.).
Don't show the cell count if it's zero - assume that means we don't know
how many cells made up the packet. Also don't show the AAL5 trailer if
the cell count is zero - the ATM Sniffer *might* sometimes supply a cell
count of 0 even if it has the AAL5 trailer, I guess, and we *might* see
some other capture file format that has the AAL5 trailer but no cell
count, but we'll cross that bridge when we come to it.
Add support for "atmsnoop" captures to the code to handle "snoop"
captures.
Use the field in "iptrace" headers that appears to be, in ATM captures,
a direction indicator - we may have the direction backwards, but, as an
STP packet was tagged as a DCE->DTE packet, and as the capturing
machine, which also was presumably the recipient of the packet, was an
AIX box, not a switch or bridge or some piece of networking equipment
such as that, it *probably* wasn't sending the STP packet, it was
probably receiving it.
svn path=/trunk/; revision=1120
1999-11-27 01:55:44 +00:00
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* Don't count the pseudo-header as part of the packet.
|
|
|
|
|
*/
|
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);
|
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"?)
|
|
|
|
|
*/
|
wiretap: register most built-in file types from its module.
Remove most of the built-in file types from the table in
wiretap/file_access.c and, instead, have the file types register
themselves, using wtap_register_file_type_subtypes().
This reduces the source code changes needed to add a new file type from
three (add the handler, add the file type to the table in file_access.c,
add a #define for the file type in wiretap/wtap.h) to one (add the
handler). (It also requires adding the handler's source file to
wiretap/CMakeLists.txt, but that's required in both cases.)
A few remain because the WTAP_FILE_TYPE_SUBTYPE_ #define is used
elsewhere; that needs to be fixed.
Fix the wiretap/CMakefile.txt file to scan k12text.l, as that now
contains a registration routine. In the process, avoid scanning files
that don't implement a file type and won't ever have a registration
routine.
Add a Lua routine to fetch the total number of file types; we use that
in some code to construct the wtap_filetypes table, which we need to do
in order to continue to have all the values that used to come from the
WTAP_FILE_TYPE_SUBTYPE_ types.
While we're at it, add modelines to a file that lacked them.
2021-02-14 08:34:10 +00:00
|
|
|
if (snoop->is_shomiti)
|
2018-02-09 00:19:12 +00:00
|
|
|
rec->rec_header.packet_header.pseudo_header.eth.fcs_len = 4;
|
2003-10-01 07:11:49 +00:00
|
|
|
else
|
2018-02-09 00:19:12 +00:00
|
|
|
rec->rec_header.packet_header.pseudo_header.eth.fcs_len = 0;
|
2003-10-01 07:11:49 +00:00
|
|
|
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.
|
|
|
|
|
*/
|
2011-12-13 09:53:50 +00:00
|
|
|
*err = WTAP_ERR_BAD_FILE;
|
2021-12-18 18:48:20 +00:00
|
|
|
*err_info = ws_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);
|
2013-06-17 21:18:47 +00:00
|
|
|
return -1;
|
2007-01-18 12:19:17 +00:00
|
|
|
}
|
2013-06-06 08:14:44 +00:00
|
|
|
if (!snoop_read_shomiti_wireless_pseudoheader(fh,
|
2018-02-09 00:19:12 +00:00
|
|
|
&rec->rec_header.packet_header.pseudo_header, err, err_info, &header_size))
|
2013-06-17 21:18:47 +00:00
|
|
|
return -1; /* Read error */
|
2007-01-18 12:19:17 +00:00
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* 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;
|
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
|
|
|
}
|
|
|
|
|
|
2018-02-09 00:19:12 +00:00
|
|
|
rec->rec_type = REC_TYPE_PACKET;
|
2021-08-30 02:12:13 +00:00
|
|
|
rec->block = wtap_block_create(WTAP_BLOCK_PACKET);
|
2018-02-09 00:19:12 +00:00
|
|
|
rec->presence_flags = WTAP_HAS_TS|WTAP_HAS_CAP_LEN;
|
|
|
|
|
rec->ts.secs = g_ntohl(hdr.ts_sec);
|
|
|
|
|
rec->ts.nsecs = g_ntohl(hdr.ts_usec) * 1000;
|
|
|
|
|
rec->rec_header.packet_header.caplen = packet_size;
|
|
|
|
|
rec->rec_header.packet_header.len = orig_size;
|
2002-04-30 18:58:16 +00:00
|
|
|
|
2003-11-04 22:14:50 +00:00
|
|
|
if (rec_size < (sizeof hdr + packet_size)) {
|
|
|
|
|
/*
|
|
|
|
|
* What, *negative* padding? Bogus.
|
|
|
|
|
*/
|
2011-12-13 09:53:50 +00:00
|
|
|
*err = WTAP_ERR_BAD_FILE;
|
2021-12-18 18:48:20 +00:00
|
|
|
*err_info = ws_strdup_printf("snoop: File has %u-byte record with packet size of %u",
|
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
|
|
|
rec_size, packet_size);
|
2013-06-17 21:18:47 +00:00
|
|
|
return -1;
|
2003-11-04 22:14:50 +00:00
|
|
|
}
|
2013-06-17 21:18:47 +00:00
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* Read the packet data.
|
|
|
|
|
*/
|
|
|
|
|
if (!wtap_read_packet_bytes(fh, buf, packet_size, err, err_info))
|
|
|
|
|
return -1; /* failed */
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* If this is ATM LANE traffic, try to guess what type of LANE
|
|
|
|
|
* traffic it is based on the packet contents.
|
|
|
|
|
*/
|
2014-05-09 05:18:49 +00:00
|
|
|
if (wth->file_encap == WTAP_ENCAP_ATM_PDUS &&
|
2018-02-09 00:19:12 +00:00
|
|
|
rec->rec_header.packet_header.pseudo_header.atm.type == TRAF_LANE) {
|
|
|
|
|
atm_guess_lane_type(rec, ws_buffer_start_ptr(buf));
|
2013-06-17 21:18:47 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
return rec_size - ((guint)sizeof hdr + packet_size);
|
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,
|
2011-04-21 09:41:52 +00:00
|
|
|
int *err, gchar **err_info)
|
2000-05-18 09:09:50 +00:00
|
|
|
{
|
2002-04-30 09:23:29 +00:00
|
|
|
struct snoop_atm_hdr atm_phdr;
|
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
|
|
|
|
Add some higher-level file-read APIs and use them.
Add wtap_read_bytes(), which takes a FILE_T, a pointer, a byte count, an
error number pointer, and an error string pointer as arguments, and that
treats a short read of any sort, including a read that returns 0 bytes,
as a WTAP_ERR_SHORT_READ error, and that returns the error number and
string through its last two arguments.
Add wtap_read_bytes_or_eof(), which is similar, but that treats a read
that returns 0 bytes as an EOF, supplying an error number of 0 as an EOF
indication.
Use those in file readers; that simplifies the code and makes it less
likely that somebody will fail to supply the error number and error
string on a file read error.
Change-Id: Ia5dba2a6f81151e87b614461349d611cffc16210
Reviewed-on: https://code.wireshark.org/review/4512
Reviewed-by: Guy Harris <guy@alum.mit.edu>
2014-10-07 01:00:57 +00:00
|
|
|
if (!wtap_read_bytes(fh, &atm_phdr, sizeof atm_phdr, err, err_info))
|
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;
|
2013-12-03 20:35:50 +00:00
|
|
|
vci = pntoh16(&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;
|
2009-09-17 02:42:31 +00:00
|
|
|
int rsize;
|
2007-01-18 12:19:17 +00:00
|
|
|
|
Add some higher-level file-read APIs and use them.
Add wtap_read_bytes(), which takes a FILE_T, a pointer, a byte count, an
error number pointer, and an error string pointer as arguments, and that
treats a short read of any sort, including a read that returns 0 bytes,
as a WTAP_ERR_SHORT_READ error, and that returns the error number and
string through its last two arguments.
Add wtap_read_bytes_or_eof(), which is similar, but that treats a read
that returns 0 bytes as an EOF, supplying an error number of 0 as an EOF
indication.
Use those in file readers; that simplifies the code and makes it less
likely that somebody will fail to supply the error number and error
string on a file read error.
Change-Id: Ia5dba2a6f81151e87b614461349d611cffc16210
Reviewed-on: https://code.wireshark.org/review/4512
Reviewed-by: Guy Harris <guy@alum.mit.edu>
2014-10-07 01:00:57 +00:00
|
|
|
if (!wtap_read_bytes(fh, &whdr, sizeof whdr, err, err_info))
|
2007-01-18 12:19:17 +00:00
|
|
|
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.
|
2009-09-17 02:12:08 +00:00
|
|
|
*/
|
2009-09-17 02:42:31 +00:00
|
|
|
if (whdr.pad[3] < 8) {
|
2011-12-13 09:53:50 +00:00
|
|
|
*err = WTAP_ERR_BAD_FILE;
|
2021-12-18 18:48:20 +00:00
|
|
|
*err_info = ws_strdup_printf("snoop: Header length in Surveyor record is %u, less than minimum of 8",
|
2009-09-17 02:42:31 +00:00
|
|
|
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;
|
2016-09-29 04:35:12 +00:00
|
|
|
if (!wtap_read_bytes(fh, NULL, rsize, err, err_info))
|
2009-09-17 02:42:31 +00:00
|
|
|
return FALSE;
|
2009-09-17 02:12:08 +00:00
|
|
|
|
2015-12-09 22:26:46 +00:00
|
|
|
memset(&pseudo_header->ieee_802_11, 0, sizeof(pseudo_header->ieee_802_11));
|
2015-06-20 22:57:57 +00:00
|
|
|
pseudo_header->ieee_802_11.fcs_len = 4;
|
|
|
|
|
pseudo_header->ieee_802_11.decrypted = FALSE;
|
|
|
|
|
pseudo_header->ieee_802_11.datapad = FALSE;
|
Clean up 802.11 radio information handling.
Have a field that holds the PHY type but nothing else. Have
a union with structures holding PHY-type-specific information, as a
bunch of attributes are PHY-specific.
If we have a channel and band, but don't have the frequency, attempt to
calculate the frequency, and add that to the radio information if we
succeed. If we have the frequency, but don't have the channel, attempt
to calculate the channel, and add that to the radio information if we
succeed.
Handle FHSS information, 11a "half/quarter-clocked" and turbo
information, 11g normal vs. Super G, additional 11n and 11ac
information, and the "short preamble" flag for 11b and 11g.
Add a PHY type for 11 legacy DSSS and detect it if possible.
Clean up the AVS dissector - make all fields wlancap. fields (if you
want generic fields, use the wlan_radio. fields).
Set more fields when writing out Commview Wi-Fi files.
Change-Id: I691ac59f5e9e1a23779b56a65124049914b72e69
Reviewed-on: https://code.wireshark.org/review/9146
Reviewed-by: Guy Harris <guy@alum.mit.edu>
2015-06-25 19:14:39 +00:00
|
|
|
pseudo_header->ieee_802_11.phy = PHDR_802_11_PHY_UNKNOWN;
|
2015-12-09 22:26:46 +00:00
|
|
|
pseudo_header->ieee_802_11.has_channel = TRUE;
|
2007-01-18 12:19:17 +00:00
|
|
|
pseudo_header->ieee_802_11.channel = whdr.channel;
|
2015-12-09 22:26:46 +00:00
|
|
|
pseudo_header->ieee_802_11.has_data_rate = TRUE;
|
2007-01-18 12:19:17 +00:00
|
|
|
pseudo_header->ieee_802_11.data_rate = whdr.rate;
|
2015-12-09 22:26:46 +00:00
|
|
|
pseudo_header->ieee_802_11.has_signal_percent = TRUE;
|
2014-10-29 23:03:08 +00:00
|
|
|
pseudo_header->ieee_802_11.signal_percent = whdr.signal;
|
2007-01-18 12:19:17 +00:00
|
|
|
|
2021-03-10 09:42:51 +00:00
|
|
|
/*
|
|
|
|
|
* We don't know they PHY, but we do have the data rate;
|
|
|
|
|
* try to guess the PHY based on the data rate and channel.
|
|
|
|
|
*/
|
|
|
|
|
if (RATE_IS_DSSS(pseudo_header->ieee_802_11.data_rate)) {
|
|
|
|
|
/* 11b */
|
|
|
|
|
pseudo_header->ieee_802_11.phy = PHDR_802_11_PHY_11B;
|
|
|
|
|
pseudo_header->ieee_802_11.phy_info.info_11b.has_short_preamble = FALSE;
|
|
|
|
|
} else if (RATE_IS_OFDM(pseudo_header->ieee_802_11.data_rate)) {
|
|
|
|
|
/* 11a or 11g, depending on the band. */
|
|
|
|
|
if (CHAN_IS_BG(pseudo_header->ieee_802_11.channel)) {
|
|
|
|
|
/* 11g */
|
|
|
|
|
pseudo_header->ieee_802_11.phy = PHDR_802_11_PHY_11G;
|
|
|
|
|
pseudo_header->ieee_802_11.phy_info.info_11g.has_mode = FALSE;
|
|
|
|
|
} else {
|
|
|
|
|
/* 11a */
|
|
|
|
|
pseudo_header->ieee_802_11.phy = PHDR_802_11_PHY_11A;
|
|
|
|
|
pseudo_header->ieee_802_11.phy_info.info_11a.has_channel_type = FALSE;
|
|
|
|
|
pseudo_header->ieee_802_11.phy_info.info_11a.has_turbo_type = FALSE;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2009-09-17 02:12:08 +00:00
|
|
|
/* add back the header and don't forget the pad as well */
|
2013-06-06 08:14:44 +00:00
|
|
|
*header_size = rsize + 8 + 4;
|
2009-09-17 02:12:08 +00:00
|
|
|
|
2013-06-06 08:14:44 +00:00
|
|
|
return TRUE;
|
2007-01-18 12:19:17 +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 */
|
2011-12-22 09:22:35 +00:00
|
|
|
-1, /* WTAP_ENCAP_ARCNET_LINUX -> unsupported */
|
1999-12-04 08:32:14 +00:00
|
|
|
-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 */
|
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. */
|
2021-04-16 18:24:52 +00:00
|
|
|
static 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)
|
2014-12-17 06:40:45 +00:00
|
|
|
return WTAP_ERR_UNWRITABLE_ENCAP;
|
1999-12-04 08:32:14 +00:00
|
|
|
|
|
|
|
|
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 */
|
2021-04-16 18:24:52 +00:00
|
|
|
static gboolean snoop_dump_open(wtap_dumper *wdh, int *err, gchar **err_info _U_)
|
1999-12-04 03:36:22 +00:00
|
|
|
{
|
|
|
|
|
struct snoop_hdr file_hdr;
|
|
|
|
|
|
|
|
|
|
/* This is a snoop file */
|
|
|
|
|
wdh->subtype_write = snoop_dump;
|
|
|
|
|
|
|
|
|
|
/* Write the file header. */
|
2014-05-09 05:18:49 +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]);
|
2014-05-09 05:18:49 +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. */
|
2014-05-09 05:18:49 +00:00
|
|
|
static gboolean snoop_dump(wtap_dumper *wdh,
|
2018-02-09 00:19:12 +00:00
|
|
|
const wtap_rec *rec,
|
2014-12-18 00:02:50 +00:00
|
|
|
const guint8 *pd, int *err, gchar **err_info _U_)
|
1999-12-04 03:36:22 +00:00
|
|
|
{
|
2018-02-09 00:19:12 +00:00
|
|
|
const union wtap_pseudo_header *pseudo_header = &rec->rec_header.packet_header.pseudo_header;
|
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;
|
2013-07-29 07:54:24 +00:00
|
|
|
static const char zeroes[4] = {0};
|
2002-04-30 09:23:29 +00:00
|
|
|
struct snoop_atm_hdr atm_hdr;
|
|
|
|
|
int atm_hdrsize;
|
|
|
|
|
|
2014-05-24 18:28:30 +00:00
|
|
|
/* We can only write packet records. */
|
2018-02-09 00:19:12 +00:00
|
|
|
if (rec->rec_type != REC_TYPE_PACKET) {
|
2014-12-18 00:31:49 +00:00
|
|
|
*err = WTAP_ERR_UNWRITABLE_REC_TYPE;
|
2014-05-24 18:28:30 +00:00
|
|
|
return FALSE;
|
|
|
|
|
}
|
|
|
|
|
|
Catch attempts to write multiple encapsulation types if unsupported.
If, in the process of opening the input file, we determine that it has
packets of more than one link-layer type, we can catch attempts to write
that file to a file of a format that doesn't support more than one
link-layer type at the time we try to open the output file.
If, however, we don't discover that the file has more than one
link-layer type until we've already created the output file - for
example, if we have a pcapng file with a new IDB, with a different
link-layer type from previous IDBs, after packet blocks for the earlier
interfces - we can't catch that until we try to write the packet.
Currently, that causes the packet's data to be written out as is, so the
output file claims it's of the file's link-layer type, causing programs
reading the file to misdissect the packet.
Report WTAP_ERR_ENCAP_PER_PACKET_UNSUPPORTED on the write attempt
instead, and have a nicer error message for
WTAP_ERR_ENCAP_PER_PACKET_UNSUPPORTED on a write.
Change-Id: Ic41f2e4367cfe5667eb30c88cc6d3bfe422462f6
Reviewed-on: https://code.wireshark.org/review/30617
Reviewed-by: Guy Harris <guy@alum.mit.edu>
2018-11-14 03:38:12 +00:00
|
|
|
/*
|
|
|
|
|
* Make sure this packet doesn't have a link-layer type that
|
|
|
|
|
* differs from the one for the file.
|
|
|
|
|
*/
|
|
|
|
|
if (wdh->encap != rec->rec_header.packet_header.pkt_encap) {
|
|
|
|
|
*err = WTAP_ERR_ENCAP_PER_PACKET_UNSUPPORTED;
|
|
|
|
|
return FALSE;
|
|
|
|
|
}
|
|
|
|
|
|
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... */
|
2018-02-09 00:19:12 +00:00
|
|
|
reclen = (int)sizeof rec_hdr + rec->rec_header.packet_header.caplen + atm_hdrsize;
|
1999-12-04 03:36:22 +00:00
|
|
|
|
2014-01-22 00:26:36 +00:00
|
|
|
|
1999-12-04 03:36:22 +00:00
|
|
|
/* ... plus enough bytes to pad it to a 4-byte boundary. */
|
2021-06-16 09:01:23 +00:00
|
|
|
padlen = WS_ROUNDUP_4(reclen) - reclen;
|
1999-12-04 03:36:22 +00:00
|
|
|
reclen += padlen;
|
|
|
|
|
|
2014-01-22 00:26:36 +00:00
|
|
|
/* Don't write anything we're not willing to read. */
|
2018-02-09 00:19:12 +00:00
|
|
|
if (rec->rec_header.packet_header.caplen + atm_hdrsize > WTAP_MAX_PACKET_SIZE_STANDARD) {
|
2014-01-22 00:26:36 +00:00
|
|
|
*err = WTAP_ERR_PACKET_TOO_LARGE;
|
|
|
|
|
return FALSE;
|
|
|
|
|
}
|
|
|
|
|
|
2018-02-09 00:19:12 +00:00
|
|
|
rec_hdr.orig_len = g_htonl(rec->rec_header.packet_header.len + atm_hdrsize);
|
|
|
|
|
rec_hdr.incl_len = g_htonl(rec->rec_header.packet_header.caplen + atm_hdrsize);
|
2002-07-29 06:09:59 +00:00
|
|
|
rec_hdr.rec_len = g_htonl(reclen);
|
1999-12-04 03:36:22 +00:00
|
|
|
rec_hdr.cum_drops = 0;
|
2018-02-09 00:19:12 +00:00
|
|
|
rec_hdr.ts_sec = g_htonl(rec->ts.secs);
|
|
|
|
|
rec_hdr.ts_usec = g_htonl(rec->ts.nsecs / 1000);
|
2014-05-09 05:18:49 +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);
|
2014-05-09 05:18:49 +00:00
|
|
|
if (!wtap_dump_file_write(wdh, &atm_hdr, sizeof atm_hdr, err))
|
2002-04-30 09:23:29 +00:00
|
|
|
return FALSE;
|
|
|
|
|
}
|
|
|
|
|
|
2018-02-09 00:19:12 +00:00
|
|
|
if (!wtap_dump_file_write(wdh, pd, rec->rec_header.packet_header.caplen, err))
|
1999-12-04 05:14:39 +00:00
|
|
|
return FALSE;
|
1999-12-04 03:36:22 +00:00
|
|
|
|
|
|
|
|
/* Now write the padding. */
|
2014-05-09 05:18:49 +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
|
|
|
}
|
2015-01-02 00:45:22 +00:00
|
|
|
|
wiretap: have file handlers advertise blocks and options supported.
Instead of a "supports name resolution" Boolean and bitflags for types of
comments supported, provide a list of block types that the file
type/subtype supports, with each block type having a list of options
supported. Indicate whether "supported" means "one instance" or
"multiple instances".
"Supports" doesn't just mean "can be written", it also means "could be
read".
Rename WTAP_BLOCK_IF_DESCRIPTION to WTAP_BLOCK_IF_ID_AND_INFO, to
indicate that it provides, in addition to information about the
interface, an ID (implicitly, in pcapng files, by its ordinal number)
that is associated with every packet in the file. Emphasize that in
comments - just because your capture file format can list the interfaces
on which a capture was done, that doesn't mean it supports this; it
doesn't do so if the file doesn't indicate, for every packet, on which
of those interfaces it was captured (I'm looking at *you*, Microsoft
Network Monitor...).
Use APIs to query that information to do what the "does this file
type/subtype support name resolution information", "does this file
type/subtype support all of these comment types", and "does this file
type/subtype support - and require - interface IDs" APIs did.
Provide backwards compatibility for Lua.
This allows us to eliminate the WTAP_FILE_TYPE_SUBTYPE_ values for IBM's
iptrace; do so.
2021-02-21 22:18:04 +00:00
|
|
|
static const struct supported_block_type snoop_blocks_supported[] = {
|
|
|
|
|
/*
|
|
|
|
|
* We support packet blocks, with no comments or other options.
|
|
|
|
|
*/
|
|
|
|
|
{ WTAP_BLOCK_PACKET, MULTIPLE_BLOCKS_SUPPORTED, NO_OPTIONS_SUPPORTED }
|
|
|
|
|
};
|
|
|
|
|
|
wiretap: register most built-in file types from its module.
Remove most of the built-in file types from the table in
wiretap/file_access.c and, instead, have the file types register
themselves, using wtap_register_file_type_subtypes().
This reduces the source code changes needed to add a new file type from
three (add the handler, add the file type to the table in file_access.c,
add a #define for the file type in wiretap/wtap.h) to one (add the
handler). (It also requires adding the handler's source file to
wiretap/CMakeLists.txt, but that's required in both cases.)
A few remain because the WTAP_FILE_TYPE_SUBTYPE_ #define is used
elsewhere; that needs to be fixed.
Fix the wiretap/CMakefile.txt file to scan k12text.l, as that now
contains a registration routine. In the process, avoid scanning files
that don't implement a file type and won't ever have a registration
routine.
Add a Lua routine to fetch the total number of file types; we use that
in some code to construct the wtap_filetypes table, which we need to do
in order to continue to have all the values that used to come from the
WTAP_FILE_TYPE_SUBTYPE_ types.
While we're at it, add modelines to a file that lacked them.
2021-02-14 08:34:10 +00:00
|
|
|
static const struct file_type_subtype_info snoop_info = {
|
|
|
|
|
"Sun snoop", "snoop", "snoop", "cap",
|
wiretap: have file handlers advertise blocks and options supported.
Instead of a "supports name resolution" Boolean and bitflags for types of
comments supported, provide a list of block types that the file
type/subtype supports, with each block type having a list of options
supported. Indicate whether "supported" means "one instance" or
"multiple instances".
"Supports" doesn't just mean "can be written", it also means "could be
read".
Rename WTAP_BLOCK_IF_DESCRIPTION to WTAP_BLOCK_IF_ID_AND_INFO, to
indicate that it provides, in addition to information about the
interface, an ID (implicitly, in pcapng files, by its ordinal number)
that is associated with every packet in the file. Emphasize that in
comments - just because your capture file format can list the interfaces
on which a capture was done, that doesn't mean it supports this; it
doesn't do so if the file doesn't indicate, for every packet, on which
of those interfaces it was captured (I'm looking at *you*, Microsoft
Network Monitor...).
Use APIs to query that information to do what the "does this file
type/subtype support name resolution information", "does this file
type/subtype support all of these comment types", and "does this file
type/subtype support - and require - interface IDs" APIs did.
Provide backwards compatibility for Lua.
This allows us to eliminate the WTAP_FILE_TYPE_SUBTYPE_ values for IBM's
iptrace; do so.
2021-02-21 22:18:04 +00:00
|
|
|
FALSE, BLOCKS_SUPPORTED(snoop_blocks_supported),
|
wiretap: register most built-in file types from its module.
Remove most of the built-in file types from the table in
wiretap/file_access.c and, instead, have the file types register
themselves, using wtap_register_file_type_subtypes().
This reduces the source code changes needed to add a new file type from
three (add the handler, add the file type to the table in file_access.c,
add a #define for the file type in wiretap/wtap.h) to one (add the
handler). (It also requires adding the handler's source file to
wiretap/CMakeLists.txt, but that's required in both cases.)
A few remain because the WTAP_FILE_TYPE_SUBTYPE_ #define is used
elsewhere; that needs to be fixed.
Fix the wiretap/CMakefile.txt file to scan k12text.l, as that now
contains a registration routine. In the process, avoid scanning files
that don't implement a file type and won't ever have a registration
routine.
Add a Lua routine to fetch the total number of file types; we use that
in some code to construct the wtap_filetypes table, which we need to do
in order to continue to have all the values that used to come from the
WTAP_FILE_TYPE_SUBTYPE_ types.
While we're at it, add modelines to a file that lacked them.
2021-02-14 08:34:10 +00:00
|
|
|
snoop_dump_can_write_encap, snoop_dump_open, NULL
|
|
|
|
|
};
|
|
|
|
|
|
wiretap: have file handlers advertise blocks and options supported.
Instead of a "supports name resolution" Boolean and bitflags for types of
comments supported, provide a list of block types that the file
type/subtype supports, with each block type having a list of options
supported. Indicate whether "supported" means "one instance" or
"multiple instances".
"Supports" doesn't just mean "can be written", it also means "could be
read".
Rename WTAP_BLOCK_IF_DESCRIPTION to WTAP_BLOCK_IF_ID_AND_INFO, to
indicate that it provides, in addition to information about the
interface, an ID (implicitly, in pcapng files, by its ordinal number)
that is associated with every packet in the file. Emphasize that in
comments - just because your capture file format can list the interfaces
on which a capture was done, that doesn't mean it supports this; it
doesn't do so if the file doesn't indicate, for every packet, on which
of those interfaces it was captured (I'm looking at *you*, Microsoft
Network Monitor...).
Use APIs to query that information to do what the "does this file
type/subtype support name resolution information", "does this file
type/subtype support all of these comment types", and "does this file
type/subtype support - and require - interface IDs" APIs did.
Provide backwards compatibility for Lua.
This allows us to eliminate the WTAP_FILE_TYPE_SUBTYPE_ values for IBM's
iptrace; do so.
2021-02-21 22:18:04 +00:00
|
|
|
static const struct supported_block_type shomiti_blocks_supported[] = {
|
|
|
|
|
/*
|
|
|
|
|
* We support packet blocks, with no comments or other options.
|
|
|
|
|
*/
|
|
|
|
|
{ WTAP_BLOCK_PACKET, MULTIPLE_BLOCKS_SUPPORTED, NO_OPTIONS_SUPPORTED }
|
|
|
|
|
};
|
|
|
|
|
|
wiretap: register most built-in file types from its module.
Remove most of the built-in file types from the table in
wiretap/file_access.c and, instead, have the file types register
themselves, using wtap_register_file_type_subtypes().
This reduces the source code changes needed to add a new file type from
three (add the handler, add the file type to the table in file_access.c,
add a #define for the file type in wiretap/wtap.h) to one (add the
handler). (It also requires adding the handler's source file to
wiretap/CMakeLists.txt, but that's required in both cases.)
A few remain because the WTAP_FILE_TYPE_SUBTYPE_ #define is used
elsewhere; that needs to be fixed.
Fix the wiretap/CMakefile.txt file to scan k12text.l, as that now
contains a registration routine. In the process, avoid scanning files
that don't implement a file type and won't ever have a registration
routine.
Add a Lua routine to fetch the total number of file types; we use that
in some code to construct the wtap_filetypes table, which we need to do
in order to continue to have all the values that used to come from the
WTAP_FILE_TYPE_SUBTYPE_ types.
While we're at it, add modelines to a file that lacked them.
2021-02-14 08:34:10 +00:00
|
|
|
static const struct file_type_subtype_info shomiti_info = {
|
|
|
|
|
"Shomiti/Finisar Surveyor", "shomiti", "cap", NULL,
|
wiretap: have file handlers advertise blocks and options supported.
Instead of a "supports name resolution" Boolean and bitflags for types of
comments supported, provide a list of block types that the file
type/subtype supports, with each block type having a list of options
supported. Indicate whether "supported" means "one instance" or
"multiple instances".
"Supports" doesn't just mean "can be written", it also means "could be
read".
Rename WTAP_BLOCK_IF_DESCRIPTION to WTAP_BLOCK_IF_ID_AND_INFO, to
indicate that it provides, in addition to information about the
interface, an ID (implicitly, in pcapng files, by its ordinal number)
that is associated with every packet in the file. Emphasize that in
comments - just because your capture file format can list the interfaces
on which a capture was done, that doesn't mean it supports this; it
doesn't do so if the file doesn't indicate, for every packet, on which
of those interfaces it was captured (I'm looking at *you*, Microsoft
Network Monitor...).
Use APIs to query that information to do what the "does this file
type/subtype support name resolution information", "does this file
type/subtype support all of these comment types", and "does this file
type/subtype support - and require - interface IDs" APIs did.
Provide backwards compatibility for Lua.
This allows us to eliminate the WTAP_FILE_TYPE_SUBTYPE_ values for IBM's
iptrace; do so.
2021-02-21 22:18:04 +00:00
|
|
|
FALSE, BLOCKS_SUPPORTED(shomiti_blocks_supported),
|
wiretap: register most built-in file types from its module.
Remove most of the built-in file types from the table in
wiretap/file_access.c and, instead, have the file types register
themselves, using wtap_register_file_type_subtypes().
This reduces the source code changes needed to add a new file type from
three (add the handler, add the file type to the table in file_access.c,
add a #define for the file type in wiretap/wtap.h) to one (add the
handler). (It also requires adding the handler's source file to
wiretap/CMakeLists.txt, but that's required in both cases.)
A few remain because the WTAP_FILE_TYPE_SUBTYPE_ #define is used
elsewhere; that needs to be fixed.
Fix the wiretap/CMakefile.txt file to scan k12text.l, as that now
contains a registration routine. In the process, avoid scanning files
that don't implement a file type and won't ever have a registration
routine.
Add a Lua routine to fetch the total number of file types; we use that
in some code to construct the wtap_filetypes table, which we need to do
in order to continue to have all the values that used to come from the
WTAP_FILE_TYPE_SUBTYPE_ types.
While we're at it, add modelines to a file that lacked them.
2021-02-14 08:34:10 +00:00
|
|
|
NULL, NULL, NULL
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
void register_snoop(void)
|
|
|
|
|
{
|
2021-02-24 03:10:35 +00:00
|
|
|
snoop_file_type_subtype = wtap_register_file_type_subtype(&snoop_info);
|
|
|
|
|
shomiti_file_type_subtype = wtap_register_file_type_subtype(&shomiti_info);
|
wiretap: more work on file type/subtypes.
Provide a wiretap routine to get an array of all savable file
type/subtypes, sorted with pcap and pcapng at the top, followed by the
other types, sorted either by the name or the description.
Use that routine to list options for the -F flag for various commands
Rename wtap_get_savable_file_types_subtypes() to
wtap_get_savable_file_types_subtypes_for_file(), to indicate that it
provides an array of all file type/subtypes in which a given file can be
saved. Have it sort all types, other than the default type/subtype and,
if there is one, the "other" type (both of which are put at the top), by
the name or the description.
Don't allow wtap_register_file_type_subtypes() to override any existing
registrations; have them always register a new type. In that routine,
if there are any emply slots in the table, due to an entry being
unregistered, use it rather than allocating a new slot.
Don't allow unregistration of built-in types.
Rename the "dump open table" to the "file type/subtype table", as it has
entries for all types/subtypes, even if we can't write them.
Initialize that table in a routine that pre-allocates the GArray before
filling it with built-in types/subtypes, so it doesn't keep getting
reallocated.
Get rid of wtap_num_file_types_subtypes - it's just a copy of the size
of the GArray.
Don't have wtap_file_type_subtype_description() crash if handed an
file type/subtype that isn't a valid array index - just return NULL, as
we do with wtap_file_type_subtype_name().
In wtap_name_to_file_type_subtype(), don't use WTAP_FILE_TYPE_SUBTYPE_
names for the backwards-compatibility names - map those names to the
current names, and then look them up. This reduces the number of
uses of hardwired WTAP_FILE_TYPE_SUBTYPE_ values.
Clean up the type of wtap_module_count - it has no need to be a gulong.
Have built-in wiretap file handlers register names to be used for their
file type/subtypes, rather than building the table in init.lua.
Add a new Lua C function get_wtap_filetypes() to construct the
wtap_filetypes table, based on the registered names, and use it in
init.lua.
Add a #define WSLUA_INTERNAL_FUNCTION to register functions intended
only for internal use in init.lua, so they can be made available from
Lua without being documented.
Get rid of WTAP_NUM_FILE_TYPES_SUBTYPES - most code has no need to use
it, as it can just request arrays of types, and the space of
type/subtype codes can be sparse due to registration in any case, so
code has to be careful using it.
wtap_get_num_file_types_subtypes() is no longer used, so remove it. It
returns the number of elements in the file type/subtype array, which is
not necessarily the name of known file type/subtypes, as there may have
been some deregistered types, and those types do *not* get removed from
the array, they just get cleared so that they're available for future
allocation (we don't want the indices of any registered types to changes
if another type is deregistered, as those indicates are the type/subtype
values, so we can't shrink the array).
Clean up white space and remove some comments that shouldn't have been
added.
2021-02-17 06:24:47 +00:00
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* Register names for backwards compatibility with the
|
|
|
|
|
* wtap_filetypes table in Lua.
|
|
|
|
|
*/
|
|
|
|
|
wtap_register_backwards_compatibility_lua_name("SNOOP",
|
|
|
|
|
snoop_file_type_subtype);
|
|
|
|
|
wtap_register_backwards_compatibility_lua_name("SHOMITI",
|
|
|
|
|
shomiti_file_type_subtype);
|
wiretap: register most built-in file types from its module.
Remove most of the built-in file types from the table in
wiretap/file_access.c and, instead, have the file types register
themselves, using wtap_register_file_type_subtypes().
This reduces the source code changes needed to add a new file type from
three (add the handler, add the file type to the table in file_access.c,
add a #define for the file type in wiretap/wtap.h) to one (add the
handler). (It also requires adding the handler's source file to
wiretap/CMakeLists.txt, but that's required in both cases.)
A few remain because the WTAP_FILE_TYPE_SUBTYPE_ #define is used
elsewhere; that needs to be fixed.
Fix the wiretap/CMakefile.txt file to scan k12text.l, as that now
contains a registration routine. In the process, avoid scanning files
that don't implement a file type and won't ever have a registration
routine.
Add a Lua routine to fetch the total number of file types; we use that
in some code to construct the wtap_filetypes table, which we need to do
in order to continue to have all the values that used to come from the
WTAP_FILE_TYPE_SUBTYPE_ types.
While we're at it, add modelines to a file that lacked them.
2021-02-14 08:34:10 +00:00
|
|
|
}
|
|
|
|
|
|
2015-01-02 00:45:22 +00:00
|
|
|
/*
|
2019-07-26 18:43:17 +00:00
|
|
|
* Editor modelines - https://www.wireshark.org/tools/modelines.html
|
2015-01-02 00:45:22 +00:00
|
|
|
*
|
|
|
|
|
* Local variables:
|
|
|
|
|
* c-basic-offset: 8
|
|
|
|
|
* tab-width: 8
|
|
|
|
|
* indent-tabs-mode: t
|
|
|
|
|
* End:
|
|
|
|
|
*
|
|
|
|
|
* vi: set shiftwidth=8 tabstop=8 noexpandtab:
|
|
|
|
|
* :indentSize=8:tabSize=8:noTabs=false:
|
|
|
|
|
*/
|