1999-08-02 02:26:22 +00:00
|
|
|
/* radcom.c
|
1999-09-23 05:03:32 +00:00
|
|
|
*
|
2004-07-18 00:24:25 +00:00
|
|
|
* $Id$
|
1999-08-02 02:26:22 +00:00
|
|
|
*
|
|
|
|
* Wiretap Library
|
2001-11-13 23:55:44 +00:00
|
|
|
* Copyright (c) 1998 by Gilbert Ramirez <gram@alumni.rice.edu>
|
2002-08-28 20:30:45 +00:00
|
|
|
*
|
1999-08-02 02:26:22 +00:00
|
|
|
* This program is free software; you can redistribute it and/or
|
|
|
|
* modify it under the terms of the GNU General Public License
|
|
|
|
* as published by the Free Software Foundation; either version 2
|
|
|
|
* of the License, or (at your option) any later version.
|
2002-08-28 20:30:45 +00:00
|
|
|
*
|
1999-08-02 02:26:22 +00:00
|
|
|
* This program is distributed in the hope that it will be useful,
|
|
|
|
* but WITHOUT ANY WARRANTY; without even the implied warranty of
|
|
|
|
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
|
|
|
|
* GNU General Public License for more details.
|
2002-08-28 20:30:45 +00:00
|
|
|
*
|
1999-08-02 02:26:22 +00:00
|
|
|
* You should have received a copy of the GNU General Public License
|
|
|
|
* along with this program; if not, write to the Free Software
|
2012-06-28 22:56:06 +00:00
|
|
|
* Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA.
|
1999-08-02 02:26:22 +00:00
|
|
|
*/
|
2002-03-04 00:25:35 +00:00
|
|
|
|
1999-08-02 02:26:22 +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"
|
1999-08-02 02:26:22 +00:00
|
|
|
#include "buffer.h"
|
|
|
|
#include "radcom.h"
|
|
|
|
|
|
|
|
struct frame_date {
|
|
|
|
guint16 year;
|
|
|
|
guint8 month;
|
|
|
|
guint8 day;
|
|
|
|
guint32 sec; /* seconds since midnight */
|
|
|
|
guint32 usec;
|
|
|
|
};
|
|
|
|
|
1999-09-01 23:53:58 +00:00
|
|
|
struct unaligned_frame_date {
|
|
|
|
char year[2];
|
|
|
|
char month;
|
|
|
|
char day;
|
|
|
|
char sec[4]; /* seconds since midnight */
|
|
|
|
char usec[4];
|
|
|
|
};
|
|
|
|
|
2002-12-17 21:53:57 +00:00
|
|
|
/* Found at the beginning of the file. Bytes 2 and 3 (D2:00) seem to be
|
|
|
|
* different in some captures */
|
2009-04-24 12:16:01 +00:00
|
|
|
static const guint8 radcom_magic[8] = {
|
1999-08-02 02:26:22 +00:00
|
|
|
0x42, 0xD2, 0x00, 0x34, 0x12, 0x66, 0x22, 0x88
|
|
|
|
};
|
|
|
|
|
2009-04-24 12:16:01 +00:00
|
|
|
static const guint8 encap_magic[4] = {
|
2011-04-27 03:13:08 +00:00
|
|
|
0x00, 0x42, 0x43, 0x09
|
2002-12-17 21:53:57 +00:00
|
|
|
};
|
|
|
|
|
2009-04-24 12:16:01 +00:00
|
|
|
static const guint8 active_time_magic[11] = {
|
2002-12-17 21:53:57 +00:00
|
|
|
0x41, 0x63, 0x74, 0x69, 0x76, 0x65, 0x20, 0x54, 0x69, 0x6d, 0x65
|
|
|
|
};
|
|
|
|
|
1999-09-01 23:53:58 +00:00
|
|
|
/* RADCOM record header - followed by frame data (perhaps including FCS).
|
It appears that the first two bytes of "xxz" are, in fact, the actual
length of the packet, and the second two bytes are the captured length
of the packet. The old "length" value appears to be the captured length
of the packet as well; perhaps it's to be interpreted as the number of
bytes of data following the packet header (just in case there's padding,
for example).
Treat "ATM/", as an encapsulation string, as RFC 1483 ATM. (It may
actually be raw ATM, but the only capture I've seen had, in the parts I
saw, only RFC 1483 traffic LLC/SNAP traffic.)
There are 8 bytes in front of the LLC/SNAP header in ATM captures; skip
them, for now. (Perhaps they're a pseudo-header, giving VPI/VCI
information and stuff such as that? Or perhaps that's in the record
header?)
svn path=/trunk/; revision=6871
2003-01-07 08:41:23 +00:00
|
|
|
|
|
|
|
"data_length" appears to be the length of packet data following
|
|
|
|
the record header. It's 0 in the last record.
|
|
|
|
|
|
|
|
"length" appears to be the amount of captured packet data, and
|
|
|
|
"real_length" might be the actual length of the frame on the wire -
|
|
|
|
in some captures, it's the same as "length", and, in others,
|
|
|
|
it's greater than "length". In the last record, however, those
|
|
|
|
may have bogus values (or is that some kind of trailer record?).
|
|
|
|
|
|
|
|
"xxx" appears to be all-zero in all but the last record in one
|
|
|
|
capture; if so, perhaps this indicates that the last record is,
|
|
|
|
in fact, a trailer of some sort, and some field in the header
|
|
|
|
is a record type. */
|
1999-09-01 23:53:58 +00:00
|
|
|
struct radcomrec_hdr {
|
|
|
|
char xxx[4]; /* unknown */
|
It appears that the first two bytes of "xxz" are, in fact, the actual
length of the packet, and the second two bytes are the captured length
of the packet. The old "length" value appears to be the captured length
of the packet as well; perhaps it's to be interpreted as the number of
bytes of data following the packet header (just in case there's padding,
for example).
Treat "ATM/", as an encapsulation string, as RFC 1483 ATM. (It may
actually be raw ATM, but the only capture I've seen had, in the parts I
saw, only RFC 1483 traffic LLC/SNAP traffic.)
There are 8 bytes in front of the LLC/SNAP header in ATM captures; skip
them, for now. (Perhaps they're a pseudo-header, giving VPI/VCI
information and stuff such as that? Or perhaps that's in the record
header?)
svn path=/trunk/; revision=6871
2003-01-07 08:41:23 +00:00
|
|
|
char data_length[2]; /* packet length? */
|
1999-09-01 23:53:58 +00:00
|
|
|
char xxy[5]; /* unknown */
|
|
|
|
struct unaligned_frame_date date; /* date/time stamp of packet */
|
It appears that the first two bytes of "xxz" are, in fact, the actual
length of the packet, and the second two bytes are the captured length
of the packet. The old "length" value appears to be the captured length
of the packet as well; perhaps it's to be interpreted as the number of
bytes of data following the packet header (just in case there's padding,
for example).
Treat "ATM/", as an encapsulation string, as RFC 1483 ATM. (It may
actually be raw ATM, but the only capture I've seen had, in the parts I
saw, only RFC 1483 traffic LLC/SNAP traffic.)
There are 8 bytes in front of the LLC/SNAP header in ATM captures; skip
them, for now. (Perhaps they're a pseudo-header, giving VPI/VCI
information and stuff such as that? Or perhaps that's in the record
header?)
svn path=/trunk/; revision=6871
2003-01-07 08:41:23 +00:00
|
|
|
char real_length[2]; /* actual length of packet */
|
|
|
|
char length[2]; /* captured length of packet */
|
|
|
|
char xxz[2]; /* unknown */
|
1999-09-01 23:53:58 +00:00
|
|
|
char dce; /* DCE/DTE flag (and other flags?) */
|
|
|
|
char xxw[9]; /* unknown */
|
|
|
|
};
|
|
|
|
|
Have the Wiretap open, read, and seek-and-read routines return, in
addition to an error code, an error info string, for
WTAP_ERR_UNSUPPORTED, WTAP_ERR_UNSUPPORTED_ENCAP, and
WTAP_ERR_BAD_RECORD errors. Replace the error messages logged with
"g_message()" for those errors with g_strdup()ed or g_strdup_printf()ed
strings returned as the error info string, and change the callers of
those routines to, for those errors, put the info string into the
printed message or alert box for the error.
Add messages for cases where those errors were returned without printing
an additional message.
Nobody uses the error code from "cf_read()" - "cf_read()" puts up the
alert box itself for failures; get rid of the error code, so it just
returns a success/failure indication.
Rename "file_read_error_message()" to "cf_read_error_message()", as it
handles read errors from Wiretap, and have it take an error info string
as an argument. (That handles a lot of the work of putting the info
string into the error message.)
Make some variables in "ascend-grammar.y" static.
Check the return value of "erf_read_header()" in "erf_seek_read()".
Get rid of an unused #define in "i4btrace.c".
svn path=/trunk/; revision=9852
2004-01-25 21:55:17 +00:00
|
|
|
static gboolean radcom_read(wtap *wth, int *err, gchar **err_info,
|
2006-11-05 22:46:44 +00:00
|
|
|
gint64 *data_offset);
|
|
|
|
static gboolean radcom_seek_read(wtap *wth, gint64 seek_off,
|
2012-10-16 21:50:57 +00:00
|
|
|
struct wtap_pkthdr *pkhdr, guint8 *pd, int length,
|
Have the Wiretap open, read, and seek-and-read routines return, in
addition to an error code, an error info string, for
WTAP_ERR_UNSUPPORTED, WTAP_ERR_UNSUPPORTED_ENCAP, and
WTAP_ERR_BAD_RECORD errors. Replace the error messages logged with
"g_message()" for those errors with g_strdup()ed or g_strdup_printf()ed
strings returned as the error info string, and change the callers of
those routines to, for those errors, put the info string into the
printed message or alert box for the error.
Add messages for cases where those errors were returned without printing
an additional message.
Nobody uses the error code from "cf_read()" - "cf_read()" puts up the
alert box itself for failures; get rid of the error code, so it just
returns a success/failure indication.
Rename "file_read_error_message()" to "cf_read_error_message()", as it
handles read errors from Wiretap, and have it take an error info string
as an argument. (That handles a lot of the work of putting the info
string into the error message.)
Make some variables in "ascend-grammar.y" static.
Check the return value of "erf_read_header()" in "erf_seek_read()".
Get rid of an unused #define in "i4btrace.c".
svn path=/trunk/; revision=9852
2004-01-25 21:55:17 +00:00
|
|
|
int *err, gchar **err_info);
|
2000-05-19 08:18:17 +00:00
|
|
|
static int radcom_read_rec_header(FILE_T fh, struct radcomrec_hdr *hdr,
|
2011-04-21 09:41:52 +00:00
|
|
|
int *err, gchar **err_info);
|
2011-09-01 09:43:10 +00:00
|
|
|
static gboolean radcom_read_rec_data(FILE_T fh, guint8 *pd, int length,
|
2011-04-21 09:41:52 +00:00
|
|
|
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
|
|
|
|
Have the Wiretap open, read, and seek-and-read routines return, in
addition to an error code, an error info string, for
WTAP_ERR_UNSUPPORTED, WTAP_ERR_UNSUPPORTED_ENCAP, and
WTAP_ERR_BAD_RECORD errors. Replace the error messages logged with
"g_message()" for those errors with g_strdup()ed or g_strdup_printf()ed
strings returned as the error info string, and change the callers of
those routines to, for those errors, put the info string into the
printed message or alert box for the error.
Add messages for cases where those errors were returned without printing
an additional message.
Nobody uses the error code from "cf_read()" - "cf_read()" puts up the
alert box itself for failures; get rid of the error code, so it just
returns a success/failure indication.
Rename "file_read_error_message()" to "cf_read_error_message()", as it
handles read errors from Wiretap, and have it take an error info string
as an argument. (That handles a lot of the work of putting the info
string into the error message.)
Make some variables in "ascend-grammar.y" static.
Check the return value of "erf_read_header()" in "erf_seek_read()".
Get rid of an unused #define in "i4btrace.c".
svn path=/trunk/; revision=9852
2004-01-25 21:55:17 +00:00
|
|
|
int radcom_open(wtap *wth, int *err, gchar **err_info)
|
1999-08-02 02:26:22 +00:00
|
|
|
{
|
|
|
|
int bytes_read;
|
2002-12-17 21:53:57 +00:00
|
|
|
guint8 r_magic[8], t_magic[11], search_encap[7];
|
1999-08-02 02:26:22 +00:00
|
|
|
struct frame_date start_date;
|
2011-04-27 03:13:08 +00:00
|
|
|
#if 0
|
1999-08-31 00:25:19 +00:00
|
|
|
guint32 sec;
|
1999-08-02 02:26:22 +00:00
|
|
|
struct tm tm;
|
2011-04-27 03:13:08 +00:00
|
|
|
#endif
|
1999-08-02 02:26:22 +00:00
|
|
|
|
1999-08-20 08:00:24 +00:00
|
|
|
/* Read in the string that should be at the start of a RADCOM file */
|
Have the per-capture-file-type open routines "wtap_open_offline()" calls
return 1 on success, -1 if they got an error, and 0 if the file isn't of
the type that file is checking for, and supply an error code if they
return -1; have "wtap_open_offline()" use that error code. Also, have
the per-capture-file-type open routines treat errors accessing the file
as errors, and return -1, rather than just returning 0 so that we try
another file type.
Have the per-capture-file-type read routines "wtap_loop()" calls return
-1 and supply an error code on error (and not, as they did in some
cases, call "g_error()" and abort), and have "wtap_loop()", if the read
routine returned an error, return FALSE (and pass an error-code-pointer
argument onto the read routines, so they fill it in), and return TRUE on
success.
Add some new error codes for them to return.
Now that "wtap_loop()" can return a success/failure indication and an
error code, in "read_cap_file()" put up a message box if we get an error
reading the file, and return the error code.
Handle the additional errors we can get when opening a capture file.
If the attempt to open a capture file succeeds, but the attempt to read
it fails, don't treat that as a complete failure - we may have managed
to read some of the capture file, and we should display what we managed
to read.
svn path=/trunk/; revision=516
1999-08-19 05:31:38 +00:00
|
|
|
errno = WTAP_ERR_CANT_READ;
|
2011-04-06 06:51:19 +00:00
|
|
|
bytes_read = file_read(r_magic, 8, wth->fh);
|
1999-08-02 02:26:22 +00:00
|
|
|
if (bytes_read != 8) {
|
2011-04-21 09:41:52 +00:00
|
|
|
*err = file_error(wth->fh, err_info);
|
Do not call wtap_file_read_unknown_bytes() or
wtap_file_read_expected_bytes() from an open routine - open routines are
supposed to return -1 on error, 0 if the file doesn't appear to be a
file of the specified type, or 1 if the file does appear to be a file of
the specified type, but those macros will cause the caller to return
FALSE on errors (so that, even if there's an I/O error, it reports "the
file isn't a file of the specified type" rather than "we got an error
trying to read the file").
When doing reads in an open routine before we've concluded that the file
is probably of the right type, return 0, rather than -1, if we get
WTAP_ERR_SHORT_READ - if we don't have enough data to check whether a
file is of a given type, we should keep trying other types, not give up.
For reads done *after* we've concluded the file is probably of the right
type, if a read doesn't return the number of bytes we asked for, but
returns an error of 0, return WTAP_ERR_SHORT_READ - the file is
apparently cut short.
For NetMon and NetXRay/Windows Sniffer files, use a #define for the
magic number size, and use that for both magic numbers.
svn path=/trunk/; revision=46803
2012-12-27 12:19:25 +00:00
|
|
|
if (*err != 0 && *err != WTAP_ERR_SHORT_READ)
|
Have the per-capture-file-type open routines "wtap_open_offline()" calls
return 1 on success, -1 if they got an error, and 0 if the file isn't of
the type that file is checking for, and supply an error code if they
return -1; have "wtap_open_offline()" use that error code. Also, have
the per-capture-file-type open routines treat errors accessing the file
as errors, and return -1, rather than just returning 0 so that we try
another file type.
Have the per-capture-file-type read routines "wtap_loop()" calls return
-1 and supply an error code on error (and not, as they did in some
cases, call "g_error()" and abort), and have "wtap_loop()", if the read
routine returned an error, return FALSE (and pass an error-code-pointer
argument onto the read routines, so they fill it in), and return TRUE on
success.
Add some new error codes for them to return.
Now that "wtap_loop()" can return a success/failure indication and an
error code, in "read_cap_file()" put up a message box if we get an error
reading the file, and return the error code.
Handle the additional errors we can get when opening a capture file.
If the attempt to open a capture file succeeds, but the attempt to read
it fails, don't treat that as a complete failure - we may have managed
to read some of the capture file, and we should display what we managed
to read.
svn path=/trunk/; revision=516
1999-08-19 05:31:38 +00:00
|
|
|
return -1;
|
|
|
|
return 0;
|
1999-08-02 02:26:22 +00:00
|
|
|
}
|
|
|
|
|
2011-04-27 03:13:08 +00:00
|
|
|
/* XXX: bytes 2 and 3 of the "magic" header seem to be different in some
|
|
|
|
* captures. We force them to our standard value so that the test
|
|
|
|
* succeeds (until we find if they have a special meaning, perhaps a
|
|
|
|
* version number ?) */
|
|
|
|
r_magic[1] = 0xD2;
|
|
|
|
r_magic[2] = 0x00;
|
2002-12-17 21:53:57 +00:00
|
|
|
if (memcmp(r_magic, radcom_magic, 8) != 0) {
|
Have the per-capture-file-type open routines "wtap_open_offline()" calls
return 1 on success, -1 if they got an error, and 0 if the file isn't of
the type that file is checking for, and supply an error code if they
return -1; have "wtap_open_offline()" use that error code. Also, have
the per-capture-file-type open routines treat errors accessing the file
as errors, and return -1, rather than just returning 0 so that we try
another file type.
Have the per-capture-file-type read routines "wtap_loop()" calls return
-1 and supply an error code on error (and not, as they did in some
cases, call "g_error()" and abort), and have "wtap_loop()", if the read
routine returned an error, return FALSE (and pass an error-code-pointer
argument onto the read routines, so they fill it in), and return TRUE on
success.
Add some new error codes for them to return.
Now that "wtap_loop()" can return a success/failure indication and an
error code, in "read_cap_file()" put up a message box if we get an error
reading the file, and return the error code.
Handle the additional errors we can get when opening a capture file.
If the attempt to open a capture file succeeds, but the attempt to read
it fails, don't treat that as a complete failure - we may have managed
to read some of the capture file, and we should display what we managed
to read.
svn path=/trunk/; revision=516
1999-08-19 05:31:38 +00:00
|
|
|
return 0;
|
1999-08-02 02:26:22 +00:00
|
|
|
}
|
|
|
|
|
2011-04-27 03:13:08 +00:00
|
|
|
/* Look for the "Active Time" string. The "frame_date" structure should
|
|
|
|
* be located 32 bytes before the beginning of this string */
|
Have the per-capture-file-type open routines "wtap_open_offline()" calls
return 1 on success, -1 if they got an error, and 0 if the file isn't of
the type that file is checking for, and supply an error code if they
return -1; have "wtap_open_offline()" use that error code. Also, have
the per-capture-file-type open routines treat errors accessing the file
as errors, and return -1, rather than just returning 0 so that we try
another file type.
Have the per-capture-file-type read routines "wtap_loop()" calls return
-1 and supply an error code on error (and not, as they did in some
cases, call "g_error()" and abort), and have "wtap_loop()", if the read
routine returned an error, return FALSE (and pass an error-code-pointer
argument onto the read routines, so they fill it in), and return TRUE on
success.
Add some new error codes for them to return.
Now that "wtap_loop()" can return a success/failure indication and an
error code, in "read_cap_file()" put up a message box if we get an error
reading the file, and return the error code.
Handle the additional errors we can get when opening a capture file.
If the attempt to open a capture file succeeds, but the attempt to read
it fails, don't treat that as a complete failure - we may have managed
to read some of the capture file, and we should display what we managed
to read.
svn path=/trunk/; revision=516
1999-08-19 05:31:38 +00:00
|
|
|
errno = WTAP_ERR_CANT_READ;
|
2011-04-06 06:51:19 +00:00
|
|
|
bytes_read = file_read(t_magic, 11, wth->fh);
|
2002-12-17 21:53:57 +00:00
|
|
|
if (bytes_read != 11) {
|
2011-04-21 09:41:52 +00:00
|
|
|
*err = file_error(wth->fh, err_info);
|
Do not call wtap_file_read_unknown_bytes() or
wtap_file_read_expected_bytes() from an open routine - open routines are
supposed to return -1 on error, 0 if the file doesn't appear to be a
file of the specified type, or 1 if the file does appear to be a file of
the specified type, but those macros will cause the caller to return
FALSE on errors (so that, even if there's an I/O error, it reports "the
file isn't a file of the specified type" rather than "we got an error
trying to read the file").
When doing reads in an open routine before we've concluded that the file
is probably of the right type, return 0, rather than -1, if we get
WTAP_ERR_SHORT_READ - if we don't have enough data to check whether a
file is of a given type, we should keep trying other types, not give up.
For reads done *after* we've concluded the file is probably of the right
type, if a read doesn't return the number of bytes we asked for, but
returns an error of 0, return WTAP_ERR_SHORT_READ - the file is
apparently cut short.
For NetMon and NetXRay/Windows Sniffer files, use a #define for the
magic number size, and use that for both magic numbers.
svn path=/trunk/; revision=46803
2012-12-27 12:19:25 +00:00
|
|
|
if (*err != 0 && *err != WTAP_ERR_SHORT_READ)
|
Have the per-capture-file-type open routines "wtap_open_offline()" calls
return 1 on success, -1 if they got an error, and 0 if the file isn't of
the type that file is checking for, and supply an error code if they
return -1; have "wtap_open_offline()" use that error code. Also, have
the per-capture-file-type open routines treat errors accessing the file
as errors, and return -1, rather than just returning 0 so that we try
another file type.
Have the per-capture-file-type read routines "wtap_loop()" calls return
-1 and supply an error code on error (and not, as they did in some
cases, call "g_error()" and abort), and have "wtap_loop()", if the read
routine returned an error, return FALSE (and pass an error-code-pointer
argument onto the read routines, so they fill it in), and return TRUE on
success.
Add some new error codes for them to return.
Now that "wtap_loop()" can return a success/failure indication and an
error code, in "read_cap_file()" put up a message box if we get an error
reading the file, and return the error code.
Handle the additional errors we can get when opening a capture file.
If the attempt to open a capture file succeeds, but the attempt to read
it fails, don't treat that as a complete failure - we may have managed
to read some of the capture file, and we should display what we managed
to read.
svn path=/trunk/; revision=516
1999-08-19 05:31:38 +00:00
|
|
|
return -1;
|
|
|
|
return 0;
|
1999-08-02 02:26:22 +00:00
|
|
|
}
|
2011-04-27 03:13:08 +00:00
|
|
|
while (memcmp(t_magic, active_time_magic, 11) != 0)
|
|
|
|
{
|
|
|
|
if (file_seek(wth->fh, -10, SEEK_CUR, err) == -1)
|
|
|
|
return -1;
|
|
|
|
errno = WTAP_ERR_CANT_READ;
|
|
|
|
bytes_read = file_read(t_magic, 11, wth->fh);
|
|
|
|
if (bytes_read != 11) {
|
|
|
|
*err = file_error(wth->fh, err_info);
|
Do not call wtap_file_read_unknown_bytes() or
wtap_file_read_expected_bytes() from an open routine - open routines are
supposed to return -1 on error, 0 if the file doesn't appear to be a
file of the specified type, or 1 if the file does appear to be a file of
the specified type, but those macros will cause the caller to return
FALSE on errors (so that, even if there's an I/O error, it reports "the
file isn't a file of the specified type" rather than "we got an error
trying to read the file").
When doing reads in an open routine before we've concluded that the file
is probably of the right type, return 0, rather than -1, if we get
WTAP_ERR_SHORT_READ - if we don't have enough data to check whether a
file is of a given type, we should keep trying other types, not give up.
For reads done *after* we've concluded the file is probably of the right
type, if a read doesn't return the number of bytes we asked for, but
returns an error of 0, return WTAP_ERR_SHORT_READ - the file is
apparently cut short.
For NetMon and NetXRay/Windows Sniffer files, use a #define for the
magic number size, and use that for both magic numbers.
svn path=/trunk/; revision=46803
2012-12-27 12:19:25 +00:00
|
|
|
if (*err != 0 && *err != WTAP_ERR_SHORT_READ)
|
2011-04-27 03:13:08 +00:00
|
|
|
return -1;
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
if (file_seek(wth->fh, -43, SEEK_CUR, err) == -1) return -1;
|
1999-08-02 02:26:22 +00:00
|
|
|
|
|
|
|
/* Get capture start time */
|
Have the per-capture-file-type open routines "wtap_open_offline()" calls
return 1 on success, -1 if they got an error, and 0 if the file isn't of
the type that file is checking for, and supply an error code if they
return -1; have "wtap_open_offline()" use that error code. Also, have
the per-capture-file-type open routines treat errors accessing the file
as errors, and return -1, rather than just returning 0 so that we try
another file type.
Have the per-capture-file-type read routines "wtap_loop()" calls return
-1 and supply an error code on error (and not, as they did in some
cases, call "g_error()" and abort), and have "wtap_loop()", if the read
routine returned an error, return FALSE (and pass an error-code-pointer
argument onto the read routines, so they fill it in), and return TRUE on
success.
Add some new error codes for them to return.
Now that "wtap_loop()" can return a success/failure indication and an
error code, in "read_cap_file()" put up a message box if we get an error
reading the file, and return the error code.
Handle the additional errors we can get when opening a capture file.
If the attempt to open a capture file succeeds, but the attempt to read
it fails, don't treat that as a complete failure - we may have managed
to read some of the capture file, and we should display what we managed
to read.
svn path=/trunk/; revision=516
1999-08-19 05:31:38 +00:00
|
|
|
errno = WTAP_ERR_CANT_READ;
|
2011-04-06 06:51:19 +00:00
|
|
|
bytes_read = file_read(&start_date, sizeof(struct frame_date),
|
2011-04-27 03:13:08 +00:00
|
|
|
wth->fh);
|
1999-08-02 02:26:22 +00:00
|
|
|
if (bytes_read != sizeof(struct frame_date)) {
|
2011-04-21 09:41:52 +00:00
|
|
|
*err = file_error(wth->fh, err_info);
|
Do not call wtap_file_read_unknown_bytes() or
wtap_file_read_expected_bytes() from an open routine - open routines are
supposed to return -1 on error, 0 if the file doesn't appear to be a
file of the specified type, or 1 if the file does appear to be a file of
the specified type, but those macros will cause the caller to return
FALSE on errors (so that, even if there's an I/O error, it reports "the
file isn't a file of the specified type" rather than "we got an error
trying to read the file").
When doing reads in an open routine before we've concluded that the file
is probably of the right type, return 0, rather than -1, if we get
WTAP_ERR_SHORT_READ - if we don't have enough data to check whether a
file is of a given type, we should keep trying other types, not give up.
For reads done *after* we've concluded the file is probably of the right
type, if a read doesn't return the number of bytes we asked for, but
returns an error of 0, return WTAP_ERR_SHORT_READ - the file is
apparently cut short.
For NetMon and NetXRay/Windows Sniffer files, use a #define for the
magic number size, and use that for both magic numbers.
svn path=/trunk/; revision=46803
2012-12-27 12:19:25 +00:00
|
|
|
if (*err != 0 && *err != WTAP_ERR_SHORT_READ)
|
Have the per-capture-file-type open routines "wtap_open_offline()" calls
return 1 on success, -1 if they got an error, and 0 if the file isn't of
the type that file is checking for, and supply an error code if they
return -1; have "wtap_open_offline()" use that error code. Also, have
the per-capture-file-type open routines treat errors accessing the file
as errors, and return -1, rather than just returning 0 so that we try
another file type.
Have the per-capture-file-type read routines "wtap_loop()" calls return
-1 and supply an error code on error (and not, as they did in some
cases, call "g_error()" and abort), and have "wtap_loop()", if the read
routine returned an error, return FALSE (and pass an error-code-pointer
argument onto the read routines, so they fill it in), and return TRUE on
success.
Add some new error codes for them to return.
Now that "wtap_loop()" can return a success/failure indication and an
error code, in "read_cap_file()" put up a message box if we get an error
reading the file, and return the error code.
Handle the additional errors we can get when opening a capture file.
If the attempt to open a capture file succeeds, but the attempt to read
it fails, don't treat that as a complete failure - we may have managed
to read some of the capture file, and we should display what we managed
to read.
svn path=/trunk/; revision=516
1999-08-19 05:31:38 +00:00
|
|
|
return -1;
|
|
|
|
return 0;
|
1999-08-02 02:26:22 +00:00
|
|
|
}
|
|
|
|
|
Have the per-capture-file-type open routines "wtap_open_offline()" calls
return 1 on success, -1 if they got an error, and 0 if the file isn't of
the type that file is checking for, and supply an error code if they
return -1; have "wtap_open_offline()" use that error code. Also, have
the per-capture-file-type open routines treat errors accessing the file
as errors, and return -1, rather than just returning 0 so that we try
another file type.
Have the per-capture-file-type read routines "wtap_loop()" calls return
-1 and supply an error code on error (and not, as they did in some
cases, call "g_error()" and abort), and have "wtap_loop()", if the read
routine returned an error, return FALSE (and pass an error-code-pointer
argument onto the read routines, so they fill it in), and return TRUE on
success.
Add some new error codes for them to return.
Now that "wtap_loop()" can return a success/failure indication and an
error code, in "read_cap_file()" put up a message box if we get an error
reading the file, and return the error code.
Handle the additional errors we can get when opening a capture file.
If the attempt to open a capture file succeeds, but the attempt to read
it fails, don't treat that as a complete failure - we may have managed
to read some of the capture file, and we should display what we managed
to read.
svn path=/trunk/; revision=516
1999-08-19 05:31:38 +00:00
|
|
|
/* This is a radcom file */
|
|
|
|
wth->file_type = WTAP_FILE_RADCOM;
|
|
|
|
wth->subtype_read = radcom_read;
|
2000-05-18 09:09:50 +00:00
|
|
|
wth->subtype_seek_read = radcom_seek_read;
|
2002-12-17 21:53:57 +00:00
|
|
|
wth->snapshot_length = 0; /* not available in header, only in frame */
|
2005-08-25 21:29:54 +00:00
|
|
|
wth->tsprecision = WTAP_FILE_TSPREC_USEC;
|
Have the per-capture-file-type open routines "wtap_open_offline()" calls
return 1 on success, -1 if they got an error, and 0 if the file isn't of
the type that file is checking for, and supply an error code if they
return -1; have "wtap_open_offline()" use that error code. Also, have
the per-capture-file-type open routines treat errors accessing the file
as errors, and return -1, rather than just returning 0 so that we try
another file type.
Have the per-capture-file-type read routines "wtap_loop()" calls return
-1 and supply an error code on error (and not, as they did in some
cases, call "g_error()" and abort), and have "wtap_loop()", if the read
routine returned an error, return FALSE (and pass an error-code-pointer
argument onto the read routines, so they fill it in), and return TRUE on
success.
Add some new error codes for them to return.
Now that "wtap_loop()" can return a success/failure indication and an
error code, in "read_cap_file()" put up a message box if we get an error
reading the file, and return the error code.
Handle the additional errors we can get when opening a capture file.
If the attempt to open a capture file succeeds, but the attempt to read
it fails, don't treat that as a complete failure - we may have managed
to read some of the capture file, and we should display what we managed
to read.
svn path=/trunk/; revision=516
1999-08-19 05:31:38 +00:00
|
|
|
|
2011-04-27 03:13:08 +00:00
|
|
|
#if 0
|
1999-08-30 20:40:13 +00:00
|
|
|
tm.tm_year = pletohs(&start_date.year)-1900;
|
1999-08-02 02:26:22 +00:00
|
|
|
tm.tm_mon = start_date.month-1;
|
|
|
|
tm.tm_mday = start_date.day;
|
1999-08-31 00:25:19 +00:00
|
|
|
sec = pletohl(&start_date.sec);
|
|
|
|
tm.tm_hour = sec/3600;
|
|
|
|
tm.tm_min = (sec%3600)/60;
|
|
|
|
tm.tm_sec = sec%60;
|
1999-08-02 02:26:22 +00:00
|
|
|
tm.tm_isdst = -1;
|
2011-04-27 03:13:08 +00:00
|
|
|
#endif
|
2002-06-07 07:27:35 +00:00
|
|
|
if (file_seek(wth->fh, sizeof(struct frame_date), SEEK_CUR, err) == -1)
|
2002-03-04 00:25:35 +00:00
|
|
|
return -1;
|
1999-08-02 02:26:22 +00:00
|
|
|
|
Have the per-capture-file-type open routines "wtap_open_offline()" calls
return 1 on success, -1 if they got an error, and 0 if the file isn't of
the type that file is checking for, and supply an error code if they
return -1; have "wtap_open_offline()" use that error code. Also, have
the per-capture-file-type open routines treat errors accessing the file
as errors, and return -1, rather than just returning 0 so that we try
another file type.
Have the per-capture-file-type read routines "wtap_loop()" calls return
-1 and supply an error code on error (and not, as they did in some
cases, call "g_error()" and abort), and have "wtap_loop()", if the read
routine returned an error, return FALSE (and pass an error-code-pointer
argument onto the read routines, so they fill it in), and return TRUE on
success.
Add some new error codes for them to return.
Now that "wtap_loop()" can return a success/failure indication and an
error code, in "read_cap_file()" put up a message box if we get an error
reading the file, and return the error code.
Handle the additional errors we can get when opening a capture file.
If the attempt to open a capture file succeeds, but the attempt to read
it fails, don't treat that as a complete failure - we may have managed
to read some of the capture file, and we should display what we managed
to read.
svn path=/trunk/; revision=516
1999-08-19 05:31:38 +00:00
|
|
|
errno = WTAP_ERR_CANT_READ;
|
2011-04-06 06:51:19 +00:00
|
|
|
bytes_read = file_read(search_encap, 4, wth->fh);
|
2000-11-13 23:00:55 +00:00
|
|
|
if (bytes_read != 4) {
|
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
|
|
|
goto read_error;
|
1999-08-02 02:26:22 +00:00
|
|
|
}
|
2000-11-13 23:00:55 +00:00
|
|
|
while (memcmp(encap_magic, search_encap, 4)) {
|
2002-06-07 07:27:35 +00:00
|
|
|
if (file_seek(wth->fh, -3, SEEK_CUR, err) == -1)
|
2002-03-04 00:25:35 +00:00
|
|
|
return -1;
|
Have the per-capture-file-type open routines "wtap_open_offline()" calls
return 1 on success, -1 if they got an error, and 0 if the file isn't of
the type that file is checking for, and supply an error code if they
return -1; have "wtap_open_offline()" use that error code. Also, have
the per-capture-file-type open routines treat errors accessing the file
as errors, and return -1, rather than just returning 0 so that we try
another file type.
Have the per-capture-file-type read routines "wtap_loop()" calls return
-1 and supply an error code on error (and not, as they did in some
cases, call "g_error()" and abort), and have "wtap_loop()", if the read
routine returned an error, return FALSE (and pass an error-code-pointer
argument onto the read routines, so they fill it in), and return TRUE on
success.
Add some new error codes for them to return.
Now that "wtap_loop()" can return a success/failure indication and an
error code, in "read_cap_file()" put up a message box if we get an error
reading the file, and return the error code.
Handle the additional errors we can get when opening a capture file.
If the attempt to open a capture file succeeds, but the attempt to read
it fails, don't treat that as a complete failure - we may have managed
to read some of the capture file, and we should display what we managed
to read.
svn path=/trunk/; revision=516
1999-08-19 05:31:38 +00:00
|
|
|
errno = WTAP_ERR_CANT_READ;
|
2011-04-06 06:51:19 +00:00
|
|
|
bytes_read = file_read(search_encap, 4, wth->fh);
|
2000-11-13 23:00:55 +00:00
|
|
|
if (bytes_read != 4) {
|
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
|
|
|
goto read_error;
|
1999-08-02 02:26:22 +00:00
|
|
|
}
|
|
|
|
}
|
2002-06-07 07:27:35 +00:00
|
|
|
if (file_seek(wth->fh, 12, SEEK_CUR, err) == -1)
|
2002-03-04 00:25:35 +00:00
|
|
|
return -1;
|
Have the per-capture-file-type open routines "wtap_open_offline()" calls
return 1 on success, -1 if they got an error, and 0 if the file isn't of
the type that file is checking for, and supply an error code if they
return -1; have "wtap_open_offline()" use that error code. Also, have
the per-capture-file-type open routines treat errors accessing the file
as errors, and return -1, rather than just returning 0 so that we try
another file type.
Have the per-capture-file-type read routines "wtap_loop()" calls return
-1 and supply an error code on error (and not, as they did in some
cases, call "g_error()" and abort), and have "wtap_loop()", if the read
routine returned an error, return FALSE (and pass an error-code-pointer
argument onto the read routines, so they fill it in), and return TRUE on
success.
Add some new error codes for them to return.
Now that "wtap_loop()" can return a success/failure indication and an
error code, in "read_cap_file()" put up a message box if we get an error
reading the file, and return the error code.
Handle the additional errors we can get when opening a capture file.
If the attempt to open a capture file succeeds, but the attempt to read
it fails, don't treat that as a complete failure - we may have managed
to read some of the capture file, and we should display what we managed
to read.
svn path=/trunk/; revision=516
1999-08-19 05:31:38 +00:00
|
|
|
errno = WTAP_ERR_CANT_READ;
|
2011-04-06 06:51:19 +00:00
|
|
|
bytes_read = file_read(search_encap, 4, wth->fh);
|
1999-08-02 02:26:22 +00:00
|
|
|
if (bytes_read != 4) {
|
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
|
|
|
goto read_error;
|
1999-08-02 02:26:22 +00:00
|
|
|
}
|
It appears that the first two bytes of "xxz" are, in fact, the actual
length of the packet, and the second two bytes are the captured length
of the packet. The old "length" value appears to be the captured length
of the packet as well; perhaps it's to be interpreted as the number of
bytes of data following the packet header (just in case there's padding,
for example).
Treat "ATM/", as an encapsulation string, as RFC 1483 ATM. (It may
actually be raw ATM, but the only capture I've seen had, in the parts I
saw, only RFC 1483 traffic LLC/SNAP traffic.)
There are 8 bytes in front of the LLC/SNAP header in ATM captures; skip
them, for now. (Perhaps they're a pseudo-header, giving VPI/VCI
information and stuff such as that? Or perhaps that's in the record
header?)
svn path=/trunk/; revision=6871
2003-01-07 08:41:23 +00:00
|
|
|
if (memcmp(search_encap, "LAPB", 4) == 0)
|
1999-08-02 02:26:22 +00:00
|
|
|
wth->file_encap = WTAP_ENCAP_LAPB;
|
It appears that the first two bytes of "xxz" are, in fact, the actual
length of the packet, and the second two bytes are the captured length
of the packet. The old "length" value appears to be the captured length
of the packet as well; perhaps it's to be interpreted as the number of
bytes of data following the packet header (just in case there's padding,
for example).
Treat "ATM/", as an encapsulation string, as RFC 1483 ATM. (It may
actually be raw ATM, but the only capture I've seen had, in the parts I
saw, only RFC 1483 traffic LLC/SNAP traffic.)
There are 8 bytes in front of the LLC/SNAP header in ATM captures; skip
them, for now. (Perhaps they're a pseudo-header, giving VPI/VCI
information and stuff such as that? Or perhaps that's in the record
header?)
svn path=/trunk/; revision=6871
2003-01-07 08:41:23 +00:00
|
|
|
else if (memcmp(search_encap, "Ethe", 4) == 0)
|
1999-08-02 02:26:22 +00:00
|
|
|
wth->file_encap = WTAP_ENCAP_ETHERNET;
|
It appears that the first two bytes of "xxz" are, in fact, the actual
length of the packet, and the second two bytes are the captured length
of the packet. The old "length" value appears to be the captured length
of the packet as well; perhaps it's to be interpreted as the number of
bytes of data following the packet header (just in case there's padding,
for example).
Treat "ATM/", as an encapsulation string, as RFC 1483 ATM. (It may
actually be raw ATM, but the only capture I've seen had, in the parts I
saw, only RFC 1483 traffic LLC/SNAP traffic.)
There are 8 bytes in front of the LLC/SNAP header in ATM captures; skip
them, for now. (Perhaps they're a pseudo-header, giving VPI/VCI
information and stuff such as that? Or perhaps that's in the record
header?)
svn path=/trunk/; revision=6871
2003-01-07 08:41:23 +00:00
|
|
|
else if (memcmp(search_encap, "ATM/", 4) == 0)
|
|
|
|
wth->file_encap = WTAP_ENCAP_ATM_RFC1483;
|
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
|
|
|
else {
|
2000-02-19 08:00:08 +00:00
|
|
|
*err = WTAP_ERR_UNSUPPORTED_ENCAP;
|
Have the Wiretap open, read, and seek-and-read routines return, in
addition to an error code, an error info string, for
WTAP_ERR_UNSUPPORTED, WTAP_ERR_UNSUPPORTED_ENCAP, and
WTAP_ERR_BAD_RECORD errors. Replace the error messages logged with
"g_message()" for those errors with g_strdup()ed or g_strdup_printf()ed
strings returned as the error info string, and change the callers of
those routines to, for those errors, put the info string into the
printed message or alert box for the error.
Add messages for cases where those errors were returned without printing
an additional message.
Nobody uses the error code from "cf_read()" - "cf_read()" puts up the
alert box itself for failures; get rid of the error code, so it just
returns a success/failure indication.
Rename "file_read_error_message()" to "cf_read_error_message()", as it
handles read errors from Wiretap, and have it take an error info string
as an argument. (That handles a lot of the work of putting the info
string into the error message.)
Make some variables in "ascend-grammar.y" static.
Check the return value of "erf_read_header()" in "erf_seek_read()".
Get rid of an unused #define in "i4btrace.c".
svn path=/trunk/; revision=9852
2004-01-25 21:55:17 +00:00
|
|
|
*err_info = g_strdup_printf("radcom: network type \"%.4s\" unknown", search_encap);
|
Have the per-capture-file-type open routines "wtap_open_offline()" calls
return 1 on success, -1 if they got an error, and 0 if the file isn't of
the type that file is checking for, and supply an error code if they
return -1; have "wtap_open_offline()" use that error code. Also, have
the per-capture-file-type open routines treat errors accessing the file
as errors, and return -1, rather than just returning 0 so that we try
another file type.
Have the per-capture-file-type read routines "wtap_loop()" calls return
-1 and supply an error code on error (and not, as they did in some
cases, call "g_error()" and abort), and have "wtap_loop()", if the read
routine returned an error, return FALSE (and pass an error-code-pointer
argument onto the read routines, so they fill it in), and return TRUE on
success.
Add some new error codes for them to return.
Now that "wtap_loop()" can return a success/failure indication and an
error code, in "read_cap_file()" put up a message box if we get an error
reading the file, and return the error code.
Handle the additional errors we can get when opening a capture file.
If the attempt to open a capture file succeeds, but the attempt to read
it fails, don't treat that as a complete failure - we may have managed
to read some of the capture file, and we should display what we managed
to read.
svn path=/trunk/; revision=516
1999-08-19 05:31:38 +00:00
|
|
|
return -1;
|
|
|
|
}
|
1999-08-02 02:26:22 +00:00
|
|
|
|
2011-04-27 03:13:08 +00:00
|
|
|
#if 0
|
|
|
|
bytes_read = file_read(&next_date, sizeof(struct frame_date), wth->fh);
|
Have the per-capture-file-type open routines "wtap_open_offline()" calls
return 1 on success, -1 if they got an error, and 0 if the file isn't of
the type that file is checking for, and supply an error code if they
return -1; have "wtap_open_offline()" use that error code. Also, have
the per-capture-file-type open routines treat errors accessing the file
as errors, and return -1, rather than just returning 0 so that we try
another file type.
Have the per-capture-file-type read routines "wtap_loop()" calls return
-1 and supply an error code on error (and not, as they did in some
cases, call "g_error()" and abort), and have "wtap_loop()", if the read
routine returned an error, return FALSE (and pass an error-code-pointer
argument onto the read routines, so they fill it in), and return TRUE on
success.
Add some new error codes for them to return.
Now that "wtap_loop()" can return a success/failure indication and an
error code, in "read_cap_file()" put up a message box if we get an error
reading the file, and return the error code.
Handle the additional errors we can get when opening a capture file.
If the attempt to open a capture file succeeds, but the attempt to read
it fails, don't treat that as a complete failure - we may have managed
to read some of the capture file, and we should display what we managed
to read.
svn path=/trunk/; revision=516
1999-08-19 05:31:38 +00:00
|
|
|
errno = WTAP_ERR_CANT_READ;
|
1999-08-02 02:26:22 +00:00
|
|
|
if (bytes_read != sizeof(struct frame_date)) {
|
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
|
|
|
goto read_error;
|
1999-08-02 02:26:22 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
while (memcmp(&start_date, &next_date, 4)) {
|
2002-06-07 07:27:35 +00:00
|
|
|
if (file_seek(wth->fh, 1-sizeof(struct frame_date), SEEK_CUR, err) == -1)
|
2002-03-04 00:25:35 +00:00
|
|
|
return -1;
|
Have the per-capture-file-type open routines "wtap_open_offline()" calls
return 1 on success, -1 if they got an error, and 0 if the file isn't of
the type that file is checking for, and supply an error code if they
return -1; have "wtap_open_offline()" use that error code. Also, have
the per-capture-file-type open routines treat errors accessing the file
as errors, and return -1, rather than just returning 0 so that we try
another file type.
Have the per-capture-file-type read routines "wtap_loop()" calls return
-1 and supply an error code on error (and not, as they did in some
cases, call "g_error()" and abort), and have "wtap_loop()", if the read
routine returned an error, return FALSE (and pass an error-code-pointer
argument onto the read routines, so they fill it in), and return TRUE on
success.
Add some new error codes for them to return.
Now that "wtap_loop()" can return a success/failure indication and an
error code, in "read_cap_file()" put up a message box if we get an error
reading the file, and return the error code.
Handle the additional errors we can get when opening a capture file.
If the attempt to open a capture file succeeds, but the attempt to read
it fails, don't treat that as a complete failure - we may have managed
to read some of the capture file, and we should display what we managed
to read.
svn path=/trunk/; revision=516
1999-08-19 05:31:38 +00:00
|
|
|
errno = WTAP_ERR_CANT_READ;
|
2011-04-06 06:51:19 +00:00
|
|
|
bytes_read = file_read(&next_date, sizeof(struct frame_date),
|
1999-08-02 02:26:22 +00:00
|
|
|
wth->fh);
|
|
|
|
if (bytes_read != sizeof(struct frame_date)) {
|
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
|
|
|
goto read_error;
|
1999-08-02 02:26:22 +00:00
|
|
|
}
|
2011-04-27 03:13:08 +00:00
|
|
|
}
|
|
|
|
#endif
|
1999-08-02 02:26:22 +00:00
|
|
|
|
1999-08-28 01:19:45 +00:00
|
|
|
if (wth->file_encap == WTAP_ENCAP_ETHERNET) {
|
2002-06-07 07:27:35 +00:00
|
|
|
if (file_seek(wth->fh, 294, SEEK_CUR, err) == -1)
|
2002-03-04 00:25:35 +00:00
|
|
|
return -1;
|
1999-08-28 01:19:45 +00:00
|
|
|
} else if (wth->file_encap == WTAP_ENCAP_LAPB) {
|
2002-06-07 07:27:35 +00:00
|
|
|
if (file_seek(wth->fh, 297, SEEK_CUR, err) == -1)
|
2002-03-04 00:25:35 +00:00
|
|
|
return -1;
|
It appears that the first two bytes of "xxz" are, in fact, the actual
length of the packet, and the second two bytes are the captured length
of the packet. The old "length" value appears to be the captured length
of the packet as well; perhaps it's to be interpreted as the number of
bytes of data following the packet header (just in case there's padding,
for example).
Treat "ATM/", as an encapsulation string, as RFC 1483 ATM. (It may
actually be raw ATM, but the only capture I've seen had, in the parts I
saw, only RFC 1483 traffic LLC/SNAP traffic.)
There are 8 bytes in front of the LLC/SNAP header in ATM captures; skip
them, for now. (Perhaps they're a pseudo-header, giving VPI/VCI
information and stuff such as that? Or perhaps that's in the record
header?)
svn path=/trunk/; revision=6871
2003-01-07 08:41:23 +00:00
|
|
|
} else if (wth->file_encap == WTAP_ENCAP_ATM_RFC1483) {
|
|
|
|
if (file_seek(wth->fh, 504, SEEK_CUR, err) == -1)
|
|
|
|
return -1;
|
1999-08-28 01:19:45 +00:00
|
|
|
}
|
1999-08-02 02:26:22 +00:00
|
|
|
|
Have the per-capture-file-type open routines "wtap_open_offline()" calls
return 1 on success, -1 if they got an error, and 0 if the file isn't of
the type that file is checking for, and supply an error code if they
return -1; have "wtap_open_offline()" use that error code. Also, have
the per-capture-file-type open routines treat errors accessing the file
as errors, and return -1, rather than just returning 0 so that we try
another file type.
Have the per-capture-file-type read routines "wtap_loop()" calls return
-1 and supply an error code on error (and not, as they did in some
cases, call "g_error()" and abort), and have "wtap_loop()", if the read
routine returned an error, return FALSE (and pass an error-code-pointer
argument onto the read routines, so they fill it in), and return TRUE on
success.
Add some new error codes for them to return.
Now that "wtap_loop()" can return a success/failure indication and an
error code, in "read_cap_file()" put up a message box if we get an error
reading the file, and return the error code.
Handle the additional errors we can get when opening a capture file.
If the attempt to open a capture file succeeds, but the attempt to read
it fails, don't treat that as a complete failure - we may have managed
to read some of the capture file, and we should display what we managed
to read.
svn path=/trunk/; revision=516
1999-08-19 05:31:38 +00:00
|
|
|
return 1;
|
|
|
|
|
|
|
|
read_error:
|
2011-04-21 09:41:52 +00:00
|
|
|
*err = file_error(wth->fh, err_info);
|
2000-04-15 21:12:37 +00:00
|
|
|
if (*err != 0)
|
Have the per-capture-file-type open routines "wtap_open_offline()" calls
return 1 on success, -1 if they got an error, and 0 if the file isn't of
the type that file is checking for, and supply an error code if they
return -1; have "wtap_open_offline()" use that error code. Also, have
the per-capture-file-type open routines treat errors accessing the file
as errors, and return -1, rather than just returning 0 so that we try
another file type.
Have the per-capture-file-type read routines "wtap_loop()" calls return
-1 and supply an error code on error (and not, as they did in some
cases, call "g_error()" and abort), and have "wtap_loop()", if the read
routine returned an error, return FALSE (and pass an error-code-pointer
argument onto the read routines, so they fill it in), and return TRUE on
success.
Add some new error codes for them to return.
Now that "wtap_loop()" can return a success/failure indication and an
error code, in "read_cap_file()" put up a message box if we get an error
reading the file, and return the error code.
Handle the additional errors we can get when opening a capture file.
If the attempt to open a capture file succeeds, but the attempt to read
it fails, don't treat that as a complete failure - we may have managed
to read some of the capture file, and we should display what we managed
to read.
svn path=/trunk/; revision=516
1999-08-19 05:31:38 +00:00
|
|
|
return -1;
|
|
|
|
return 0;
|
1999-08-02 02:26:22 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
/* Read the next packet */
|
2011-04-21 09:41:52 +00:00
|
|
|
static gboolean radcom_read(wtap *wth, int *err, gchar **err_info,
|
2011-04-27 03:13:08 +00:00
|
|
|
gint64 *data_offset)
|
1999-08-02 02:26:22 +00:00
|
|
|
{
|
2000-05-18 09:09:50 +00:00
|
|
|
int ret;
|
1999-09-01 23:53:58 +00:00
|
|
|
struct radcomrec_hdr hdr;
|
It appears that the first two bytes of "xxz" are, in fact, the actual
length of the packet, and the second two bytes are the captured length
of the packet. The old "length" value appears to be the captured length
of the packet as well; perhaps it's to be interpreted as the number of
bytes of data following the packet header (just in case there's padding,
for example).
Treat "ATM/", as an encapsulation string, as RFC 1483 ATM. (It may
actually be raw ATM, but the only capture I've seen had, in the parts I
saw, only RFC 1483 traffic LLC/SNAP traffic.)
There are 8 bytes in front of the LLC/SNAP header in ATM captures; skip
them, for now. (Perhaps they're a pseudo-header, giving VPI/VCI
information and stuff such as that? Or perhaps that's in the record
header?)
svn path=/trunk/; revision=6871
2003-01-07 08:41:23 +00:00
|
|
|
guint16 data_length, real_length, length;
|
1999-08-31 00:25:19 +00:00
|
|
|
guint32 sec;
|
2000-05-18 09:09:50 +00:00
|
|
|
int bytes_read;
|
1999-08-02 02:26:22 +00:00
|
|
|
struct tm tm;
|
2011-09-01 09:43:10 +00:00
|
|
|
guint8 phdr[8];
|
1999-09-01 23:53:58 +00:00
|
|
|
char fcs[2];
|
1999-08-02 02:26:22 +00:00
|
|
|
|
1999-09-01 23:53:58 +00:00
|
|
|
/* Read record header. */
|
2012-05-04 16:56:18 +00:00
|
|
|
*data_offset = file_tell(wth->fh);
|
2011-04-21 09:41:52 +00:00
|
|
|
ret = radcom_read_rec_header(wth->fh, &hdr, err, err_info);
|
2000-05-18 09:09:50 +00:00
|
|
|
if (ret <= 0) {
|
|
|
|
/* Read error or EOF */
|
2000-09-07 05:34:23 +00:00
|
|
|
return FALSE;
|
1999-08-02 02:26:22 +00:00
|
|
|
}
|
It appears that the first two bytes of "xxz" are, in fact, the actual
length of the packet, and the second two bytes are the captured length
of the packet. The old "length" value appears to be the captured length
of the packet as well; perhaps it's to be interpreted as the number of
bytes of data following the packet header (just in case there's padding,
for example).
Treat "ATM/", as an encapsulation string, as RFC 1483 ATM. (It may
actually be raw ATM, but the only capture I've seen had, in the parts I
saw, only RFC 1483 traffic LLC/SNAP traffic.)
There are 8 bytes in front of the LLC/SNAP header in ATM captures; skip
them, for now. (Perhaps they're a pseudo-header, giving VPI/VCI
information and stuff such as that? Or perhaps that's in the record
header?)
svn path=/trunk/; revision=6871
2003-01-07 08:41:23 +00:00
|
|
|
data_length = pletohs(&hdr.data_length);
|
|
|
|
if (data_length == 0) {
|
|
|
|
/*
|
|
|
|
* The last record appears to have 0 in its "data_length"
|
|
|
|
* field, but non-zero values in other fields, so we
|
|
|
|
* check for that and treat it as an EOF indication.
|
|
|
|
*/
|
2004-06-16 08:11:59 +00:00
|
|
|
*err = 0;
|
It appears that the first two bytes of "xxz" are, in fact, the actual
length of the packet, and the second two bytes are the captured length
of the packet. The old "length" value appears to be the captured length
of the packet as well; perhaps it's to be interpreted as the number of
bytes of data following the packet header (just in case there's padding,
for example).
Treat "ATM/", as an encapsulation string, as RFC 1483 ATM. (It may
actually be raw ATM, but the only capture I've seen had, in the parts I
saw, only RFC 1483 traffic LLC/SNAP traffic.)
There are 8 bytes in front of the LLC/SNAP header in ATM captures; skip
them, for now. (Perhaps they're a pseudo-header, giving VPI/VCI
information and stuff such as that? Or perhaps that's in the record
header?)
svn path=/trunk/; revision=6871
2003-01-07 08:41:23 +00:00
|
|
|
return FALSE;
|
|
|
|
}
|
1999-09-01 23:53:58 +00:00
|
|
|
length = pletohs(&hdr.length);
|
It appears that the first two bytes of "xxz" are, in fact, the actual
length of the packet, and the second two bytes are the captured length
of the packet. The old "length" value appears to be the captured length
of the packet as well; perhaps it's to be interpreted as the number of
bytes of data following the packet header (just in case there's padding,
for example).
Treat "ATM/", as an encapsulation string, as RFC 1483 ATM. (It may
actually be raw ATM, but the only capture I've seen had, in the parts I
saw, only RFC 1483 traffic LLC/SNAP traffic.)
There are 8 bytes in front of the LLC/SNAP header in ATM captures; skip
them, for now. (Perhaps they're a pseudo-header, giving VPI/VCI
information and stuff such as that? Or perhaps that's in the record
header?)
svn path=/trunk/; revision=6871
2003-01-07 08:41:23 +00:00
|
|
|
real_length = pletohs(&hdr.real_length);
|
1999-08-02 02:26:22 +00:00
|
|
|
|
It appears that the first two bytes of "xxz" are, in fact, the actual
length of the packet, and the second two bytes are the captured length
of the packet. The old "length" value appears to be the captured length
of the packet as well; perhaps it's to be interpreted as the number of
bytes of data following the packet header (just in case there's padding,
for example).
Treat "ATM/", as an encapsulation string, as RFC 1483 ATM. (It may
actually be raw ATM, but the only capture I've seen had, in the parts I
saw, only RFC 1483 traffic LLC/SNAP traffic.)
There are 8 bytes in front of the LLC/SNAP header in ATM captures; skip
them, for now. (Perhaps they're a pseudo-header, giving VPI/VCI
information and stuff such as that? Or perhaps that's in the record
header?)
svn path=/trunk/; revision=6871
2003-01-07 08:41:23 +00:00
|
|
|
if (wth->file_encap == WTAP_ENCAP_LAPB) {
|
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
|
|
|
length -= 2; /* FCS */
|
It appears that the first two bytes of "xxz" are, in fact, the actual
length of the packet, and the second two bytes are the captured length
of the packet. The old "length" value appears to be the captured length
of the packet as well; perhaps it's to be interpreted as the number of
bytes of data following the packet header (just in case there's padding,
for example).
Treat "ATM/", as an encapsulation string, as RFC 1483 ATM. (It may
actually be raw ATM, but the only capture I've seen had, in the parts I
saw, only RFC 1483 traffic LLC/SNAP traffic.)
There are 8 bytes in front of the LLC/SNAP header in ATM captures; skip
them, for now. (Perhaps they're a pseudo-header, giving VPI/VCI
information and stuff such as that? Or perhaps that's in the record
header?)
svn path=/trunk/; revision=6871
2003-01-07 08:41:23 +00:00
|
|
|
real_length -= 2;
|
|
|
|
}
|
1999-08-02 02:26:22 +00:00
|
|
|
|
2012-02-25 23:24:34 +00:00
|
|
|
wth->phdr.presence_flags = WTAP_HAS_TS|WTAP_HAS_CAP_LEN;
|
|
|
|
|
It appears that the first two bytes of "xxz" are, in fact, the actual
length of the packet, and the second two bytes are the captured length
of the packet. The old "length" value appears to be the captured length
of the packet as well; perhaps it's to be interpreted as the number of
bytes of data following the packet header (just in case there's padding,
for example).
Treat "ATM/", as an encapsulation string, as RFC 1483 ATM. (It may
actually be raw ATM, but the only capture I've seen had, in the parts I
saw, only RFC 1483 traffic LLC/SNAP traffic.)
There are 8 bytes in front of the LLC/SNAP header in ATM captures; skip
them, for now. (Perhaps they're a pseudo-header, giving VPI/VCI
information and stuff such as that? Or perhaps that's in the record
header?)
svn path=/trunk/; revision=6871
2003-01-07 08:41:23 +00:00
|
|
|
wth->phdr.len = real_length;
|
1999-08-02 02:26:22 +00:00
|
|
|
wth->phdr.caplen = length;
|
|
|
|
|
1999-09-01 23:53:58 +00:00
|
|
|
tm.tm_year = pletohs(&hdr.date.year)-1900;
|
It appears that the first two bytes of "xxz" are, in fact, the actual
length of the packet, and the second two bytes are the captured length
of the packet. The old "length" value appears to be the captured length
of the packet as well; perhaps it's to be interpreted as the number of
bytes of data following the packet header (just in case there's padding,
for example).
Treat "ATM/", as an encapsulation string, as RFC 1483 ATM. (It may
actually be raw ATM, but the only capture I've seen had, in the parts I
saw, only RFC 1483 traffic LLC/SNAP traffic.)
There are 8 bytes in front of the LLC/SNAP header in ATM captures; skip
them, for now. (Perhaps they're a pseudo-header, giving VPI/VCI
information and stuff such as that? Or perhaps that's in the record
header?)
svn path=/trunk/; revision=6871
2003-01-07 08:41:23 +00:00
|
|
|
tm.tm_mon = (hdr.date.month&0x0f)-1;
|
1999-09-01 23:53:58 +00:00
|
|
|
tm.tm_mday = hdr.date.day;
|
|
|
|
sec = pletohl(&hdr.date.sec);
|
1999-08-31 00:25:19 +00:00
|
|
|
tm.tm_hour = sec/3600;
|
|
|
|
tm.tm_min = (sec%3600)/60;
|
|
|
|
tm.tm_sec = sec%60;
|
1999-08-02 02:26:22 +00:00
|
|
|
tm.tm_isdst = -1;
|
2005-08-24 21:31:56 +00:00
|
|
|
wth->phdr.ts.secs = mktime(&tm);
|
|
|
|
wth->phdr.ts.nsecs = pletohl(&hdr.date.usec) * 1000;
|
It appears that the first two bytes of "xxz" are, in fact, the actual
length of the packet, and the second two bytes are the captured length
of the packet. The old "length" value appears to be the captured length
of the packet as well; perhaps it's to be interpreted as the number of
bytes of data following the packet header (just in case there's padding,
for example).
Treat "ATM/", as an encapsulation string, as RFC 1483 ATM. (It may
actually be raw ATM, but the only capture I've seen had, in the parts I
saw, only RFC 1483 traffic LLC/SNAP traffic.)
There are 8 bytes in front of the LLC/SNAP header in ATM captures; skip
them, for now. (Perhaps they're a pseudo-header, giving VPI/VCI
information and stuff such as that? Or perhaps that's in the record
header?)
svn path=/trunk/; revision=6871
2003-01-07 08:41:23 +00:00
|
|
|
|
|
|
|
switch (wth->file_encap) {
|
|
|
|
|
2003-10-01 07:11:49 +00:00
|
|
|
case WTAP_ENCAP_ETHERNET:
|
|
|
|
/* XXX - is there an FCS? */
|
2012-10-16 21:50:57 +00:00
|
|
|
wth->phdr.pseudo_header.eth.fcs_len = -1;
|
2003-10-01 07:11:49 +00:00
|
|
|
break;
|
|
|
|
|
It appears that the first two bytes of "xxz" are, in fact, the actual
length of the packet, and the second two bytes are the captured length
of the packet. The old "length" value appears to be the captured length
of the packet as well; perhaps it's to be interpreted as the number of
bytes of data following the packet header (just in case there's padding,
for example).
Treat "ATM/", as an encapsulation string, as RFC 1483 ATM. (It may
actually be raw ATM, but the only capture I've seen had, in the parts I
saw, only RFC 1483 traffic LLC/SNAP traffic.)
There are 8 bytes in front of the LLC/SNAP header in ATM captures; skip
them, for now. (Perhaps they're a pseudo-header, giving VPI/VCI
information and stuff such as that? Or perhaps that's in the record
header?)
svn path=/trunk/; revision=6871
2003-01-07 08:41:23 +00:00
|
|
|
case WTAP_ENCAP_LAPB:
|
2012-10-16 21:50:57 +00:00
|
|
|
wth->phdr.pseudo_header.x25.flags = (hdr.dce & 0x1) ?
|
It appears that the first two bytes of "xxz" are, in fact, the actual
length of the packet, and the second two bytes are the captured length
of the packet. The old "length" value appears to be the captured length
of the packet as well; perhaps it's to be interpreted as the number of
bytes of data following the packet header (just in case there's padding,
for example).
Treat "ATM/", as an encapsulation string, as RFC 1483 ATM. (It may
actually be raw ATM, but the only capture I've seen had, in the parts I
saw, only RFC 1483 traffic LLC/SNAP traffic.)
There are 8 bytes in front of the LLC/SNAP header in ATM captures; skip
them, for now. (Perhaps they're a pseudo-header, giving VPI/VCI
information and stuff such as that? Or perhaps that's in the record
header?)
svn path=/trunk/; revision=6871
2003-01-07 08:41:23 +00:00
|
|
|
0x00 : FROM_DCE;
|
|
|
|
break;
|
|
|
|
|
|
|
|
case WTAP_ENCAP_ATM_RFC1483:
|
|
|
|
/*
|
|
|
|
* XXX - is this stuff a pseudo-header?
|
|
|
|
* The direction appears to be in the "hdr.dce" field.
|
|
|
|
*/
|
2011-04-21 09:41:52 +00:00
|
|
|
if (!radcom_read_rec_data(wth->fh, phdr, sizeof phdr, err,
|
|
|
|
err_info))
|
It appears that the first two bytes of "xxz" are, in fact, the actual
length of the packet, and the second two bytes are the captured length
of the packet. The old "length" value appears to be the captured length
of the packet as well; perhaps it's to be interpreted as the number of
bytes of data following the packet header (just in case there's padding,
for example).
Treat "ATM/", as an encapsulation string, as RFC 1483 ATM. (It may
actually be raw ATM, but the only capture I've seen had, in the parts I
saw, only RFC 1483 traffic LLC/SNAP traffic.)
There are 8 bytes in front of the LLC/SNAP header in ATM captures; skip
them, for now. (Perhaps they're a pseudo-header, giving VPI/VCI
information and stuff such as that? Or perhaps that's in the record
header?)
svn path=/trunk/; revision=6871
2003-01-07 08:41:23 +00:00
|
|
|
return FALSE; /* Read error */
|
|
|
|
length -= 8;
|
|
|
|
wth->phdr.len -= 8;
|
|
|
|
wth->phdr.caplen -= 8;
|
|
|
|
break;
|
|
|
|
}
|
1999-08-02 02:26:22 +00:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Read the packet data.
|
|
|
|
*/
|
|
|
|
buffer_assure_space(wth->frame_buffer, length);
|
2002-03-05 08:40:27 +00:00
|
|
|
if (!radcom_read_rec_data(wth->fh,
|
2011-04-21 09:41:52 +00:00
|
|
|
buffer_start_ptr(wth->frame_buffer), length, err, err_info))
|
2000-09-07 05:34:23 +00:00
|
|
|
return FALSE; /* Read error */
|
1999-08-02 02:26:22 +00:00
|
|
|
|
1999-08-28 01:19:45 +00:00
|
|
|
if (wth->file_encap == WTAP_ENCAP_LAPB) {
|
1999-09-01 23:53:58 +00:00
|
|
|
/* Read the FCS.
|
It appears that the first two bytes of "xxz" are, in fact, the actual
length of the packet, and the second two bytes are the captured length
of the packet. The old "length" value appears to be the captured length
of the packet as well; perhaps it's to be interpreted as the number of
bytes of data following the packet header (just in case there's padding,
for example).
Treat "ATM/", as an encapsulation string, as RFC 1483 ATM. (It may
actually be raw ATM, but the only capture I've seen had, in the parts I
saw, only RFC 1483 traffic LLC/SNAP traffic.)
There are 8 bytes in front of the LLC/SNAP header in ATM captures; skip
them, for now. (Perhaps they're a pseudo-header, giving VPI/VCI
information and stuff such as that? Or perhaps that's in the record
header?)
svn path=/trunk/; revision=6871
2003-01-07 08:41:23 +00:00
|
|
|
XXX - should we have some way of indicating the
|
|
|
|
presence and size of an FCS to our caller?
|
|
|
|
That'd let us handle other file types as well. */
|
1999-09-01 23:53:58 +00:00
|
|
|
errno = WTAP_ERR_CANT_READ;
|
2011-04-06 06:51:19 +00:00
|
|
|
bytes_read = file_read(&fcs, sizeof fcs, wth->fh);
|
1999-09-01 23:53:58 +00:00
|
|
|
if (bytes_read != sizeof fcs) {
|
2011-04-21 09:41:52 +00:00
|
|
|
*err = file_error(wth->fh, err_info);
|
1999-10-05 07:06:08 +00:00
|
|
|
if (*err == 0)
|
1999-09-01 23:53:58 +00:00
|
|
|
*err = WTAP_ERR_SHORT_READ;
|
2000-09-07 05:34:23 +00:00
|
|
|
return FALSE;
|
1999-09-01 23:53:58 +00:00
|
|
|
}
|
1999-08-28 01:19:45 +00:00
|
|
|
}
|
1999-08-02 02:26:22 +00:00
|
|
|
|
2000-09-07 05:34:23 +00:00
|
|
|
return TRUE;
|
2000-05-18 09:09:50 +00:00
|
|
|
}
|
|
|
|
|
2002-03-05 08:40:27 +00:00
|
|
|
static gboolean
|
2006-11-05 22:46:44 +00:00
|
|
|
radcom_seek_read(wtap *wth, gint64 seek_off,
|
2012-10-16 21:50:57 +00:00
|
|
|
struct wtap_pkthdr *pkhdr, guint8 *pd, int length,
|
2011-04-27 03:13:08 +00:00
|
|
|
int *err, gchar **err_info)
|
2000-05-18 09:09:50 +00:00
|
|
|
{
|
2012-10-16 21:50:57 +00:00
|
|
|
union wtap_pseudo_header *pseudo_header = &pkhdr->pseudo_header;
|
2000-05-18 09:09:50 +00:00
|
|
|
int ret;
|
|
|
|
struct radcomrec_hdr hdr;
|
2011-09-01 09:43:10 +00:00
|
|
|
guint8 phdr[8];
|
2000-05-18 09:09:50 +00:00
|
|
|
|
2002-06-07 07:27:35 +00:00
|
|
|
if (file_seek(wth->random_fh, seek_off, SEEK_SET, err) == -1)
|
2002-03-05 08:40:27 +00:00
|
|
|
return FALSE;
|
2000-05-18 09:09:50 +00:00
|
|
|
|
|
|
|
/* Read record header. */
|
2011-04-21 09:41:52 +00:00
|
|
|
ret = radcom_read_rec_header(wth->random_fh, &hdr, err, err_info);
|
2000-05-18 09:09:50 +00:00
|
|
|
if (ret <= 0) {
|
|
|
|
/* Read error or EOF */
|
2002-03-05 05:58:41 +00:00
|
|
|
if (ret == 0) {
|
|
|
|
/* EOF means "short read" in random-access mode */
|
|
|
|
*err = WTAP_ERR_SHORT_READ;
|
|
|
|
}
|
2002-03-05 08:40:27 +00:00
|
|
|
return FALSE;
|
2000-05-18 09:09:50 +00:00
|
|
|
}
|
|
|
|
|
It appears that the first two bytes of "xxz" are, in fact, the actual
length of the packet, and the second two bytes are the captured length
of the packet. The old "length" value appears to be the captured length
of the packet as well; perhaps it's to be interpreted as the number of
bytes of data following the packet header (just in case there's padding,
for example).
Treat "ATM/", as an encapsulation string, as RFC 1483 ATM. (It may
actually be raw ATM, but the only capture I've seen had, in the parts I
saw, only RFC 1483 traffic LLC/SNAP traffic.)
There are 8 bytes in front of the LLC/SNAP header in ATM captures; skip
them, for now. (Perhaps they're a pseudo-header, giving VPI/VCI
information and stuff such as that? Or perhaps that's in the record
header?)
svn path=/trunk/; revision=6871
2003-01-07 08:41:23 +00:00
|
|
|
switch (wth->file_encap) {
|
|
|
|
|
2003-10-01 07:11:49 +00:00
|
|
|
case WTAP_ENCAP_ETHERNET:
|
|
|
|
/* XXX - is there an FCS? */
|
|
|
|
pseudo_header->eth.fcs_len = -1;
|
|
|
|
break;
|
|
|
|
|
It appears that the first two bytes of "xxz" are, in fact, the actual
length of the packet, and the second two bytes are the captured length
of the packet. The old "length" value appears to be the captured length
of the packet as well; perhaps it's to be interpreted as the number of
bytes of data following the packet header (just in case there's padding,
for example).
Treat "ATM/", as an encapsulation string, as RFC 1483 ATM. (It may
actually be raw ATM, but the only capture I've seen had, in the parts I
saw, only RFC 1483 traffic LLC/SNAP traffic.)
There are 8 bytes in front of the LLC/SNAP header in ATM captures; skip
them, for now. (Perhaps they're a pseudo-header, giving VPI/VCI
information and stuff such as that? Or perhaps that's in the record
header?)
svn path=/trunk/; revision=6871
2003-01-07 08:41:23 +00:00
|
|
|
case WTAP_ENCAP_LAPB:
|
|
|
|
pseudo_header->x25.flags = (hdr.dce & 0x1) ? 0x00 : FROM_DCE;
|
|
|
|
break;
|
|
|
|
|
|
|
|
case WTAP_ENCAP_ATM_RFC1483:
|
|
|
|
/*
|
|
|
|
* XXX - is this stuff a pseudo-header?
|
|
|
|
* The direction appears to be in the "hdr.dce" field.
|
|
|
|
*/
|
|
|
|
if (!radcom_read_rec_data(wth->random_fh, phdr, sizeof phdr,
|
2011-04-21 09:41:52 +00:00
|
|
|
err, err_info))
|
It appears that the first two bytes of "xxz" are, in fact, the actual
length of the packet, and the second two bytes are the captured length
of the packet. The old "length" value appears to be the captured length
of the packet as well; perhaps it's to be interpreted as the number of
bytes of data following the packet header (just in case there's padding,
for example).
Treat "ATM/", as an encapsulation string, as RFC 1483 ATM. (It may
actually be raw ATM, but the only capture I've seen had, in the parts I
saw, only RFC 1483 traffic LLC/SNAP traffic.)
There are 8 bytes in front of the LLC/SNAP header in ATM captures; skip
them, for now. (Perhaps they're a pseudo-header, giving VPI/VCI
information and stuff such as that? Or perhaps that's in the record
header?)
svn path=/trunk/; revision=6871
2003-01-07 08:41:23 +00:00
|
|
|
return FALSE; /* Read error */
|
|
|
|
break;
|
|
|
|
}
|
2000-05-18 09:09:50 +00:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Read the packet data.
|
|
|
|
*/
|
2011-04-21 09:41:52 +00:00
|
|
|
return radcom_read_rec_data(wth->random_fh, pd, length, err, err_info);
|
2000-05-18 09:09:50 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
static int
|
2011-04-21 09:41:52 +00:00
|
|
|
radcom_read_rec_header(FILE_T fh, struct radcomrec_hdr *hdr, int *err,
|
2011-04-27 03:13:08 +00:00
|
|
|
gchar **err_info)
|
2000-05-18 09:09:50 +00:00
|
|
|
{
|
|
|
|
int bytes_read;
|
|
|
|
|
|
|
|
errno = WTAP_ERR_CANT_READ;
|
2011-04-06 06:51:19 +00:00
|
|
|
bytes_read = file_read(hdr, sizeof *hdr, fh);
|
2000-05-18 09:09:50 +00:00
|
|
|
if (bytes_read != sizeof *hdr) {
|
2011-04-21 09:41:52 +00:00
|
|
|
*err = file_error(fh, err_info);
|
2000-05-18 09:09:50 +00:00
|
|
|
if (*err != 0)
|
|
|
|
return -1;
|
|
|
|
if (bytes_read != 0) {
|
|
|
|
*err = WTAP_ERR_SHORT_READ;
|
|
|
|
return -1;
|
|
|
|
}
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
return 1;
|
|
|
|
}
|
|
|
|
|
2002-03-05 08:40:27 +00:00
|
|
|
static gboolean
|
2011-09-01 09:43:10 +00:00
|
|
|
radcom_read_rec_data(FILE_T fh, guint8 *pd, int length, int *err,
|
2011-04-27 03:13:08 +00:00
|
|
|
gchar **err_info)
|
2000-05-18 09:09:50 +00:00
|
|
|
{
|
|
|
|
int bytes_read;
|
|
|
|
|
|
|
|
errno = WTAP_ERR_CANT_READ;
|
2011-04-06 06:51:19 +00:00
|
|
|
bytes_read = file_read(pd, length, fh);
|
2000-05-18 09:09:50 +00:00
|
|
|
|
|
|
|
if (bytes_read != length) {
|
2011-04-21 09:41:52 +00:00
|
|
|
*err = file_error(fh, err_info);
|
2000-05-18 09:09:50 +00:00
|
|
|
if (*err == 0)
|
|
|
|
*err = WTAP_ERR_SHORT_READ;
|
2002-03-05 08:40:27 +00:00
|
|
|
return FALSE;
|
2000-05-18 09:09:50 +00:00
|
|
|
}
|
2002-03-05 08:40:27 +00:00
|
|
|
return TRUE;
|
1999-08-02 02:26:22 +00:00
|
|
|
}
|